Phase de conception 1 : Connectivité avec les sites locaux

Article
10/04/2023

La connectivité avec les centres de données locaux s’inscrit comme la zone de conception la plus critique pour la mise en réseau Azure VMware Solution. Les exigences clés à traiter sont les suivantes :

Débit élevé : les migrations à partir d’environnements vSphere locaux et de solutions de récupération d’urgence exigent de déplacer rapidement d’importants volumes de données entre les sites locaux et les clouds privés Azure VMware Solution.
Faible latence : les applications distribuées peuvent nécessiter une faible latence pour les connexions entre les machines virtuelles Azure VMware Solution et les systèmes locaux.
Prévisibilité des performances : pour obtenir un débit et une latence prévisibles, les applications vitales pour l’entreprise déployées sur Azure VMware Solution peuvent nécessiter des services de connectivité dédiés (Azure ExpressRoute) entre les sites locaux et le réseau Microsoft.

Cet article décrit les options prises en charge par Azure VMware Solution pour la connectivité avec les sites locaux :

Service Global Reach d’ExpressRoute
VPN IPSec
Transit via un peering privé ExpressRoute

Les options sont présentées par ordre décroissant, en fonction de leur capacité à répondre aux exigences clés répertoriées précédemment. Une option ne doit être ignorée (et la suivante considérée) que si elle est en conflit avec les contraintes non négociables d’un scénario donné.

Cet organigramme revient sur le processus de choix d’une option de connectivité hybride pour Azure VMware Solution :

Service Global Reach d’ExpressRoute

ExpressRoute Global Reach est l’option de connectivité hybride par défaut prise en charge par Azure VMware Solution. Elle fournit, avec une complexité minimale, une connectivité de couche 3 entre un cloud privé Azure VMware Solution et un site distant connecté à un circuit ExpressRoute géré par le client. Vous pouvez également utiliser le circuit ExpressRoute géré par le client pour vous connecter aux services natifs Azure. Pour améliorer la sécurité ou réserver la bande passante, vous pouvez aussi déployer un circuit géré par le client distinct qui soit réservé au trafic Azure VMware Solution.

Le diagramme suivant illustre une topologie de réseau utilisant Global Reach pour la connectivité avec les sites locaux. Le trafic entre les clouds privés Azure VMware Solution et les sites locaux ne traverse pas les réseaux virtuels Azure.

Remarque

Pour une résilience maximale, deux circuits ExpressRoute gérés par le client dans différents emplacements de peering doivent être utilisés pour connecter des centres de données locaux au réseau principal Microsoft. Dans ce cas, chaque circuit ExpressRoute géré par le client doit disposer d’une connexion Global Reach au cloud privé Azure VMware Solution (et aux réseaux virtuels Azure). Consultez cet article pour obtenir des conseils sur les implémentations ExpressRoute résilientes.

Pour savoir comment connecter un cloud privé Azure VMware Solution à un circuit ExpressRoute géré par le client avec Global Reach, consultez la rubrique Appairer des environnements locaux à Azure VMware Solution.

La connectivité Global Reach répond pleinement aux trois exigences clés :

Débit élevé : ExpressRoute vous permet de vous connecter au réseau Microsoft depuis votre site sur des lignes dédiées (jusqu’à 10 Gbits/s pour ExpressRoute avec un fournisseur ou 100 Gbits/s pour ExpressRoute Direct).
Faible latence : Global Reach vous permet d’acheminer le trafic directement de la périphérie du réseau Microsoft vers les clusters vSphere Azure VMware Solution. Global Reach réduit le nombre de tronçons réseau entre les sites locaux et les clouds privés.
Prévisibilité des performances : lorsque vous utilisez ExpressRoute Global Reach, le trafic est routé sur des liens qui ne rencontrent aucun problème de congestion (jusqu’à la capacité maximale approvisionnée). Par conséquent, la durée aller-retour (RTT) entre les machines virtuelles exécutées sur Azure VMware Solution et les hôtes locaux reste constante au fil du temps.

