Déployer des appliances virtuelles réseau à haute disponibilité

Cet article décrit les méthodes courantes de déploiement d’un ensemble d’appliances virtuelles réseau pour la haute disponibilité dans Azure. Une appliance virtuelle réseau contrôle généralement le flux de trafic entre les segments réseau qui ont différents niveaux de sécurité. Par exemple, vous pouvez utiliser une appliance virtuelle de réseau entre un réseau virtuel de périmètre et l’Internet public, ou pour connecter des emplacements externes à Azure via un réseau privé virtuel (VPN) ou des équipements WAN définis par logiciel (SD-WAN).

Cet article suppose que vous avez une compréhension de base de la mise en réseau Azure, des équilibreurs de charge Azure, du routage du trafic de réseau virtuel et des itinéraires définis par l’utilisateur (UDR).

De nombreux modèles de conception utilisent des NVAs pour inspecter le trafic entre différentes zones de sécurité. Ces modèles peuvent utiliser des appliances virtuelles réseau aux fins suivantes :

• Pour inspecter le trafic de sortie des machines virtuelles vers Internet et empêcher l’exfiltration des données.

• Pour inspecter le trafic d’entrée d’Internet vers des machines virtuelles et empêcher les attaques.

• Pour filtrer le trafic entre les machines virtuelles dans Azure afin d’empêcher les déplacements latéral de systèmes compromis.

• Pour filtrer le trafic entre les systèmes locaux et les machines virtuelles Azure, en particulier s’ils appartiennent à différents niveaux de sécurité. Par exemple, Azure héberge le réseau de périmètre, tandis que l’environnement local héberge les applications internes.

• Pour mettre fin aux tunnels VPN ou SD-WAN à partir d’emplacements externes, tels que des réseaux locaux ou d’autres clouds publics.

Vous pouvez ajouter les NVA suivantes à une conception Azure en utilisant les modèles de cet article :

• Pare-feu réseau
• Proxys inverses de couche 4
• Points de terminaison VPN IPsec (Internet Protocol Security)
• Appliances SD-WAN
• Proxys inverses basés sur le web qui ont des fonctionnalités de pare-feu d’applications web
• Proxys Internet pour restreindre les pages Internet accessibles à partir d’Azure
• Équilibreurs de charge de couche 7

Les appliances virtuelles réseau natives Azure, telles que Azure Firewall et Azure Application Gateway, utilisent les conceptions expliquées plus loin dans cet article. Vous devez comprendre ces options du point de vue de la conception et à des fins de résolution des problèmes réseau.

Les appliances virtuelles réseau nécessitent souvent une haute disponibilité, car elles contrôlent la communication entre les segments réseau. Si les NVAs deviennent indisponibles, le trafic réseau ne peut pas circuler et les applications cessent de fonctionner. Des pannes planifiées et imprévues arrêtent occasionnellement des instances d'appareil virtuel de réseau, comme des autres machines virtuelles dans Azure ou dans des autres nuages. Les instances NVA peuvent s'arrêter même si vous les configurez avec des SSD Premium d'Azure, qui fournissent un accord de niveau de service pour une instance unique dans Azure. Les applications hautement disponibles nécessitent au moins deux appliances virtuelles réseau pour garantir la connectivité.

Lorsque vous choisissez la meilleure option pour déployer une appliance virtuelle réseau dans un réseau virtuel Azure, l’aspect le plus important est de savoir si le fournisseur de l’appliance virtuelle réseau a évalué et validé sa conception. Le fournisseur doit également fournir la configuration de l’appliance virtuelle réseau requise pour intégrer l’appliance virtuelle réseau dans Azure. Si le fournisseur de l’appliance virtuelle réseau fournit plusieurs options de conception prises en charge, tenez compte des facteurs suivants pour prendre votre décision :

• Temps de convergence : Temps nécessaire à chaque conception pour rediriger le trafic loin d’une instance NVA ayant échoué

• Prise en charge de la topologie : configurations de l’appliance virtuelle réseau que chaque option de conception prend en charge, telles que les clusters NVA actif/actif, actif/en attente ou scale-out avec montée en puissance parallèle qui ont une unité supplémentaire pour la redondance

• Symétrie du trafic : Que ce soit une conception particulière qui force l'appliance virtuelle réseau (NVA) à effectuer une traduction d'adresses réseau source (SNAT) sur les paquets pour éviter le routage asymétrique, ou si la conception applique la symétrie du trafic par d'autres moyens.

Remarque

