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

Cet article présente les options les plus courantes de déploiement d'un ensemble d'appliances virtuelles réseau pour la haute disponibilité dans Azure. Un appliance virtuelle réseau permet généralement de contrôler le flux du trafic entre les segments réseau classés avec différents niveaux de sécurité, par exemple entre un réseau virtuel de zone DMZ et l’Internet public.

Il existe un certain nombre de modèles de conception où les appliances virtuelles réseau permettent d’inspecter le trafic entre différentes zones de sécurité, par exemple :

• pour inspecter le trafic de sortie des machines virtuelles vers Internet et empêcher l’exfiltration de données ;
• pour inspecter le trafic d’entrée d’Internet vers les machines virtuelles et empêcher les attaques ;
• pour filtrer le trafic entre les machines virtuelles dans Azure afin d’éviter les déplacements latéraux des systèmes compromis ;
• pour filtrer le trafic entre les systèmes locaux et les machines virtuelles Azure s’ils sont considérés comme appartenant à des niveaux de sécurité différents. (Par exemple, si Azure héberge la zone DMZ et les applications internes en local.)

Il existe de nombreux exemples d’appliances virtuelles réseau, notamment les pare-feux réseau, les proxys inversés de couche 4, les points de terminaison VPN IPsec, les proxys inversés basés sur le web avec des fonctionnalités de pare-feu d’applications web, les proxys Internet pour restreindre les pages Internet accessibles à partir d’Azure, les équilibreurs de charge de couche 7, etc. Ils peuvent tous être insérés dans une conception Azure avec les modèles décrits dans cet article. Même les appliances virtuelles réseau internes Azure, telles que le pare-feu Azure et Azure Application Gateway, utilisent les conceptions décrites plus loin dans cet article. La compréhension de ces options est essentielle à la fois du point de vue de la conception et de la résolution des problèmes réseau.

La première question à laquelle vous devez répondre est la raison pour laquelle une haute disponibilité est requise pour les appliances virtuelles réseau. Cela s’explique par le fait que ces appareils contrôlent la communication entre les segments réseau. S’ils ne sont pas disponibles, le trafic réseau ne peut pas être transmis et les applications cessent de fonctionner. Les interruptions planifiées et non planifiées peuvent et vont occasionnellement entraîner l’arrêt des instances d’appliance virtuelle réseau (comme n’importe quelle autre machine virtuelle dans Azure ou dans tout autre cloud). Les instances sont arrêtées, même si ces appliances virtuelles réseau sont configurées avec des disques managés Premium pour fournir un contrat SLA à instance unique dans Azure. Par conséquent, les applications hautement disponibles nécessitent au moins une deuxième appliance virtuelle réseau qui peut garantir la connectivité.

Conditions préalables : cet article suppose une connaissance élémentaire de la mise en réseau Azure, des équilibreurs de charge Azure et du routage du trafic de réseau virtuel (UDR).

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 à prendre en compte est de savoir si le fournisseur d’appliances virtuelles réseau a approuvé et validé cette conception spécifique. Le fournisseur doit également fournir la configuration d’appliance virtuelle réseau nécessaire pour intégrer l’appliance virtuelle réseau à Azure. Si le fournisseur d’appliance virtuelle réseau offre d’autres alternatives que les options de conception prises en charge pour une appliance virtuelle réseau, ces facteurs peuvent influencer la décision :

• Temps de convergence : combien de temps faut-il pour que chaque conception dirige le trafic à partir d’une instance d’appliance virtuelle réseau en échec ?
• Prise en charge de la topologie : quelles sont les configurations d’appliance virtuelle réseau prises en charge par chaque option de conception ? Clusters d’appliance virtuelle réseau actifs/actifs, actifs/en attente, avec scale-out avec une redondance de n+1 ?
• Symétrie du trafic : une conception particulière oblige-t-elle l’appliance virtuelle réseau à effectuer des traductions d’adresses réseau (SNAT) sources sur les paquets pour éviter le routage asymétrique ? Ou la symétrie du trafic est-elle appliquée par d’autres moyens ?

Les sections suivantes du document décrivent les architectures les plus courantes utilisées pour intégrer des appliances virtuelles réseau dans un réseau hub-and-spoke.

Vue d'ensemble des architectures haute disponibilité

Les architectures suivantes décrivent les ressources et la configuration nécessaire pour des appliances virtuelles réseau hautement disponibles :

Conception d’équilibreur de charge

Cette conception utilise deux équilibreurs de charge Azure pour exposer un cluster d’appliances virtuelles réseau au reste du réseau :

• Un équilibreur de charge interne permet de rediriger le trafic interne à partir d’Azure et de l’emplacement local vers les appliances virtuelles réseau. Cet équilibreur de charge interne est configuré avec des règles de ports haute disponibilité, de sorte que chaque port TCP/UDP est redirigé vers les instances d’appliance virtuelle réseau.
• Un équilibreur de charge public expose les appliances virtuelles réseau à Internet. Comme les ports HA sont destinés au trafic entrant, chaque port TCP/UDP individuel doit être ouvert dans une règle d’équilibrage de charge dédiée.