Vous ne pouvez pas utiliser Global Reach dans les scénarios qui présentent une ou plusieurs des contraintes suivantes :

ExpressRoute Global Reach n’est pas disponible dans la région Azure du cloud privé Azure VMware Solution ou à l’emplacement de rencontre du circuit ExpressRoute géré par le client. Il n’existe aucune solution de contournement pour cette limitation. Consultez la rubrique À propos d’ExpressRoute Global Reach pour obtenir des informations à jour sur la disponibilité de Global Reach.
Il existe des exigences de sécurité réseau non négociables. Si vous ne pouvez pas déployer un appareil de pare-feu sur le côté local du circuit ExpressRoute géré par le client, l’utilisation de Global Reach expose tous les segments de réseau Azure VMware Solution (y compris les réseaux de gestion [gestion vCenter Server et NSX-T]) sur l’ensemble du réseau connecté au circuit. Ce problème se produit le plus souvent lorsque les circuits ExpressRoute gérés par le client sont implémentés sur des services réseau MPLS (également appelés modèle de connectivité Any-To-Any ExpressRoute). Ce scénario est représenté ci-dessous :

Lorsque la connectivité ExpressRoute est implémentée sur les IPVPN MPLS, vous ne pouvez pas déployer de pare-feu sur un emplacement unique pour inspecter tout le trafic vers et depuis Azure VMware Solution. En règle générale, les organisations qui utilisent des réseaux MPLS déploient des pare-feu dans de grands centres de données (et non dans tous leurs sites [qui peuvent être de petites succursales, des bureaux ou des magasins]).

VPN IPSec

Vous pouvez implémenter la connectivité entre les clouds privés Azure VMware Solution et les sites locaux en acheminant le trafic via un réseau virtuel de transit sur Azure. Le réseau de transit est connecté au cloud privé Azure VMware Solution via le circuit ExpressRoute géré. Le réseau virtuel de transit est connecté au site local via un VPN IPSec, comme représenté ci-dessous :

Vous pouvez appliquer des stratégies de sécurité pour les connexions entre les sites locaux et le cloud privé Azure VMware Solution (la ligne en pointillés dans le diagramme) en acheminant le trafic via un pare-feu, si l’appareil VPN ne fournit aucune fonctionnalité de pare-feu. Cette configuration nécessite Azure Virtual WAN avec intention de routage, comme indiqué dans la section Choisir où héberger les appareils virtuels sur Azure du présent article.

Avant d’implémenter la connectivité IPSec entre les sites locaux et les réseaux virtuels de transit, vous devez prendre trois décisions de conception :

Choisir le service réseau à utiliser comme sous-couche pour le tunnel IPSec. Les options disponibles sont les suivantes : connectivité Internet, peering Microsoft ExpressRoute et peering privé ExpressRoute.
Choisir où héberger les appareils virtuels qui terminent le tunnel IPSec côté Azure. Les options disponibles incluent les suivantes : réseaux virtuels gérés par le client et hubs Virtual WAN.
Choisir quel appareil virtuel doit terminer le tunnel IPSec côté Azure. Le choix de cet appareil détermine également la configuration Azure requise pour le routage du trafic entre le tunnel IPSec et le circuit géré Azure VMware Solution. Les options disponibles sont les suivantes : passerelle VPN Azure native et appliances virtuelles IPSec tierces (appliances virtuelles de réseau).

Cet organigramme récapitule le processus décisionnel :

Les critères de prise de décision sont décrits dans les sections suivantes.

Choisir un service réseau de superposition

Nous vous invitons vivement à étudier les trois options de superposition VPN dans l’ordre indiqué ci-dessous :

