Utilisez une conception à deux régions de la solution Azure VMware sans Global Reach
Cet article décrit les bonnes pratiques en matière de connectivité, de flux de trafic et de haute disponibilité lors du déploiement de la solution Azure VMware dans deux régions et de l’utilisation de Virtual WAN sécurisé avec intention de routage. Il fournit des conseils sur l’utilisation de cette conception sans Global Reach. Cet article décrit la topologie de Virtual WAN avec l’intention de routage pour les clouds privés Azure VMware Solution, les sites sur site et les ressources natives Azure. L’implémentation et la configuration de Virtual WAN sécurisé avec l’intention de routage ne sont pas couvertes dans cet article.
Si vous utilisez une région qui ne prend pas en charge Global Reach ou si vous avez une exigence de sécurité pour inspecter le trafic entre la solution Azure VMware et le site sur site au pare-feu du hub, vous devez ouvrir un ticket de support pour activer la transitivité ExpressRoute-ExpressRoute. Virtual WAN ne prend pas en charge la transitivité ExpressRoute-ExpressRoute par défaut. Pour plus d’informations, veuillez consulter la section Connectivité en transit entre les circuits ExpressRoute avec intention de routage.
Utilisez une conception Virtual WAN sécurisé à deux régions sans Global Reach
Seul le SKU Standard de Virtual WAN prend en charge Virtual WAN sécurisé avec l’intention de routage. Utilisez Virtual WAN sécurisé avec intention de routage pour envoyer tout le trafic internet et le trafic du réseau privé (RFC 1918) vers une solution de sécurité, telle qu’Azure Firewall, une appliance virtuelle de réseau non-Microsoft (NVA), ou une solution SaaS.
Ce scénario de hub a la configuration suivante :
Le réseau à deux régions possède une instance de Virtual WAN et deux hubs. Chaque région a un hub.
Chaque hub dispose de sa propre instance Azure Firewall déployée, ce qui en fait des hubs Virtual WAN sécurisés.
Les hubs Virtual WAN sécurisés ont l’intention de routage activée.
Ce scénario inclut également les composants suivants :
Chaque région dispose de son propre cloud privé Azure VMware Solution et d’un réseau virtuel Azure.
Un site sur site se connecte aux deux régions.
Remarque
Si vous utilisez des préfixes non RFC 1918 dans vos ressources connectées sur site, réseaux virtuels ou solution Azure VMware, spécifiez ces préfixes dans le champ Préfixes de trafic privé de la fonctionnalité d’intention de routage. Saisissez des routes résumées dans le champ Préfixes de trafic privé pour couvrir votre plage. N’entrez pas la plage exacte qui est annoncée à Virtual WAN, car cette spécification peut entraîner des problèmes de routage. Par exemple, si le circuit Azure ExpressRoute annonce 192.0.2.0/24 depuis le site sur site, entrez une plage CIDR /23 ou plus grande, par exemple 192.0.2.0/23. Pour plus d’informations, veuillez consulter la section Configurer l’intention de routage et les politiques via le portail Virtual WAN.
Remarque
Lorsque vous configurez Azure VMware Solution avec des hubs Virtual WAN sécurisés, définissez l’option de préférence de routage du hub sur AS Path pour garantir des résultats de routage optimaux sur le hub. Pour plus d’informations, consultez Préférences de routage du hub virtuel.
Le diagramme suivant montre un exemple de ce scénario.
La table suivante décrit la connectivité topologique dans le diagramme précédent.
| Connexion | Description |
|---|---|
| D | Connexion du cloud privé Azure VMware Solution à son hub régional local. |
| E | Connectivité sur site via ExpressRoute vers les deux hubs régionaux. |
| Interhub | Connexion interhub logique entre deux hubs déployés sous le même Virtual WAN. |
Flux de trafic dans Virtual WAN sécurisé à deux régions
Les sections suivantes décrivent les flux de trafic et la connectivité pour Azure VMware Solution, sur site, réseaux virtuels Azure et internet.
Connectivité des clouds privés Azure VMware Solution et flux de trafic
Le diagramme suivant montre les flux de trafic pour les deux clouds privés Azure VMware Solution.
La table suivante décrit la connectivité topologique dans le diagramme précédent.
| Numéro de flux de trafic | Source | Destination | Le pare-feu du hub Virtual WAN sécurisé inspecte-t-il ce trafic ? |
|---|---|---|---|
| 1 | Cloud Azure VMware Solution région 1 | Réseau virtuel 1 | Oui, via le pare-feu du hub 1 |
| 2 | Cloud Azure VMware Solution région 1 | Sur site | Oui, via le pare-feu du hub 1 |
| 3 | Cloud Azure VMware Solution région 1 | Réseau virtuel 2 | Oui, via le pare-feu du hub 1 puis via le pare-feu du hub 2 |
| 4 | Cloud Azure VMware Solution région 1 | Cloud Azure VMware Solution région 2 | Oui, via le pare-feu du hub 1 puis via le pare-feu du hub 2 |
| 5 | Cloud Azure VMware Solution région 2 | Réseau virtuel 1 | Oui, via le pare-feu du hub 2 puis via le pare-feu du hub 1 |
| 6 | Cloud Azure VMware Solution région 2 | Réseau virtuel 2 | Oui, via le pare-feu du hub 2 |
| 7 | Cloud Azure VMware Solution région 2 | Sur site | Oui, via le pare-feu du hub 2 |
Chaque cloud privé Azure VMware Solution se connecte au hub via la connexion ExpressRoute D.
Lorsque vous activez la transitivité ExpressRoute-ExpressRoute sur le hub sécurisé et que vous activez l’intention de routage, le hub sécurisé envoie les adresses RFC 1918 par défaut (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) à la solution Azure VMware via la connexion D. En plus des adresses RFC 1918 par défaut, Azure VMware Solution apprend des routes plus spécifiques des réseaux virtuels Azure et des réseaux de succursales, tels que S2S VPN, P2S VPN et SD-WAN, qui se connectent aux deux hubs. Les deux clouds privés Azure VMware Solution n’apprennent pas de routes spécifiques depuis les réseaux sur site.
Pour router le trafic vers les réseaux sur site, Azure VMware Solution utilise les adresses RFC 1918 par défaut qu’il apprend via la connexion D depuis son hub régional local. Ce trafic transite par le pare-feu du hub régional local. Le pare-feu du hub utilise les routes spécifiques des réseaux sur site pour router le trafic vers les destinations via la connexion E. Le trafic provenant de tout cloud privé Azure VMware Solution vers des réseaux virtuels transite par le pare-feu du hub.
Connectivité sur site et flux de trafic
Le diagramme suivant montre les flux de trafic pour la connectivité sur site.
La table suivante décrit la connectivité topologique dans le diagramme précédent.
| Numéro de flux de trafic | Source | Destination | Le pare-feu du hub Virtual WAN sécurisé inspecte-t-il ce trafic ? |
|---|---|---|---|
| 2 | Sur site | Cloud Azure VMware Solution région 1 | Oui, via le pare-feu du hub 1 |
| 7 | Sur site | Cloud Azure VMware Solution région 2 | Oui, via le pare-feu du hub 2 |
| 8 | Sur site | Réseau virtuel 1 | Oui, via le pare-feu du hub 1 |
| 9 | Sur site | Réseau virtuel 2 | Oui, via le pare-feu du hub 2 |
Le site sur site se connecte aux deux hubs via la connexion ExpressRoute E.
Lorsque vous activez la transitivité ExpressRoute-ExpressRoute sur les deux hubs sécurisés et que vous activez l’intention de routage, chaque hub sécurisé envoie les adresses RFC 1918 par défaut (10.0.0.0/8, 172.16.0.0/12, et 192.168.0.0/16) vers le site sur site via la connexion E. En plus des adresses RFC 1918 par défaut, le site sur site apprend des routes plus spécifiques depuis les réseaux virtuels Azure et les réseaux de succursales, tels que S2S VPN, P2S VPN et SD-WAN, qui se connectent aux deux hubs.
Le site sur site n’apprend pas les routes spécifiques des clouds privés Azure VMware Solution. Le site sur site apprend les adresses RFC 1918 par défaut des deux hubs via la connexion E. Le site sur site route vers les deux clouds privés Azure VMware Solution via les adresses RFC 1918 par défaut qu’il apprend via la connexion E.
Remarque
Vous devez ajouter des routes spécifiques sur les deux hubs. Si vous n’ajoutez pas de routes spécifiques sur les hubs, vous pouvez introduire un routage sous-optimal car le site sur site utilise le routage ECMP (Equal-Cost Multi-Path) entre les connexions E pour le trafic à destination d’un cloud privé Azure VMware Solution. En conséquence, le trafic entre le site sur site et un cloud privé Azure VMware Solution peut rencontrer des problèmes de latence, de performances ou de pertes de paquets.
Pour annoncer une route plus spécifique vers le site sur site, spécifiez ces préfixes dans le champ Préfixes de trafic privé de la fonctionnalité d’intention de routage. Pour plus d’informations, veuillez consulter la section Configurer l’intention de routage et les politiques via le portail Virtual WAN. Vous devez ajouter une route résumée qui englobe à la fois votre bloc /22 de la solution Azure VMware et vos sous-réseaux Azure VMware Solution. Si vous ajoutez le même préfixe exact ou un préfixe plus spécifique au lieu d’une route résumée, vous introduisez des problèmes de routage au sein de l’environnement Azure. N’incluez que des routes résumées dans le champ Préfixes de trafic privé.
Comme illustré dans le diagramme, le cloud privé Azure VMware Solution 1 inclut des sous-réseaux de charge de travail allant de 10.10.0.0/24 à 10.10.7.0/24. Sur le hub 1, la route résumée 10.10.0.0/21 est ajoutée au champ Préfixes de trafic privé car elle englobe les huit sous-réseaux. De plus, sur le hub 1, la route résumée 10.150.0.0/22 est ajoutée au champ Préfixes de trafic privé pour couvrir le bloc de gestion Azure VMware Solution. Les routes résumées 10.10.0.0/21 et 10.150.0.0/22 sont annoncées au site sur site via la connexion E afin que le site sur site ait une route plus spécifique plutôt que 10.0.0.0/8.
Le cloud privé Azure VMware Solution 2 inclut des sous-réseaux de charge de travail allant de 10.20.0.0/24 à 10.20.7.0/24. Sur le hub 2, la route résumée 10.20.0.0/21 est ajoutée au champ Préfixes de trafic privé car elle englobe les huit sous-réseaux. De plus, sur le hub 2, la route résumée 10.250.0.0/22 est ajoutée au champ Préfixes de trafic privé pour couvrir le bloc de gestion Azure VMware Solution. Les routes résumées 10.20.0.0/21 et 10.250.0.0/22 sont annoncées au site sur site via la connexion E afin que le site sur site ait une route plus spécifique plutôt que 10.0.0.0/8.
Vous pouvez ajouter l’intégralité du bloc de gestion /22 de la solution Azure VMware dans le champ Préfixes de trafic privé car Azure VMware Solution n’annonce pas le bloc /22 exact en retour vers Azure. Azure VMware Solution annonce des routes plus spécifiques.
Lorsque vous activez la transitivité ExpressRoute-ExpressRoute sur le hub, il envoie les adresses RFC 1918 par défaut vers votre réseau sur site. N’annoncez pas les préfixes RFC 1918 exacts en retour vers Azure. Les mêmes routes exactes peuvent créer des problèmes de routage au sein d’Azure. Au lieu de cela, vous devez annoncer des routes plus spécifiques en retour vers Azure pour vos réseaux sur site.
Remarque
Si vous annoncez les adresses RFC 1918 par défaut depuis le site sur site vers Azure et que vous souhaitez continuer cette pratique, vous devez diviser chaque plage RFC 1918 en deux sous-plages égales et annoncer ces sous-plages en retour vers Azure. Les sous-plages sont 10.0.0.0/9, 10.128.0.0/9, 172.16.0.0/13, 172.24.0.0/13, 192.168.0.0/17, et 192.168.128.0/17.
Connectivité des réseaux virtuels Azure et flux de trafic
Le diagramme suivant montre les flux de trafic pour les réseaux virtuels Azure.
La table suivante décrit les flux de trafic dans le diagramme précédent.
| Numéro de flux de trafic | Source | Destination | Le pare-feu du hub Virtual WAN sécurisé inspecte-t-il ce trafic ? |
|---|---|---|---|
| 1 | Réseau virtuel 1 | Cloud Azure VMware Solution région 1 | Oui, via le pare-feu du hub 1 |
| 3 | Réseau virtuel 2 | Cloud Azure VMware Solution région 1 | Oui, via le pare-feu du hub 2 puis le pare-feu du hub 1 |
| 5 | Réseau virtuel 1 | Cloud Azure VMware Solution région 2 | Oui, via le pare-feu du hub 1 puis le pare-feu du hub 2 |
| 6 | Réseau virtuel 2 | Cloud Azure VMware Solution région 2 | Oui, via le pare-feu du hub 2 |
| 8 | Réseau virtuel 1 | Sur site | Oui, via le pare-feu du hub 1 |
| 9 | Réseau virtuel 2 | Sur site | Oui, via le pare-feu du hub 2 |
| 10 | Réseau virtuel 1 | Réseau virtuel 2 | Oui, via le pare-feu du hub 1 puis le pare-feu du hub 2 |
| 10 | Réseau virtuel 2 | Réseau virtuel 1 | Oui, via le pare-feu du hub 2 puis le pare-feu du hub 1 |
Chaque réseau virtuel est directement appairé à son hub régional.
Le diagramme montre comment toutes les ressources natives Azure dans les deux réseaux virtuels apprennent leurs routes effectives. Lorsque vous activez l’intention de routage, le hub 1 et le hub 2 envoient les adresses RFC 1918 par défaut à leurs réseaux virtuels appairés. Les ressources natives Azure dans les réseaux virtuels n’apprennent pas de routes spécifiques en dehors de leur réseau virtuel.
Lorsque vous activez l’intention de routage, toutes les ressources du réseau virtuel apprennent l’adresse RFC 1918 par défaut et utilisent le pare-feu de leur hub régional comme prochain saut. Les clouds privés Azure VMware Solution communiquent entre eux via la connexion D en passant par le pare-feu de leur hub régional local. À partir de là, ils traversent l’interhub du WAN virtuel et subissent une inspection au pare-feu du hub transrégional. Les clouds privés Azure VMware Solution communiquent également avec le site sur site via la connexion D en passant par le pare-feu de leur hub régional local. Tout le trafic qui entre et sort des réseaux virtuels transite par les pare-feux de leur hub régional.
Connectivité Internet
Cette section décrit comment fournir une connectivité internet pour les ressources natives Azure dans les réseaux virtuels et les clouds privés Azure VMware Solution dans les deux régions. Pour plus d’informations, consultez Considérations relatives à la conception de la connectivité Internet. Vous pouvez utiliser les options suivantes pour fournir une connectivité internet à Azure VMware Solution.
- Option 1 : Service internet hébergé par Azure
- Option 2 : Traduction d’adresses réseau (SNAT) gérée par la solution Azure VMware
- Option 3 : Adresse IPv4 publique Azure vers la passerelle de NSX-T Data Center
Une conception Virtual WAN à deux régions avec intention de routage prend en charge toutes les options, mais nous recommandons l’option 1. Le scénario plus loin dans cet article utilise l’option 1 pour fournir la connectivité internet. L’option 1 fonctionne le mieux avec Virtual WAN sécurisé car elle est facile à inspecter, déployer et gérer.
Lorsque vous activez l’intention de routage sur les deux hubs sécurisés, elle annonce les adresses RFC 1918 aux réseaux virtuels directement appairés. Mais vous pouvez également annoncer une route par défaut 0.0.0.0/0 pour la connectivité internet aux ressources en aval. Lorsque vous activez l’intention de routage, vous pouvez générer une route par défaut depuis les deux pare-feux de hub. Cette route par défaut est annoncée à ses réseaux virtuels directement appairés et à sa solution Azure VMware Solution directement connectée.
Connectivité internet Azure VMware Solution et réseaux virtuels
Le diagramme suivant montre les flux de trafic pour les clouds privés Azure VMware Solution et les réseaux virtuels.
La table suivante décrit les flux de trafic dans le diagramme précédent.
| Numéro de flux de trafic | Source | Destination | Le pare-feu du hub Virtual WAN sécurisé inspecte-t-il ce trafic ? |
|---|---|---|---|
| 11 | Cloud Azure VMware Solution région 1 | Internet | Oui, via le pare-feu du hub 1 |
| 12 | Réseau virtuel 2 | Internet | Oui, via le pare-feu du hub 2 |
| 13 | Réseau virtuel 1 | Internet | Oui, via le pare-feu du hub 1 |
| 14 | Cloud Azure VMware Solution région 2 | Internet | Oui, via le pare-feu du hub 2 |
Lorsque vous activez l’intention de routage pour le trafic internet, par défaut, le hub sécurisé Virtual WAN n’annonce pas la route par défaut sur les circuits ExpressRoute. Pour vous assurer que la route par défaut se propage à la solution Azure VMware Solution directement connectée depuis Virtual WAN, vous devez activer la propagation de la route par défaut sur vos circuits ExpressRoute de la solution Azure VMware Solution. Pour plus d’informations, consultez la section Annonce de la route par défaut 0.0.0.0/0 vers les points de terminaison.
Après avoir activé la propagation de la route par défaut, la connexion D annonce la route par défaut 0.0.0.0/0 depuis le hub. Ne pas activer ce paramètre pour les circuits ExpressRoute sur site. Nous vous recommandons de mettre en place un filtre BGP (Border Gateway Protocol) sur votre équipement sur site pour empêcher l’apprentissage de la route par défaut. Un filtre BGP ajoute une couche supplémentaire de protection et garantit que votre configuration n’affecte pas la connectivité internet sur site.
Lorsque vous activez l’intention de routage pour l’accès à internet, les deux hubs régionaux génèrent une route par défaut et l’annoncent à leurs connexions réseau virtuel appairées au hub. Notez que dans les cartes d’interface réseau (NIC) des machines virtuelles dans le réseau virtuel, le prochain saut pour 0.0.0.0/0 est le pare-feu du hub. Pour trouver le prochain saut, sélectionnez Routes effectives dans la NIC. La route par défaut n’est pas annoncée entre les hubs régionaux via le lien interhub. Par conséquent, les réseaux virtuels utilisent leur hub régional local pour accéder à internet, et ils n’ont pas de connectivité internet de secours vers le hub transrégional.
Résilience de l’accès internet pour Azure VMware Solution
Lorsque vous n’utilisez pas Global Reach dans une conception à deux régions, la connectivité internet sortante ne dispose pas de redondance car chaque cloud privé Azure VMware Solution apprend la route par défaut depuis son hub régional local et n’est pas directement connecté à son hub transrégional. Si une panne régionale affecte le hub régional local, utilisez l’une des configurations manuelles suivantes pour obtenir une redondance internet.
Option 1 :
Utilisez cette option uniquement pour l’accès internet sortant. Lors d’une panne régionale locale, si vous avez besoin d’un accès internet sortant pour votre charge de travail Azure VMware Solution, utilisez le SNAT géré par la solution Azure VMware. Cette solution offre un accès simple et rapide. Pour plus d’informations, veuillez consulter la section Activer le SNAT géré pour les charges de travail Azure VMware Solution.
Option 2 :
Utilisez cette option pour l’accès internet entrant et sortant. Lors d’une panne régionale locale, si vous avez besoin à la fois d’un accès internet entrant et sortant pour votre cloud Azure VMware Solution, utilisez la méthode suivante.
Supprimez la connexion qui va de la solution Azure VMware à votre hub régional local (connexion D dans les diagrammes).
Dans le portail Azure, sélectionnez Azure VMware Solution et supprimez la clé d’autorisation que vous avez créée pour la connexion D.
Créez une nouvelle connexion vers le hub transrégional.
Pour gérer le trafic entrant, envisagez d’utiliser Azure Front Door ou Azure Traffic Manager pour maintenir une haute disponibilité régionale.
Utilisez VMware HCX Mobility Optimized Networking (MON) sans Global Reach
Vous pouvez activer HCX Mobility Optimized Networking (MON) lorsque vous utilisez l’extension réseau HCX. MON fournit un routage de trafic optimal dans certains scénarios pour éviter que les réseaux ne se chevauchent ou ne bouclent entre les ressources sur site et dans le cloud sur des réseaux étendus.
Trafic sortant d’Azure VMware Solution
Lorsque vous activez MON pour un réseau étendu spécifique et une machine virtuelle, le flux de trafic change. Après avoir mis en œuvre MON, le trafic sortant de la machine virtuelle ne revient pas vers le site sur site. Au lieu de cela, il contourne le tunnel IPSec de l’extension réseau. Le trafic de la machine virtuelle sort du NSX-T Tier-1 gateway de la solution Azure VMware Solution, va vers le NSX-T Tier-0 gateway, puis vers Virtual WAN.
Trafic entrant vers Azure VMware Solution
Lorsque vous activez MON pour un réseau étendu spécifique et une machine virtuelle, vous introduisez les changements suivants. Depuis NSX-T Azure VMware Solution, MON injecte une route d’hôte /32 en retour vers Virtual WAN. Virtual WAN annonce cette route /32 en retour vers le site sur site, les réseaux virtuels et les réseaux de succursales. Cette route d’hôte /32 garantit que le trafic provenant du site sur site, des réseaux virtuels et des réseaux de succursales n’utilise pas le tunnel IPSec de l’extension réseau lorsque le trafic se dirige vers la machine virtuelle activée par MON. Le trafic provenant des réseaux sources se dirige directement vers la machine virtuelle activée par MON car elle apprend la route /32.
Limitation HCX MON pour Virtual WAN sécurisé sans Global Reach
Lorsque vous activez la transitivité ExpressRoute-ExpressRoute sur le hub sécurisé et que vous activez l’intention de routage, le hub sécurisé envoie les adresses RFC 1918 par défaut à la fois au site sur site et à la solution Azure VMware. En plus des adresses RFC 1918 par défaut, le site sur site et la solution Azure VMware apprennent des routes plus spécifiques des réseaux virtuels Azure et des réseaux de succursales qui se connectent au hub.
Cependant, les réseaux sur site n’apprennent pas de routes spécifiques depuis la solution Azure VMware, et la solution Azure VMware n’apprend pas de routes spécifiques depuis les réseaux sur site. Au lieu de cela, les deux environnements se reposent sur les adresses RFC 1918 par défaut pour faciliter le routage retour l’un vers l’autre via le pare-feu du hub. Par conséquent, les routes plus spécifiques, telles que les routes d’hôte MON, ne sont pas annoncées du circuit ExpressRoute Azure VMware Solution vers le circuit ExpressRoute basé sur le site sur site. L’inverse est également vrai. L’incapacité d’apprendre des routes spécifiques introduit des flux de trafic asymétriques. Le trafic sortant d’Azure VMware Solution passe par le NSX-T Tier-0 gateway, mais le trafic retour provenant du site sur site revient via le tunnel IPSec de l’extension réseau.
Corriger l’asymétrie du trafic
Pour corriger l’asymétrie du trafic, vous devez ajuster les routes de la politique MON. Les routes de la politique MON déterminent quel trafic retourne vers la passerelle sur site via une extension L2. Elles décident également quel trafic passe par le NSX-T Tier-0 gateway de la solution Azure VMware.
Si une adresse IP de destination correspond et que vous la définissez sur autoriser dans la configuration de la politique MON, deux actions se produisent. Premièrement, le système identifie le paquet. Deuxièmement, le système envoie le paquet vers la passerelle sur site via l’appliance d’extension réseau.
Si une adresse IP de destination ne correspond pas ou que vous la définissez sur refuser dans la politique MON, le système envoie le paquet vers le NSX-T Tier-0 gateway de la solution Azure VMware pour le routage.
Le tableau suivant décrit les routes de politique HCX.
| Network (Réseau) | Rediriger vers le pair | Remarque |
|---|---|---|
| Espace d’adressage de réseau virtuel Azure | Deny | Inclure explicitement les plages d’adresses pour tous vos réseaux virtuels. Le trafic destiné à Azure est dirigé vers l’extérieur via Azure VMware Solution et ne revient pas au réseau sur site. |
| Espaces d’adresses RFC 1918 par défaut | Autoriser | Ajoutez les adresses RFC 1918 par défaut. Cette configuration garantit que tout trafic ne correspondant pas aux critères précédents est redirigé vers le réseau sur site. Si votre configuration sur site utilise des adresses qui ne font pas partie de RFC 1918, vous devez inclure explicitement ces plages. |
| Espace d’adresses 0.0.0.0/0 | Deny | Les adresses non couvertes par RFC 1918, telles que les adresses IP accessibles sur internet, ou le trafic ne correspondant pas aux entrées spécifiées, sortent directement via Azure VMware Solution et ne sont pas redirigées vers le réseau sur site. |