Le diagramme suivant décrit la séquence de tronçons que les paquets d’Internet vers un serveur d’applications dans un réseau virtuel spoke suivent :

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

Le mécanisme d’envoi du trafic de rayons vers l’Internet public par le biais des appliances virtuelles réseau est un itinéraire défini par l’utilisateur pour 0.0.0.0/0 avec l’adresse IP de l’équilibreur de charge interne du tronçon suivant.

Pour le trafic entre Azure et l’Internet public, chaque direction du flux de trafic traverse un équilibreur de charge Azure différent (le paquet d’entrée via l’équilibreur de charge Azure public et le paquet de sortie via l’équilibreur de charge Azure interne). Par conséquent, si la symétrie du trafic est nécessaire, la traduction d’adresses réseau source (SNAT) doit être effectuée par les instances d’appliance virtuelle réseau pour attirer le trafic de retour et éviter l’asymétrie du trafic.

Cette conception peut également être utilisée pour inspecter le trafic entre les réseaux Azure et locaux :

Le mécanisme d’envoi du trafic entre les rayons via les appliances virtuelles réseau est exactement le même, donc aucun diagramme supplémentaire n’est fourni. Dans les exemples de diagrammes ci-dessus, étant donné que rayon1 ne connaît pas la plage de rayon2, l’UDR 0.0.0.0/0 envoie le trafic adressé à rayon2 à l’équilibreur de charge Azure interne de l’appliance virtuelle réseau.

Pour le trafic entre des réseaux locaux et Azure ou entre des machines virtuelles Azure, la symétrie du trafic est garantie par l’équilibreur de charge Azure interne : lorsque les deux directions d’un flux de trafic traversent le même équilibreur de charge Azure, la même instance d’appliance virtuelle réseau est choisie.

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. Étant donné que les sondes d’intégrité peuvent être envoyées toutes les 5 secondes et qu’il faut 3 sondes ayant échoué pour déclarer une instance backend hors service, il faut généralement 10 à 15 secondes pour que l’équilibreur de charge Azure converge le trafic vers une instance d’appliance virtuelle réseau différente.

Ce programme d’installation prend en charge les configurations actif/actif et actif/en attente. Toutefois, pour les configurations actif/en attente, les instances d’appliance virtuelle réseau doivent offrir un port TCP/UDP ou un point de terminaison HTTP qui ne répond pas aux sondes d’intégrité de l’équilibreur de charge, sauf si l’instance est dans le rôle actif.

Utilisation d’équilibreurs de charge L7

Un cas particulier de cette conception consiste à remplacer l’équilibreur de charge Azure public par un équilibreur de charge de couche 7, tel que Azure Application Gateway (qui peut être considéré comme une appliance virtuelle réseau autonome). Dans ce cas, les appliances virtuelles réseau ne nécessitent qu’un équilibreur de charge interne face à elles, étant donné que le trafic provenant d’Application Gateway sera approvisionné à partir du réseau virtuel et que l’asymétrie du trafic n’est pas un problème.

L’appliance virtuelle réseau doit prendre en charge le trafic entrant pour les protocoles qui ne sont pas pris en charge par votre équilibreur de charge de couche 7, plus potentiellement tout le trafic de sortie. Pour plus d’informations sur cette configuration lors de l’utilisation du pare-feu Azure comme appliance virtuelle réseau et d’Azure Application Gateway comme proxy inverse web de couche 7, consultez Pare-feu et Application Gateway pour réseaux virtuels.

Serveur de routes Azure

Serveur de routes Azure est un service qui permet à une appliance virtuelle réseau d’interagir avec Azure SDN via Border Gateway Protocol (BGP). Non seulement les appliances virtuelles réseau apprennent quels préfixes IP existent dans les réseaux virtuels Azure, mais elles peuvent injecter des itinéraires dans les tables de routage effectives des machines virtuelles dans Azure.

Dans le diagramme ci-dessus, chaque instance d’appliance virtuelle réseau est homologuée sur BGP avec le serveur de routes Azure. Aucune table de routage n’est requise dans les sous-réseaux de rayons, car le serveur de routes Azure va programmer les itinéraires publiés par les appliances virtuelles réseau. 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, SNAT est obligatoire dans cette conception si la symétrie du trafic est requise.

Cette méthode d’insertion prend en charge le mode actif/actif (toutes les appliances virtuelles réseau publient les mêmes itinéraires sur le serveur de routes Azure), ainsi que le mode actif/en attente (une appliance virtuelle réseau publie les itinéraires avec un plus petit chemin AS que l’autre). Le serveur de routes Azure prend en charge un nombre maximal de 8 contiguïtés BGP. Par conséquent, si vous utilisez un cluster avec scale-out d’appliances virtuelles réseau actives, cette conception prend en charge un nombre maximal de 8 instances d’appliance virtuelle réseau.