Connexion Internet. L’adresse IP publique affectée à l’appareil VPN hébergé sur le réseau virtuel de transit sert de point de terminaison distant du tunnel IPSec. En raison de sa faible complexité et de son coût, vous devez toujours tester et évaluer la connectivité Internet au regard de ses performances (débit IPSec réalisable). Vous ne devez ignorer cette option que lorsque les performances observées sont trop faibles ou incohérentes. Le diagramme suivant représente cette option.
Peering Microsoft ExpressRoute. Cette option fournit une connectivité de couche 3 aux points de terminaison publics Azure via des liens dédiés. Comme une connexion Internet, elle vous permet d’atteindre l’adresse IP publique d’un appareil VPN qui sert de point de terminaison distant du tunnel IPSec et est hébergée sur le réseau virtuel de transit. Vous ne devez ignorer cette option que lorsque les exigences de routage du peering Microsoft ne peuvent pas être satisfaites. Le diagramme suivant représente cette option.
Peering privé ExpressRoute. Cette option fournit une connectivité de couche 3 entre un site local et les réseaux virtuels Azure via des liens dédiés. Elle vous permet donc d’établir un tunnel IPSec du site local vers l’adresse IP privée d’un appareil VPN hébergé sur un réseau virtuel. Le peering privé ExpressRoute peut introduire des limitations de bande passante, car la passerelle ExpressRoute se trouve dans le chemin des données. Vous pouvez utiliser ExpressRoute FastPath pour résoudre ce problème. Le peering privé nécessite également une configuration de routage plus complexe côté local. Pour en savoir plus, consultez la rubrique Configurer une connexion VPN site à site via un peering privé ExpressRoute. Le diagramme suivant représente cette option.

Choisir où héberger les appareils virtuels sur Azure

Les options disponibles incluent les suivantes : réseaux virtuels gérés par le client et hubs Virtual WAN. Pour prendre cette décision, vous devez tenir compte des caractéristiques de l’environnement Azure préexistant (le cas échéant) et de la façon dont vous souhaitez hiérarchiser la réduction des efforts de gestion comparé à la capacité d’adaptation de la configuration en fonction de besoins spécifiques. Voici quelques points clés à prendre en compte.

Vous devez utiliser l’infrastructure réseau Azure préexistante pour la connectivité Azure VMware Solution. Si la région du cloud privé Azure VMware Solution comporte déjà un réseau hub-and-spoke géré par le client, vous devez déployer les appareils de terminaison IPSec dans le hub existant. Si la région du cloud privé Azure VMware Solution comporte déjà un réseau hub-and-spoke basé sur Virtual WAN, vous devez utiliser le hub Virtual WAN pour la terminaison IPSec.
Pour router le trafic entre un tunnel IPSec et le circuit géré ExpressRoute dans un réseau hub-and-spoke géré par le client, vous devez déployer une instance de serveur de routes Azure dans le réseau virtuel hub et le configurer pour autoriser le trafic branche à branche. Vous ne pouvez pas acheminer le trafic entre les clouds privés Azure VMware Solution et les sites locaux via des appareils de pare-feu déployés dans le réseau virtuel.
Les hubs Virtual WAN prennent en charge, en mode natif, le trafic de routage entre le tunnel IPSec connecté au site local et le circuit ExpressRoute géré par Azure VMware Solution.
Si vous utilisez Virtual WAN, vous pouvez configurer les stratégies de routage et d’intention de routage pour l’inspection du trafic. Vous pouvez utiliser le pare-feu Azure ou des solutions de sécurité tierces prises en charge par Virtual WAN. Nous vous invitons à examiner la disponibilité régionale et les limitations de l’intention de routage.

Choisir quel appareil virtuel doit terminer le tunnel IPSec

Le tunnel IPSec qui fournit une connectivité au site local peut être terminé par la passerelle VPN Azure ou par des appliances virtuelles de réseau tierces. Pour prendre cette décision, vous devez tenir compte des caractéristiques de l’environnement Azure préexistant (le cas échéant) et de la façon dont vous souhaitez hiérarchiser la réduction des efforts de gestion comparé à la capacité d’adaptation de la configuration en fonction de besoins spécifiques. Voici quelques points clés à prendre en compte.