Cet article se concentre sur les conceptions en étoile. Cet article ne traite pas d’Azure Virtual WAN, car il contient des instructions plus prescriptives pour le déploiement d’appliances virtuelles réseau, selon qu’un hub Virtual WAN prend en charge une appliance virtuelle réseau spécifique. Pour plus d’informations, consultez Appliances virtuelles réseau dans un hub Virtual WAN.

Les sections suivantes décrivent les architectures courantes que vous pouvez utiliser pour intégrer des appliances virtuelles réseau dans un réseau en étoile.

Vue d’ensemble des architectures de haute disponibilité

Solution	Avantages	Considérations
Équilibreur de charge Azure	Cette solution prend en charge les configurations actives/actives et actives/en attente et les appliances virtuelles réseau avec un bon temps de convergence.	L’appliance virtuelle réseau doit fournir un port pour les sondes d’intégrité, en particulier pour les déploiements actifs/de secours. Pour les appliances avec état, telles que les pare-feu qui nécessitent la symétrie du trafic : il est nécessaire d'utiliser le SNAT pour les flux entrant et sortant de l'Internet.
Serveur de routage Azure	L’appliance virtuelle réseau doit prendre en charge le protocole BGP (Border Gateway Protocol). Cette solution prend en charge les appliances virtuelles réseau actives/actives, actives/en attente et avec scale-out.	La symétrie du trafic nécessite SNAT dans cette solution.
Équilibreur de charge de passerelle Azure	La symétrie du trafic est garantie sans SNAT. Les appliances virtuelles réseau peuvent être partagées entre les locataires. Cette solution dispose d’un bon temps de convergence et prend en charge les appliances virtuelles réseau actives/actives, actives/en attente et scale-out.	Cette solution prend en charge les flux vers et depuis Internet et ne prend pas en charge les flux East-West.
Adresse IP privée dynamique et UDR	NVA ne requiert pas de fonctionnalités spéciales. Cette solution garantit le trafic symétrique.	Cette solution est uniquement destinée aux conceptions actives/passives. Il a un temps de convergence élevé d’une à deux minutes.

Équilibreur de charge

Cette conception d’équilibreur de charge utilise deux équilibreurs de charge Azure pour exposer un cluster d’appliances virtuelles réseau au reste du réseau. L’approche convient à la fois aux appliances virtuelles réseau avec et sans état.

• Un équilibreur de charge interne redirige le trafic interne provenant d'Azure et des installations locales vers les NVAs. Cet équilibreur de charge interne est configuré avec des règles de ports à haute disponibilité afin que chaque port TCP (Transmission Control Protocol) et udp (User Datagram Protocol) soit redirigé vers les instances NVA.

• Un équilibreur de charge public expose les appliances virtuelles réseau à Internet. Les ports à haute disponibilité sont destinés au trafic entrant. Par conséquent, chaque port TCP/UDP doit être ouvert dans une règle d’équilibrage de charge dédiée.

Le diagramme suivant montre la séquence de tronçons que les paquets prennent d’Internet à un serveur d’applications dans un réseau virtuel spoke. Ces paquets traversent une appliance de pare-feu NVA pour contrôler le trafic vers et depuis l'Internet public, également appelé Trafic Nord-Sud.

Ce diagramme montre un hub et deux spokes. Le hub contient un sous-réseau de passerelle et un sous-réseau NVA. Le sous-réseau de passerelle contient un VPN ou une passerelle Azure ExpressRoute. Le sous-réseau de l’appliance virtuelle réseau contient un équilibreur de charge Azure interne et des appliances virtuelles réseau. Chaque spoke contient un serveur d’applications. Spoke2 a une note indiquant que la table de routes spoke 0.0.0.0/0 vers 10.0.0.36 et désactive la propagation de passerelle. Le trafic entrant transite de l'Internet public vers les NVAs via l'équilibreur de charge Azure public. Ce trafic transite ensuite vers le serveur d’applications dans Spoke2. Retournez les flux de trafic de ce serveur d’application vers les appliances virtuelles réseau via l’équilibreur de charge Azure interne. Ce trafic transite ensuite vers l’Internet public.

Téléchargez un fichier Visio de cette architecture.

Pour envoyer du trafic à partir de spokes vers l’Internet public via les appliances virtuelles réseau, cette conception utilise un UDR pour 0.0.0.0/0. Le tronçon suivant est l’adresse IP de l’équilibreur de charge interne.

