Utilisation du VPN site à site comme solution de secours pour le Peering privé ExpressRoute
Dans l’article intitulé Conception pour la reprise d’activité avec le peering privé ExpressRoute, nous avons parlé de la nécessité d’avoir une solution de connectivité de secours en cas d’utilisation du peering privé ExpressRoute. Nous avons également expliqué comment utiliser des circuits ExpressRoute géoredondants pour la haute disponibilité. Dans cet article, nous expliquons comment utiliser et maintenir un VPN site à site (S2S) comme sauvegarde pour un Peering privé ExpressRoute.
Remarque
L’utilisation d’un VPN site à site comme solution de secours pour la connectivité ExpressRoute n’est pas recommandée lorsqu’il s’agit de charges de travail stratégiques, sensibles à la latence ou gourmandes en bande passante. Dans ce cas, il est recommandé de concevoir la récupération d’urgence avec une résilience multisite ExpressRoute afin de garantir une disponibilité maximale.
Contrairement aux circuits ExpressRoute géoredondants, vous pouvez utiliser la combinaison de reprise d’activité ExpressRoute et VPN uniquement dans une configuration active-passive. L’une des principales difficultés de l’utilisation d’une connectivité réseau de secours en mode passif est que la connexion passive échoue souvent en même temps que la connexion principale. L’absence de maintenance active est la raison la plus fréquente des échecs de la connexion passive. Par conséquent, dans cet article, nous expliquons en particulier comment vérifier et gérer activement une connectivité VPN site à site comme solution de secours d’un peering privé ExpressRoute.
Notes
Quand une route donnée est publiée avec ExpressRoute et VPN, Azure privilégie le routage sur ExpressRoute.
Dans cet article, vous apprenez également à vérifier la connectivité du côté d’Azure et du côté de la périphérie réseau locale. La possibilité de valider d’un côté comme de l’autre est utile, que vous gériez ou non les périphériques réseau locaux appairés avec les entités de réseau Microsoft.
Exemple de topologie
Dans notre configuration, nous disposons d’un réseau local connecté à un réseau virtuel hub Azure via un circuit ExpressRoute et une connexion S2S VPN. Le réseau virtuel hub Azure est à son tour appairé à un réseau virtuel spoke, comme indiqué dans le diagramme ci-dessous :
Dans la configuration, le circuit ExpressRoute se termine sur une paire de routeurs à la périphérie du client (CE) localement. Le LAN local est connecté aux routeurs CE avec une paire de pare-feu qui fonctionnent en mode « leader-suiveur ». Le VPN S2S s’arrête directement sur les pare-feu.
Le tableau suivant répertorie les principaux préfixes d’adresse IP de la topologie :
| Entité | Préfixe |
|---|---|
| LAN local | 10.1.11.0/25 |
| Réseau virtuel hub Azure | 10.17.11.0/25 |
| Réseau virtuel Azure Spoke | 10.17.11.128/26 |
| Serveur de test local | 10.1.11.10 |
| Machine virtuelle de test de réseau virtuel spoke | 10.17.11.132 |
| Sous-réseau P2P de connexion principale ExpressRoute | 192.168.11.16/30 |
| Sous-réseau P2P de la connexion secondaire ExpressRoute | 192.168.11.20/30 |
| Adresse IP d’homologue BGP principale de la passerelle VPN | 10.17.11.76 |
| Adresse IP d’homologue BGP secondaire de la passerelle VPN | 10.17.11.77 |
| Adresse IP d’homologue BGP du VPN du pare-feu local | 192.168.11.88 |
| Adresse IP de l’interface du routeur CE principal vers le pare-feu | 192.168.11.0/31 |
| Adresse IP de l’interface du pare-feu vers le routeur CE principal | 192.168.11.1/31 |
| Adresse IP de l’interface du routeur CE secondaire vers le pare-feu | 192.168.11.2/31 |
| Adresse IP de l’interface du pare-feu vers le routeur CE secondaire | 192.168.11.3/31 |
Le tableau suivant répertorie les ASN de la topologie :
| Système autonome | ASN |
|---|---|
| Local | 65020 |
| Microsoft Enterprise Edge | 12076 |
| GW Réseau virtuel (ExR) | 65515 |
| GW Réseau virtuel (VPN) | 65515 |
Haute disponibilité sans asymétrie
Configuration pour la haute disponibilité
L’article Configurer la coexistence de connexions de site à site et ExpressRoute explique comment configurer la coexistence des connexions ExpressRoute et S2S VPN. Comme nous l’avons indiqué dans Conception pour une haute disponibilité avec ExpressRoute, notre configuration veille à une redondance du réseau pour éliminer tout point de défaillance unique jusqu’aux points de terminaison et améliorer la haute disponibilité d’ExpressRoute. En outre, les connexions primaire et secondaire des circuits ExpressRoute sont actives et publient les préfixes locaux de la même manière via les deux connexions.
La publication de routes locales par le routeur CE principal sur la connexion principale du circuit ExpressRoute est illustrée ci-dessous (commandes Junos) :
user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
La publication de routes locales par le routeur CE secondaire sur la connexion secondaire du circuit ExpressRoute est illustrée ci-dessous (commandes Junos) :
user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Pour améliorer la haute disponibilité de la connexion de secours, le VPN S2S est également configuré en mode actif-actif. La configuration de la passerelle VPN Azure est indiquée ci-dessous. Notez que, dans le cadre de la configuration du VPN, les adresses IP d’homologue BGP de la passerelle (10.17.11.76 et 10.17.11.77) sont également répertoriées.
La route locale est publiée par le pare-feu sur les homologues BGP principal et secondaire de la passerelle VPN. Les publications de route sont illustrées ci-dessous (Junos) :
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Notes
La configuration du VPN site à site en mode actif-actif fournit non seulement une haute disponibilité à votre connectivité de réseau de secours pour la reprise d’activité, mais lui fournit également un débit plus élevé . Par conséquent, la configuration du VPN site à site en mode actif-actif est recommandée, car elle crée plusieurs tunnels sous-jacents.
Configuration du flux de trafic symétrique
Nous avons noté que, quand une route locale donnée est publiée sur ExpressRoute et un VPN site à site, Azure privilégie le chemin ExpressRoute. Pour forcer Azure à privilégier le chemin du VPN site à site aux circuits ExpressRoute coexistants, vous devez publier des routes plus spécifiques (préfixe plus long avec un masque de sous-réseau plus grand) sur la connexion VPN. Notre objectif est d’utiliser les connexions VPN comme solution de secours uniquement. Par conséquent, le comportement de sélection du chemin d’accès par défaut d’Azure est conforme à notre objectif.
Nous devons faire en sorte que le trafic d’un emplacement local vers Azure privilégie également le chemin ExpressRoute au VPN site à site. La préférence locale par défaut des routeurs CE et des pare-feu dans notre configuration locale est 100. Par conséquent, en configurant la préférence locale des routes reçues sur les peerings privés ExpressRoute supérieurs à 100, nous pouvons forcer le trafic destiné à Azure sur le circuit ExpressRoute.
La configuration BGP du routeur CE principal qui termine la connexion principale du circuit ExpressRoute est illustrée ci-dessous. Notez que la préférence locale des itinéraires publiés via la session iBGP est configurée sur la valeur 150. De même, nous devons nous assurer que la préférence locale du routeur CE secondaire qui termine la connexion secondaire du circuit ExpressRoute est également configurée sur 150.
user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
bgp {
group ibgp {
type internal;
local-preference 150;
neighbor 192.168.11.1;
}
group ebgp {
peer-as 12076;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
}
neighbor 192.168.11.18;
}
}
}
La table de routage des pare-feu locaux confirme que, pour le trafic local destiné à Azure, le chemin d’accès privilégié est ExpressRoute à l’état stable.
user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.17.11.0/25 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
10.17.11.76/32 *[Static/5] 2d 21:12:16
> via st0.118
10.17.11.77/32 *[Static/5] 2d 00:41:56
> via st0.119
10.17.11.128/26 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
Dans la table de route ci-dessus, pour les routes de réseau virtuel hub et spoke (10.17.11.0/25 et 10.17.11.128/26), nous voyons que le circuit ExpressRoute est préférable aux connexions VPN. Les adresses 192.168.11.0 et 192.168.11.2 sont des adresses IP sur l’interface de pare-feu vers les routeurs CE.
Validation de l’échange d’itinéraires via un VPN S2S
Plus haut dans cet article, nous avons vérifié la publication d’itinéraires locaux par les pare-feu sur l’homologue BGP principal et secondaire de la passerelle VPN. Par ailleurs, nous allons confirmer les itinéraires Azure reçus par les pare-feu de l’homologue BGP principal et secondaire de la passerelle VPN.
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.76 65515 I
10.17.11.128/26 10.17.11.76 65515 I
{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.77 65515 I
10.17.11.128/26 10.17.11.77 65515 I
De même, nous allons vérifier les préfixes d’itinéraire du réseau local reçus par la passerelle VPN Azure.
PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.76 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.77 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
Comme vu précédemment, la passerelle VPN reçoit des routes par les pairs BGP principal et secondaire. La passerelle VPN offre également une visibilité sur les itinéraires reçus via les connexions ExpressRoute principale et secondaire (celles avec AS-path précédé de 12076). Pour confirmer les itinéraires reçus via des connexions VPN, nous devons connaître l’adresse IP locale d’homologue BGP des connexions. Dans la configuration que nous étudions, l’IP est 192.168.11.88 et nous voyons bien les routes reçues.
Ensuite, nous allons vérifier les itinéraires publiés par la passerelle VPN Azure vers l’homologue BGP de pare-feu local (192.168.11.88).
PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.17.11.0/25 10.17.11.76 65515 0
10.17.11.128/26 10.17.11.76 65515 0
10.17.11.0/25 10.17.11.77 65515 0
10.17.11.128/26 10.17.11.77 65515 0
Le fait de ne pas voir les échanges d’itinéraires indique un échec de la connexion. Pour vous aider à résoudre les problèmes de la connexion VPN, consultez Résolution des problèmes : une connexion VPN site à site Azure ne peut pas se connecter et cesse de fonctionner.
Test du basculement
Maintenant que nous avons confirmé le succès des échanges de route sur la connexion VPN (plan de contrôle), nous sommes prêts à basculer le trafic (plan de données) de la connectivité ExpressRoute à la connectivité VPN.
Remarque
Dans les environnements de production, les tests de basculement doivent être effectués pendant les fenêtres programmées de maintenance du réseau, car ils peuvent perturber le service.
Avant de procéder au basculement du trafic, effectuons le tracé de route du chemin d’accès actuel dans notre configuration à partir du serveur de test local jusqu’à la machine virtuelle de test dans le réseau virtuel spoke.
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 <1 ms <1 ms 11 ms 192.168.11.0
3 <1 ms <1 ms <1 ms 192.168.11.18
4 * * * Request timed out.
5 6 ms 6 ms 5 ms 10.17.11.132
Trace complete.
Les sous-réseaux de connexion point à point ExpressRoute principal et secondaire de notre configuration sont, respectivement, 192.168.11.16/30 et 192.168.11.20/30. Dans la détermination de route ci-dessus, nous voyons à l’étape 3 que nous avons atteint 192.168.11.18, qui est l’IP de l’interface du MSEE principal. La présence de l’interface MSEE confirme que, comme prévu, notre chemin d’accès actuel passe par ExpressRoute.
Comme indiqué dans Réinitialiser les peerings de circuit ExpressRoute, utilisons les commandes PowerShell suivantes pour désactiver les peerings principal et secondaire du circuit ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Le temps de basculement dépend du temps de convergence BGP. Dans notre configuration, le basculement prend quelques secondes (moins de 10). Après le basculement, la répétition de la détermination de l’itinéraire affiche le chemin d’accès suivant :
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 * * * Request timed out.
3 6 ms 7 ms 9 ms 10.17.11.132
Trace complete.
Le résultat de la détermination de l’itinéraire confirme que la connexion de secours via le VPN S2S est active et peut assurer la continuité du service en cas d’échec des connexions ExpressRoute principale et secondaire. Pour effectuer le test de basculement, réactivez les connexions ExpressRoute et normalisez le flux de trafic à l’aide de l’ensemble de commandes suivant.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Pour confirmer que le trafic est rétabli sur ExpressRoute, répétez la détermination de route et vérifiez qu’elle passe par le peering privé ExpressRoute.
Étapes suivantes
ExpressRoute est conçu pour la haute disponibilité sans point de défaillance unique au sein du réseau Microsoft. Un circuit ExpressRoute est toujours limité à une seule région géographique et à un seul fournisseur de services. Le VPN S2S peut être une bonne solution de secours passive pour la récupération d’urgence à un circuit ExpressRoute. Pour garantir la fiabilité d’une solution de connexion de secours passive, il est important d’effectuer régulièrement un entretien de la configuration passive et une validation de la connexion. Surtout ne laissez pas la configuration VPN devenir obsolète et recommencez régulièrement (par exemple, chaque trimestre) les étapes de test de validation et de basculement décrites dans cet article pendant la fenêtre de maintenance.
Pour activer le monitoring et les alertes basées sur les métriques de passerelle VPN, consultez Configurer des alertes sur les métriques de passerelle VPN.
Pour accélérer la convergence BGP suite à un échec d’ExpressRoute, configurez BFD sur ExpressRoute.