La durée de convergence est assez rapide dans cette configuration et sera influencée par les minuteurs KeepAlive et Holdtime de la contiguïté BGP. Tandis que le serveur de routes Azure a des minuteurs KeepAlive et Holdtime par défaut (60 secondes et 180 secondes respectivement), les appliances virtuelles réseau peuvent négocier des minuteurs inférieurs pendant l’établissement de la contiguïté BGP. Une définition trop basse de ces minuteurs peut entraîner des instabilités de BGP.

Cette conception est l’option la plus courante pour les appliances virtuelles réseau qui doivent interagir avec le routage Azure, par exemple des appliances virtuelles réseau d’arrêt de VPN qui doivent apprendre les préfixes configurés dans des réseaux virtuels Azure ou publier certains itinéraires sur les peerings privés ExpressRoute.

Équilibreur de charge de passerelle

Équilibreur de charge de passerelle Azure est une nouvelle façon d’insérer des appliances virtuelles réseau dans le chemin de données sans devoir diriger le trafic avec des itinéraires définis par l’utilisateur. Pour les machines virtuelles qui exposent leurs charges de travail par le biais d’un équilibreur de charge Azure ou d’une adresse IP publique, le trafic entrant et sortant peut être redirigé en toute transparence vers un cluster d’appliances virtuelles réseau situé dans un autre réseau virtuel. Le diagramme suivant décrit le chemin d’accès que les paquets suivent pour le trafic entrant à partir de l’Internet public au cas où les charges de travail exposent l’application via un équilibreur de charge Azure :

L’un des principaux avantages de cette méthode d’injection d’appliance virtuelle réseau est que la traduction d’adresses réseau source (SNAT) n’est pas nécessaire pour garantir la symétrie du trafic. L’autre avantage de cette option de conception est que les mêmes appliances virtuelles réseau peuvent être utilisées pour inspecter le trafic vers/à partir de différents réseaux virtuels, ce qui permet d’obtenir une architecture multilocataire du point de vue d’une appliance virtuelle réseau. Aucun peering de réseaux virtuels n’est requis entre le réseau virtuel de l’appliance virtuelle réseau et les réseaux virtuels de la charge de travail, et aucun itinéraire défini par l’utilisateur n’est requis dans le réseau virtuel de la charge de travail, ce qui simplifie considérablement la configuration.

L’injection de service avec l’équilibreur de charge de passerelle peut être utilisée pour les flux entrants qui atteignent un équilibreur de charge Azure public (et leur trafic de retour), ainsi que pour les flux sortants provenant 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 d’appliance virtuelle réseau, les sondes de contrôle d’intégrité de l’équilibreur de charge Azure permettent de détecter les défaillances individuelles des instances d’appliance virtuelle réseau, ce qui permet d’obtenir une durée de convergence très rapide (10 à 15 secondes).

Modification du PIP/UDR

L’idée sous-jacente à cette conception est d’avoir la configuration requise sans redondance d’appliance virtuelle réseau et de la modifier au cas où l’appliance virtuelle réseau subit un temps d’arrêt. Le diagramme ci-dessous montre comment une adresse IP publique Azure est associée à l’appliance virtuelle réseau active (NVA1) et les itinéraires définis par l’utilisateur dans les rayons ont l’adresse IP de l’appliance virtuelle réseau active comme tronçon suivant (10.0.0.37).

Si l’appliance virtuelle réseau active n’est pas disponible, l’appliance virtuelle réseau en attente appelle l’API Azure pour remapper l’adresse IP publique et les itinéraires définis par l’utilisateur du rayon à eux-mêmes (ou déplacer également l’adresse IP privée). La mise en œuvre de ces appels d’API peut prendre quelques minutes, ce qui explique pourquoi cette conception offre la plus mauvaise durée de convergence de toutes les options de ce document.

Une autre limitation de cette conception est que seules les configurations actives/en attente sont prises en charge, ce qui peut entraîner des problèmes de scalabilité : si vous devez augmenter la bande passante prise en charge par vos appliances virtuelles réseau, la seule option de cette conception est la montée en puissance des deux instances.

L’un des avantages de cette conception est qu’aucune traduction d’adresses réseau source (SNAT) n’est requise pour garantir la symétrie du trafic, car il n’existe qu’une seule appliance virtuelle réseau active à un moment donné.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Keith Mayer | Architecte principal de solution cloud
• Telmo Sampaio | Responsable d’ingénierie des services principal

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

Étapes suivantes

• Découvrez comment implémenter un réseau hybride sécurisé à l’aide du pare-feu Azure.
• Réseaux de périmètre - Cloud Adoption Framework
• Zone DMZ cloud - Cloud Adoption Framework