Dans les deux types de réseaux hub-and-spoke (gérés par le client et basés sur Virtual WAN), vous pouvez utiliser la passerelle VPN Azure pour terminer les tunnels IPSec connectés aux sites locaux. Les passerelles VPN Azure sont gérées par plateforme et nécessitent donc un effort de gestion minimal. Vous pouvez utiliser des passerelles préexistantes, et ce même si elles prennent en charge d’autres scénarios de connectivité. Pour en savoir plus sur les paramètres pris en charge et les performances attendues, consulter ces articles :
Les appliances virtuelles de réseau tierces sont généralement utilisées pour terminer les tunnels depuis les sites locaux dans les situations suivantes :
- L’appliance virtuelle de réseau est le CPE (équipement local client) d’une solution SDWAN déployée à la fois sur Azure et sur le site local.
- L’appliance virtuelle de réseau est un pare-feu qui applique la stratégie de sécurité requise pour les connexions entre le site local et Azure VMware Solution.

L’utilisation d’appareils tiers peut offrir une plus grande flexibilité et permettre d’accéder à des fonctions réseau avancées qui ne sont pas prises en charge par les passerelles VPN natives. Cependant, cela augmente la complexité. La haute disponibilité relève de votre responsabilité. Vous devez déployer plusieurs instances.

Transit via un peering privé ExpressRoute

Le peering privé ExpressRoute est le choix le plus courant pour connecter un site local à un réseau virtuel Azure (ou un réseau hub-and-spoke) dans les scénarios professionnels. Le réseau virtuel Azure ou le réseau virtuel hub (dans les topologies hub-and-spoke) comporte une passerelle ExpressRoute configurée avec une connexion au circuit ExpressRoute. Cette configuration fournit une connectivité de couche 3 entre le réseau virtuel (ou l’ensemble du réseau hub-and-spoke) et le réseau du site local. Toutefois, elle ne fournit pas de connectivité de couche 3 aux clouds privés Azure VMware Solution connectés au même réseau virtuel (ou au réseau virtuel hub) via un circuit ExpressRoute géré. (Consultez la rubrique Clouds privés ExpressRoute Global Reach et Azure VMware Solution.)

Vous pouvez contourner cette limitation en déployant davantage d’appareils de routage dans le réseau virtuel Azure. Cela vous permet de router le trafic via des appliances virtuelles de réseau de pare-feu hébergées sur le réseau virtuel.

Le transit via un peering privé ExpressRoute peut sembler souhaitable, mais il augmente la complexité et affecte les performances. Vous ne devez l’envisager que lorsque les VPN ExpressRoute Global Reach et IPSec (décrits dans les sections précédentes) ne peuvent s’appliquer.

Il existe deux options d’implémentation :

Réseau virtuel unique. Lorsque vous utilisez cette option, les circuits gérés par le client et Azure VMware Solution sont connectés à la même passerelle ExpressRoute.
Réseau virtuel de transit auxiliaire. Lorsque vous utilisez cette option, le circuit ExpressRoute géré par le client qui fournit une connectivité au site local est connecté à la passerelle ExpressRoute (généralement préexistante) dans le réseau virtuel hub. Le circuit géré Azure VMware Solution est connecté à une autre passerelle ExpressRoute déployée dans un réseau virtuel de transit auxiliaire.

Les sections suivantes fournissent des détails sur ces deux options d’implémentation, en particulier sur :

Le compromis entre les performances, les coûts (ressources Azure requises) et la surcharge de gestion
L’implémentation du plan de contrôle (comment les routes sont échangées entre le site local et le cloud privé)
L’implémentation du plan de données (comment les paquets réseau sont routés entre le site local et le cloud privé)

Réseau virtuel unique

