Le cloud change la façon dont l’infrastructure est conçue, y compris la conception des pare-feu, parce que le réseau n’est plus physique ou sur des réseaux locaux virtuels. Les fonctionnalités d’un réseau physique ne sont pas toutes disponibles sur un réseau virtuel. Cela inclut l’utilisation d’adresses IP flottantes ou le trafic de diffusion, et influence l’implémentation des architectures de haute disponibilité. Les équilibreurs de charge pour Appliances virtuelles réseau peuvent/doivent être implémentés de manière à obtenir une architecture à haute disponibilité au sein d’un réseau virtuel. Ce guide présente une approche structurée de la conception des pare-feu à haute disponibilité dans Azure à l’aide d’appliances virtuelles tierces.
Options pour la conception d’appliances virtuelles réseau à haut niveau de disponibilité
Lors du déploiement d’architectures à haute disponibilité, il existe quelques options pour fournir un basculement :
- Tables de routage managées par API Azure : cette option utilise deux tables de routage, une active et une passive, afin de basculer l’adresse IP de la passerelle active pour tous les services exécutés sur un réseau ou sous-réseau virtuel.
- Adresse IP flottante managée par API Azure : cette option utilise sur les pare-feu une adresse IP secondaire qui peut être déplacée entre un pare-feu actif et un pare-feu de secours.
- Géré par Load Balancer : cette option utilise un équilibreur de charge Azure faisant office d’adresse IP de la passerelle pour le sous-réseau, qui transfère ensuite le trafic vers le pare-feu actif. Il peut même transférer le trafic actif-actif pour fournir un véritable équilibrage de charge.
Le problème avec les deux premières options est que le basculement lui-même est lent. Le pare-feu doit déclencher le basculement, qui est essentiellement une « reconfiguration » des services Azure via un nouveau déploiement. Selon la vitesse à laquelle le déploiement est terminé, les flux de trafic seront indisponibles pendant plusieurs minutes. Par ailleurs, ces deux options ne permettent pas une configuration active-active dans laquelle les deux pare-feu fonctionnent en même temps.
C’est la raison pour laquelle la troisième option est de loin préférable. Le temps d’arrêt est réduit car l’équilibreur de charge peut basculer presque instantanément vers le pare-feu de secours (en mode actif/passif) ou simplement retirer la charge du pare-feu défaillant (en mode actif/actif). Toutefois, vous ne pouvez pas simplement utiliser des équilibreurs de charge comme « passerelles par défaut », car ils affectent le flux de trafic et les paquets TCP doivent être avec état.
Pare-feu à deux branches
L’image suivante commence avec deux pare-feu (FW-1 et FW-2), avec un équilibreur de charge externe et un serveur back-end S1.
Cette architecture est une configuration simple, utilisée pour le trafic entrant. Un paquet atteint l’équilibreur de charge, qui choisit le pare-feu de destination à partir de sa configuration. Le pare-feu choisi envoie alors le trafic au serveur back-end (web). Si SNAT est activé sur FW-1, le serveur S1 voit le trafic qui vient de l’IP interne de FW-1 et donc envoie également la réponse au paquet à FW-1. Le basculement vers FW-2 peut s’effectuer rapidement dans ce scénario. Pour le trafic sortant, nous pourrions ajouter un autre équilibreur de charge du côté interne. Le même principe s’applique quand le trafic vient du serveur S1. Le trafic atteint l’équilibreur de charge interne (iLB), qui choisit un pare-feu qui traduit ensuite NAT pour la résolution externe :
Pare-feu à trois branches
Des problèmes surviennent lorsque nous ajoutons une autre interface au pare-feu, et vous devez désactiver la traduction NAT entre les zones internes. Dans ce cas, consultez Sous-réseau-B et Sous-réseau-C :
Le routage L3 entre les zones internes (sous-réseaux B et C) sera à charge équilibrée sans NAT. Cette configuration devient plus claire si vous examinez les flux de trafic incluant les équilibreurs de charge dans une vue différente. Le diagramme ci-dessous montre la vue dans laquelle les équilibreurs de charge internes [iLB] sont liés à une carte réseau spécifique sur les pare-feu :
Avec le trafic L3 (sans NAT), S2 voit l’adresse IP de S1 comme adresse source. S2 envoie alors le trafic de retour pour le sous-réseau B (auquel S1-IP appartient) à l’iLB sur le sous-réseau C. Comme l’iLB sur le sous-réseau B et l’iLB sur le sous-réseau C ne synchronisent pas leurs états de session, en fonction de l’algorithme d’équilibrage de charge le trafic pourrait peut se retrouver sur FW-2. Par défaut, FW-2 ne sait rien du paquet initial (vert), donc il abandonnera la connexion.
Certains fournisseurs de pare-feu essaient de conserver un état de connexion entre les pare-feu, mais il faudrait que la synchronisation soit quasi instantanée pour que les états de connexion soient à jour. Vérifiez auprès de votre fournisseur de pare-feu s’il recommande cette configuration.
La meilleure façon de traiter ce problème est de l’éliminer. Dans l’exemple ci-dessus, cette solution veut dire qu’il faut éliminer le sous-réseau C, ce qui nous permet de profiter des avantages offerts par les réseaux virtuels virtualisés.
Isoler les hôtes sur un sous-réseau avec des groupes de sécurité réseau
Quand il y a deux machines virtuelles sur un même sous-réseau, vous pouvez appliquer un groupe de sécurité réseau qui isole le trafic entre les deux. Par défaut, le trafic à l’intérieur d’un réseau virtuel est totalement autorisé. L’ajout d’une règle Refuser tout sur le groupe de sécurité réseau isole toutes les machines virtuelles les unes des autres.
Les réseaux virtuels utilisent les mêmes routeurs back-end (virtuels)
Les réseaux virtuels/sous-réseaux utilisent un seul système de routeur back-end d’Azure ; par conséquent, il n’est pas nécessaire de spécifier une IP de routeur pour chaque sous-réseau. La destination de la route peut se trouver n’importe où sur le même réseau virtuel, ou même en dehors.
Avec les réseaux virtualisés, vous pouvez contrôler les routes sur chaque sous-réseau. Ces routes peuvent également pointer vers une seule adresse IP d’un autre sous-réseau. Dans l’image ci-dessus, il s’agit de l’iLB sur le sous-réseau D, qui équilibre la charge des deux pare-feu. Dès que S1 démarre le trafic (vert), sa charge est équilibrée, par exemple vers FW-1. FW-1 se connecte alors à S2 (toujours en vert). S2 envoie le trafic de réponse à l’IP de S1 (car NAT est désactivé). En raison des tables de routage, S2 utilise la même IP iLB que sa passerelle. L’iLB peut faire correspondre le trafic à la session initiale et par conséquent pointera toujours ce trafic vers FW-1. FW-1 l’envoie ensuite à S1, établissant ainsi un flux de trafic synchrone.
Pour que cette configuration fonctionne, le pare-feu doit avoir une table de routage (en interne) qui dirige les sous-réseaux B et C vers sa passerelle de sous-réseau par défaut. Cette passerelle de sous-réseau est la première IP logiquement disponible dans la plage de sous-réseau de ce réseau virtuel.
Impact sur les services de proxy inverse
Lorsque vous déployez un service de proxy inverse, celui-ci se trouve normalement derrière le pare-feu. Vous pourriez plutôt le placer en alignement avec le pare-feu et en fait router le trafic via le pare-feu. L’avantage de cette configuration est que le service de proxy inverse voit l’IP d’origine du client qui se connecte :
Pour cette configuration, les tables de routage sur le sous-réseau E doivent diriger les sous-réseaux B et C vers l’équilibreur de charge interne. Certains services de proxy inverse ont des pare-feu intégrés, ce qui vous permet de supprimer complètement le pare-feu dans ce flux réseau. Les pare-feu intégrés pointent le proxy inverse directement vers les serveurs des sous-réseaux B/C.
Dans ce scénario, SNAT sera nécessaire également sur le proxy inverse afin d’éviter que le trafic de retour soit transmis et refusé par les pare-feu vers le sous-réseau A.
VPN/ER
Azure fournit des services VPN/ER compatibles avec le protocole BGP et à haut niveau de disponibilité par le biais des passerelles de réseau virtuel Azure. La plupart des architectes conservent cela pour les connexions back-end ou non accessibles sur Internet. Avec cette configuration, la table de routage doit aussi prendre en charge les sous-réseaux derrière ces connexions. Il n’y a pas de grande différence pour la connectivité des sous-réseaux B/C, mais il y en a une dans la conception du trafic de retour. Complétons l’image :
Dans cette architecture, le trafic qui atteint le pare-feu, par exemple du sous-réseau B vers le sous-réseau X, est envoyé à l’iLB, qui à son tour l’envoie à l’un ou l’autre pare-feu. La route interne à l’intérieur du pare-feu renvoie le trafic à la passerelle du sous-réseau (première adresse IP disponible sur le sous-réseau-D). Vous n’avez pas besoin d’envoyer le trafic directement à l’appliance de passerelle, car une autre route sur le sous-réseau D aura une route pour le sous-réseau X en le faisant pointer vers la passerelle de réseau virtuel. Azure Networking s’occupe du routage réel.
Le trafic de retour en provenance du sous-réseau X sera transféré à l’iLB sur le sous-réseau D. Le sous-réseau de passerelle aura également une route personnalisée dirigeant les sous-réseaux B et C vers l’iLB. Le sous-réseau D ne passe pas par l’iLB. Son trafic sera traité comme un routage inter-réseau virtuel ordinaire.
Même si cela ne figure pas sur le dessin, il serait judicieux de faire en sorte que les sous-réseaux B/C/D/passerelle incluent également une route pour le sous-réseau A le dirigeant vers l’iLB, cet arrangement permettant d’éviter que le routage de réseau virtuel « ordinaire » ne contourne les pare-feu. Le sous-réseau A est simplement un autre sous-réseau du réseau virtuel du point de vue de la pile réseau Azure. Il ne sera pas traité différemment, même si vous le considérez comme étant DMZ/Internet, et ainsi de suite.
Résumé
En bref, la façon dont vous traitez les pare-feu sur vos réseaux locaux (physiques/VLAN), avec autant d’interfaces (virtuelles ou physiques), n’est pas la même que dans Azure. Si nécessaire, vous pouvez toujours les traiter de la même façon (dans une certaine mesure), mais il existe de meilleures façons de s’assurer que vous pouvez réduire les temps d’arrêt liés au basculement : avoir des implémentations actif-actif et des tables de routage propres.
Pour plus d’informations sur l’utilisation des équilibreurs de charge en tant que passerelles pour tout le trafic, consultez Vue d’ensemble des ports haute disponibilité.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Roelf Zomerman | Architecte de solution cloud senior
Étapes suivantes
En savoir plus sur les technologies des composants :
- Qu’est-ce qu’Azure Load Balancer ?
- Qu’est-ce que le réseau virtuel Azure ?
- Qu’est-ce qu’une passerelle VPN ?
Ressources associées
Explorer les architectures connexes :