Dans l’article précèdent, on avait parlé de comment peut-on sécuriser la communication entre nos différents VPC via un Firewall centralisé dans le VPC HUB, on a vu aussi la limitation de cette solution en termes de scalabilité et de management.
Dans le présent article, on parlera d’une solution alternative basée sur l’utilisation du Gateway Load-Balancer (GWLB) et on verra au fur et à mesure comment cette solution corrige les lacunes de la solution précédente. La solution est connue communément par le VPC Inspection.
Le principe de la solution VPC inspection est de positionner tout simplement nos appliances L4/L7 derrière un Load-Balancer qui va servir à partager la charge vers le groupe des cibles « Target Group ».
Le Gateway LoadBalancer (GWLB):
Un Gateway Load Balancer vous permet de déployer, de mettre à l’échelle et de gérer des appliances virtuelles, telles que des pares-feux, des systèmes de détection et de prévention des intrusions et des systèmes d’inspection approfondie des paquets. Ils combinent une passerelle réseau transparente (c’est-à-dire un point d’entrée et de sortie unique pour tout le trafic) et distribuent le trafic tout en adaptant vos appliances virtuelles à la demande.
Les Gateway Load Balancer agissent au niveau de la troisième couche du modèle OSI Open Systems Interconnection (OSI), la couche réseau. Ils écoutent tous les paquets IP sur tous les ports et transfèrent le trafic vers le groupe cible spécifié dans la règle d’écoute. Ils maintiennent la permanence des flux vers un appliance cible spécifique en utilisant un 5-uplet (pour les flux TCP/UDP) ou un 3-uplet (pour les flux non-TCP/UDP). Les Gateway Load Balancer et leurs instances d’appliances virtuelles enregistrées échangent le trafic applicatif à l’aide du protocole GENEVE sur le port 6081.
Les points de terminaison (GWLBE) :
Le trafic est acheminé vers Les Gateway Load-Balancer par le biais des points de terminaison (Service Endpoints), les Service Endpoints créent une chaine de communication privée entre les clients (Tout service générant un trafic nécessitant le passage par le Target Group) et les serveurs (Target group). Autrement dit, afin que le trafic atteint le Target Group, il faut tout d’abord que le flux soit redirigé vers les Service Endpoint du GWLB à l’aide d’une route dans la table de routage.
Les services Endpoint du Gateway LoadBalancer peuvent cohabiter au sein du même VPC du GWLB ou bien dans une autre VPC.
Finalement cette architecture est supportée seulement lorsque le Target Group supporte l’encapsulation GENVE. Se référer au site d’AWS pour obtenir la liste des constructeurs tiers supportés.
Après cette brève présentation du GWLB, retournons maintenant à notre objectif initial, qu’est pour rappel, l’inspection centralisée par des Firewalls de toute communication entre mes VPC SPOKE en utilisant le GWLB.
La seule différence entre l’architecture ci-dessus et celle utilisée dans l’article precédent et l’integration du GWLB et ses Endpoints dans le VPC INSPECTION appelé EDGE auparavant et modifier les routes par défaut de la table des subnets TGW dans le VPC INSPECTION afin qu’elles pointent sur les Endpoints au lieu de pointer directement sur les Firewalls.
Maintenant, quand la machine 10.1.0.133/25 du VPC-A/AZ-A souhaite communiquer avec la machine 10.1.2.209 du VPC-B/AZ-A, le chemin du trafic de cette communication est illustrée dans le schéma ci-dessous:
- Le subnet de la machine 10.1.0.133 est associée à une table de routage contenant une route pour rediriger le trafic à destination de 10.1.2.0/23 vers la Transit Gateway,
- À la réception du flux par la TGW, cette dernière vérifie l’adresse IP de destination du flux et l’envoie vers le TGW subnet-A du VPC INSPECTION grâce à la route par défaut programmée dans sa table de routage et attachée au VPC SPOKE A et B,
- À l’arrivée dans le subnet-A du VPC INSPECTION, la table de routage de ce subnet contient une route vers 10.1.2.0/23 qui pointe vers le service Endpoint de la même AZ (GWLBE-A), ce flux est donc redirigé vers le service Endpoint de la même AZ,
- Une fois le flux atteint le GWLBE-A, il est automatiquement acheminé vers le GWLB,
- Le GWLB encapsule le trafic avec le protocole GENEVE et envoie le flux vers un des Firewall sain du Target Group,
- Le Firewall décapsule le trafic, l’inspecte, puis le renvoie vers le GWLB en utilisant la même encapsulation,
- Le GWLB redirige automatiquement le flux vers le service Endpoint par lequel il a reçu le flux initialement,
- Une fois arrivé au niveau du service Endpoint-A dans notre exemple, la table du routage associée au subnet de ce Service Endpoint est vérifiée, Une route vers 10.1.2.0/23 est programmée dans cette table qui pointe vers la TGW. Le flux est renvoyé vers la table de routage du TGW associée au VPC INSEPCTION,
- La TGW envoie immédiatement le flux vers VPC SPOKE-B.
Le flux de retour suit les mêmes étapes ci-dessus pour atteindre le 10.1.0.133/25
Qu’est ce qui se passe en cas de panne d’un des Firewall ?
Le GWLB supervise en permanence l’état de tous les membre du Target Group via des messages de vérification en utilisant le protocole TCP, HTTP ou HTTPs et ne distribue le trafic que vers les membres sains (les membres qui répondent positivement aux messages de vérification).
En cas de défaillance d’un Firewall, le GWLB ne recevra plus de réponse à ses messages de vérification de la part de ce Firewall. Par conséquent le Firewall défaillant ne fera plus partie des cibles sains et le flux est redirigé vers les autres membres de Target Group.
Pour garantir un certain niveau de stabilité, si le FW HS est rétabli, le GWLB ne l’intègre pas tout de suite dans le Target Group mais le FW doit réussir un petit examen en répondant positivement à trois messages de vérification consécutifs. Cette valeur est configurable entre 2 et 10 messages de vérification.
On a vu dans cet article, comment le GWLB facilite drastiquement l’insertion des appliances virtuelles comme les Firewalls et les faire fonctionner en mode Actif/Actif et nous prémunir d’une manière élégante de toute la complexité des solutions qui permettaient d’assurer le Fail-Over en cas de panne de l’un de nos appliances virtuelles sans parler du temps de nécessaire pour le Fail-Over qu’est relativement plus long que celui proposé par le GWLB.
Si vous avez des questions ou vous avez besoin d’un complément d’informations ou une consultation spécifique à votre environement, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.