Pour le trafic entre Azure et l’Internet public, chaque direction du flux de trafic traverse un autre équilibreur de charge Azure. Ce processus se produit même si l’appliance virtuelle réseau du pare-feu a une carte d’interface réseau unique pour les réseaux publics et internes, car le paquet d’entrée passe par l’équilibreur de charge Azure public et que le paquet de sortie passe par l’équilibreur de charge Azure interne. Les deux directions du flux passent par différents équilibreurs de charge. Par conséquent, si vous avez besoin d’une symétrie du trafic, les instances de l’appliance virtuelle réseau doivent effectuer une SNAT pour attirer le trafic de retour et garantir la symétrie du trafic. La plupart des pare-feu nécessitent une symétrie du trafic.

Le diagramme suivant montre comment utiliser la même conception d’équilibreur de charge pour inspecter le trafic entre les réseaux Azure et locaux, ou le trafic Est-Ouest, ce qui implique uniquement un équilibreur de charge interne. Vous pouvez également utiliser cette méthode pour envoyer le trafic entre les spokes via les appliances virtuelles réseau.

Ce diagramme montre un hub et deux spokes. Le hub contient un sous-réseau de passerelle et un sous-réseau NVA. Le sous-réseau de passerelle contient une passerelle VPN ou ExpressRoute. Le sous-réseau de l’appliance virtuelle réseau contient un équilibreur de charge Azure interne et des appliances virtuelles réseau. Chaque spoke contient un serveur d’applications. Spoke2 a une note indiquant que la table de routes spoke 0.0.0.0/0 vers 10.0.0.36 et désactive la propagation de passerelle. Le trafic entrant transite d’un emplacement local vers les appliances virtuelles réseau via la passerelle VPN ou ExpressRoute, puis l’équilibreur de charge Azure interne. Ce trafic transite ensuite vers le serveur d’applications dans Spoke2. Retournez les flux de trafic de ce serveur d’application vers les appliances virtuelles réseau via l’équilibreur de charge Azure interne. Ce trafic transite ensuite vers l’environnement local via la passerelle VPN ou ExpressRoute.

Dans les diagrammes précédents, spoke1 ne connaît pas la plage de spoke2. Par conséquent, l’UDR 0.0.0.0/0 envoie le trafic destiné à spoke2 à l’équilibreur de charge Azure interne de l’appliance virtuelle réseau.

Pour le trafic entre les réseaux locaux et Azure ou entre les machines virtuelles Azure, la symétrie du trafic est garantie dans les appliances virtuelles réseau à carte unique par l’équilibreur de charge Azure interne. Lorsque les deux directions d’un flux de trafic traversent le même équilibreur de charge Azure, l’équilibreur de charge sélectionne la même instance d’appliance virtuelle réseau pour les deux directions. Si une conception NVA double carte réseau a un équilibreur de charge interne pour chaque direction de communication, SNAT garantit la symétrie du trafic. Le diagramme de North-South précédent fournit un exemple de cette conception.

Dans cette conception, les appliances virtuelles réseau double carte doivent déterminer où envoyer des réponses aux vérifications d’intégrité de l’équilibreur de charge. Load Balancer utilise toujours la même adresse IP que la source pour les vérifications d’intégrité, c’est-à-dire 168.63.129.16. L’appliance virtuelle réseau doit renvoyer ces réponses de contrôle d’intégrité via la même interface sur laquelle elles ont été reçues. Ce processus nécessite généralement plusieurs tables de routage dans un système d’exploitation, car le routage basé sur la destination envoie les réponses via la même carte réseau.

L’équilibreur de charge Azure a une très bonne durée de convergence en cas de panne individuelle de l’appliance virtuelle réseau. Vous pouvez envoyer des sondes d’intégrité toutes les cinq secondes, et il faut trois sondes échouées pour déclarer une instance d'arrière-plan hors service. Par conséquent, il faut généralement 10 à 15 secondes pour que l’équilibreur de charge Azure converge le trafic vers une autre instance DVA.

Cette configuration prend en charge les configurations actives/actives et actives/de secours. Pour les configurations actives/de secours, les instances NVA doivent fournir un port TCP ou UDP ou un point de terminaison HTTP qui répond uniquement aux sondes d’intégrité de l’équilibreur de charge pour l’instance actuellement dans le rôle actif.

Équilibreurs de charge de couche 7

Une conception spécifique pour les dispositifs de sécurité remplace l’équilibreur de charge public Azure par un équilibreur de charge de couche 7 tel que l’Azure Application Gateway, qui est lui-même considéré comme une appliance virtuelle réseau.

Dans ce scénario, les appliances virtuelles réseau nécessitent uniquement un équilibreur de charge interne pour le trafic provenant des systèmes de charge de travail. Les appareils à deux cartes réseau utilisent parfois cette approche pour éviter les problèmes de routage avec les contrôles d’intégrité de l’équilibreur de charge Azure. Cette conception prend uniquement en charge les protocoles Layer-7 pris en charge par l’équilibreur de charge Layer-7, qui est généralement HTTP et HTTPS.