Lorsque vous utilisez une approche de réseau virtuel unique, le circuit géré du cloud privé Azure VMware Solution et le circuit appartenant au client sont connectés à la même passerelle ExpressRoute, généralement le réseau hub. Le trafic entre le cloud privé et le site local peut être routé via des appliances virtuelles de réseau de pare-feu déployées dans le réseau hub. L’architecture de réseau virtuel unique est représentée ci-dessous :

Le plan de contrôle et le plan de données sont implémentés comme décrit ci-dessous :

Plan de contrôle. Une passerelle ExpressRoute déployée dans le réseau virtuel Azure ne peut pas propager de routes entre le circuit géré Azure VMware Solution et le circuit ExpressRoute géré par le client. L’utilisation d’un serveur de routes Azure (avec le paramètre branche à branche activé) permet d’injecter (dans les deux circuits) des routes pour les super-réseaux qui incluent l’espace d’adressage du cloud privé Azure VMware Solution (réseaux de gestion et segments de charge de travail) et l’espace d’adressage local.

Les super-réseaux doivent être annoncés au lieu des préfixes exacts qui composent ces espaces d’adressage. En effet, ces préfixes exacts sont déjà annoncés dans la direction opposée par le cloud privé Azure VMware Solution et le site local. Vous pouvez utiliser des super-réseaux aussi volumineux que les préfixes RFC 1918 s’ils sont compatibles avec la configuration réseau des sites locaux. Dans la plupart des cas, vous devez plutôt utiliser les super-réseaux les plus petits, qui incluent l’espace d’adressage du cloud privé Azure VMware Solution et l’espace d’adressage local. Cela réduit les risques de conflits avec la configuration de routage des sites locaux.

Les routes des super-réseaux proviennent d’appliances virtuelles de réseau compatibles BGP. Les appliances virtuelles de réseau sont configurées pour établir une session BPG avec le serveur de routage Azure. Les appliances virtuelles de réseau font uniquement partie du plan de contrôle et ne routent pas le trafic réel entre le site local et le cloud privé Azure VMware Solution. Dans la figure précédente, l’implémentation du plan de contrôle est représentée par une ligne en pointillés.
Plan de données. L’implémentation du plan de contrôle décrite précédemment attire le trafic suivant vers la passerelle ExpressRoute :
- Trafic du site local vers le cloud privé Azure VMware Solution
- Trafic du cloud privé Azure VMware Solution vers le site local
Si aucune UDR n’est appliquée au GatewaySubnet, le trafic circule directement entre le site local et le cloud privé Azure VMware Solution. Vous pouvez router le trafic vers le tronçon suivant intermédiaire en appliquant des UDR au GatewaySubnet. Les appliances virtuelles de réseau qui appliquent des stratégies de sécurité réseau sur les connexions entre les sites locaux et les clouds privés en sont un exemple classique. Dans la figure précédente, l’implémentation du plan de données est représentée par une ligne continue.

Réseau virtuel auxiliaire

Vous pouvez utiliser un réseau virtuel auxiliaire pour héberger une deuxième passerelle ExpressRoute connectée uniquement au circuit géré du cloud privé Azure VMware Solution. Si vous utilisez cette approche, le circuit géré du cloud privé et le circuit géré par le client se connectent à différentes passerelles ExpressRoute. Deux instances de serveur de routes Azure sont utilisées pour annoncer les routes appropriées à chaque circuit et pour contrôler la propagation des routes entre le cloud privé et le site local. Vous n’avez pas besoin d’annoncer les super-réseaux comme c’est le cas avec l’option de réseau virtuel unique décrite à la section précédente. La surcharge de gestion des UDR dans le GatewaySubnet est également réduite. Cette approche vous permet de router le trafic entre le cloud privé et le site local via des appliances virtuelles de réseau de pare-feu dans le réseau virtuel hub. L’implémentation d’un réseau virtuel auxiliaire est représentée dans le diagramme ci-dessous :