L’appliance virtuelle réseau doit gérer le trafic entrant pour les protocoles que l’équilibreur de charge de couche 7 ne prend pas en charge. L’appliance virtuelle réseau peut également gérer le trafic de sortie. Pour plus d’informations, consultez Pare-feu et passerelle d'application pour les réseaux virtuels.

Serveur de routage

Le serveur de routes est un service qui permet à une appliance virtuelle réseau d’interagir avec la mise en réseau définie par logiciel Azure via BGP. Les appliances virtuelles réseau apprennent quels préfixes d’adresse IP existent dans les réseaux virtuels Azure. Ils peuvent également injecter des itinéraires dans les tables de routage effectives des machines virtuelles dans Azure.

Ce diagramme montre un hub et deux spokes. Le hub contient un sous-réseau de passerelle, un sous-réseau NVA et un sous-réseau de serveur de routage. Le sous-réseau de passerelle contient une passerelle VPN ou ExpressRoute. Le sous-réseau de l’appliance virtuelle réseau contient deux appliances virtuelles réseau. Le sous-réseau du serveur de routage contient le serveur de routage. Chaque spoke contient un serveur d’applications. Spoke2 a une note indiquant que les routes effectives spoke sont 0.0.0.0/0 vers 10.0.0.37 et 0.0.0.0.0/0 vers 10.0.0.38. Le trafic entrant transite d’Internet public vers NVA1 via l’équilibreur de charge Azure public. Ce trafic transite ensuite vers le serveur d’applications dans Spoke2. Retournez les flux de trafic de ce serveur d’applications vers NVA1, puis vers l’Internet public. L’adjacency BGP connecte NVA1, NVA2 et Route Server. NVA2 et le serveur de routage sont connectés via eBGP.

Dans le diagramme précédent, chaque instance d’appliance virtuelle réseau se connecte au serveur de routage via BGP. Cette conception ne nécessite pas de table de routage dans les sous-réseaux satellites ; le serveur de routes gère les itinéraires que les appliances virtuelles de réseau publient. Si au moins deux itinéraires sont programmés sur les machines virtuelles Azure, ils utiliseront ECMP (Equal Cost MultiPathing) pour choisir l’une des instances d’appliance virtuelle réseau pour chaque flux de trafic. Par conséquent, vous devez inclure SNAT dans cette conception si vous avez besoin d’une symétrie du trafic.

Cette méthode d’insertion prend en charge les configurations actives/actives et actives/en attente. Dans une configuration active/active, toutes les appliances virtuelles réseau publient les mêmes itinéraires vers le serveur de routes. Dans une configuration active/en attente, une appliance virtuelle réseau publie des itinéraires avec un chemin d’accès de système autonome (AS) plus court que l’autre. Le serveur de routage prend en charge un maximum de huit adjacencies BGP. Par conséquent, si vous utilisez un cluster scale-out d’appliances virtuelles actives, cette conception prend en charge un maximum de huit instances d’appliance virtuelle réseau.

Cette configuration a un temps de convergence rapide. Les minuteurs de maintien et d’attente du BGP influencent le temps de convergence. Le routeur a des temporisateurs de maintien de connexion par défaut réglés sur 60 secondes et des temporisateurs de durée d'attente réglés sur 180 secondes. Mais les appliances réseau virtuelles peuvent négocier des minuteurs inférieurs pendant l’établissement de l’adjacence BGP. La définition de ces minuteurs trop bas peut entraîner des instabilités BGP.

Cette conception convient aux appliances virtuelles réseau qui doivent interagir avec le routage Azure. Les exemples incluent des appliances virtuelles réseau SD-WAN ou IPsec, qui ont généralement une bonne prise en charge BGP. Ces appliances virtuelles réseau doivent apprendre les préfixes configurés dans des réseaux virtuels Azure ou publier certains itinéraires via des peerings privés ExpressRoute. Ces types d’appliances sont généralement sans état, de sorte que la symétrie du trafic n’est pas un problème et SNAT n’est pas nécessaire.

Équilibreur de charge de passerelle

L’équilibreur de charge de passerelle permet d’insérer des appliances virtuelles dans le chemin de données sans avoir à acheminer le trafic à l’aide des UDR. Pour les machines virtuelles qui exposent leurs charges de travail via un équilibreur de charge Azure ou une adresse IP publique, vous pouvez rediriger le trafic entrant et sortant de manière transparente vers un cluster d’appliances virtuelles virtuelles situées dans un autre réseau virtuel. Le diagramme suivant montre le chemin d’accès que suivent les paquets pour le trafic entrant à partir de l’Internet public si les charges de travail exposent l’application via un équilibreur de charge Azure.

Ce diagramme montre un réseau virtuel NVA et un réseau virtuel d’application. Le réseau virtuel NVA contient l’équilibreur de charge de passerelle et les appliances virtuelles réseau. Le réseau virtuel d’application contient un serveur web. Le flux utilisateur passe d’Internet au serveur web via un équilibreur de charge Azure standard public. Le flux contrôlé par l'équilibreur de charge de passerelle (Gateway Load Balancer) passe de l'équilibreur de charge Azure standard public à l'équilibreur de charge de passerelle, puis aux appliances virtuelles réseau. Ce flux inverse les directions et va des appliances virtuelles réseau à l’équilibreur de charge de la passerelle, puis à l’équilibreur de charge standard public Azure.

Cette méthode d’injection NVA offre les avantages suivants :

• Cette méthode ne nécessite pas de SNAT pour garantir la symétrie du trafic.

• Vous pouvez utiliser les mêmes appliances virtuelles réseau pour inspecter le trafic vers et depuis différents réseaux virtuels, ce qui fournit une architecture mutualisée du point de vue de l’appliance virtuelle réseau.

• L’appairage de réseaux virtuels n’est pas nécessaire entre le réseau virtuel NVA et les réseaux virtuels de charge de travail, ce qui simplifie la configuration.

• Les UDR ne sont pas nécessaires dans le réseau virtuel de charge de travail, ce qui simplifie également la configuration.

Vous pouvez utiliser l’injection de service via Gateway Load Balancer pour le trafic entrant vers un équilibreur de charge public Azure, son trafic de retour et le trafic sortant d’Azure. Le trafic Est-Ouest entre les machines virtuelles Azure ne peut pas tirer parti de l’équilibreur de charge de passerelle pour l’injection d’une appliance virtuelle réseau.

Dans le cluster NVA, les sondes de vérification d'intégrité de l'équilibrageur de charge Azure détectent les défaillances dans les instances NVA individuelles, offrant ainsi un temps de convergence rapide de 10 à 15 secondes.

Adresse IP publique dynamique et gestion des UDR

L’objectif de cette conception est d’avoir une configuration qui fonctionne sans redondance de dispositif virtuel de réseau et peut être modifiée si le dispositif virtuel de réseau connaît une période d'inactivité. Le diagramme suivant montre comment une adresse IP publique Azure s’associe à une appliance virtuelle réseau active (NVA1 dans le diagramme). Les UDR dans les spokes utilisent l’adresse IP de l’appliance virtuelle réseau active (10.0.0.37) comme tronçon suivant.

Ce diagramme montre un hub et deux spokes. Le hub contient un sous-réseau de passerelle et un sous-réseau NVA. Le sous-réseau de passerelle contient une passerelle VPN ou ExpressRoute. Le sous-réseau de l’appliance virtuelle réseau contient deux appliances virtuelles réseau. NVA1 est marqué actif et NVA2 est en attente. Chaque spoke contient un serveur d’applications. Spoke2 a une note indiquant que la table de routes spoke 0.0.0.0/0 vers 10.0.0.37 et désactive la propagation de passerelle. Le trafic entrant transite d’Internet vers NVA1 via une adresse IP publique. Ce trafic transite ensuite vers Spoke2. Retournez les flux de trafic de Spoke2 vers NVA1, puis vers Internet.

Si l’appliance virtuelle réseau active n’est plus disponible, l’appliance virtuelle réseau de secours appelle l’API Azure pour mappper à nouveau l’adresse IP publique et les UDR spoke à elle-même ou prendre en charge l’adresse IP privée. Ces appels d’API peuvent prendre plusieurs minutes. Cette conception fournit le pire moment de convergence entre les options de cet article.

Cette conception prend uniquement en charge les configurations actives/de secours, ce qui peut entraîner des problèmes d’extensibilité. Si vous devez augmenter la bande passante prise en charge par vos appliances virtuelles réseau, vous devez effectuer un scale-up des deux instances.

Cette conception ne nécessite pas de SNAT pour garantir la symétrie du trafic, car une seule appliance virtuelle réseau est active à un moment donné.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

• Keith Mayer | Architecte de solution cloud principal
• Telmo Sampaio | Responsable de l’ingénierie du service principal
• Jose Moreno | Ingénieur principal

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étape suivante

• Réseaux de périmètre

Ressource associée

• Implémenter un réseau hybride sécurisé à l’aide du Pare-feu Azure