L’utilisation de l’architecture HUB & SPOKE dans les environnements Cloud est très commune due à sa flexibilité, son évolutivité et surtout sa capacité d’introduire le concept de la sécurité centralisée via l’insertion des produits de sécurité comme les Firewalls ou IPS/IDS dans les Hubs.

Cet article fera partie d’une série d’articles qui taclent les différentes options possibles pour introduire le concept de la sécurité et de contrôle centralisé dans le Cloud Public AWS.

La première option qui sera traitée dans cet série d’articles, est l’utilisation de la Transit Gateway pour interconnecter les VPC SPOKEs via un VPC HUB appelé VPC de transit.

La Transit Gateway (TGW) :

La Transit Gateway ou TGW est un routeur Cloud virtuel distribué dans la région, scalable et hautement disponible qui permet l’interconnexion des VPC entre eux (jusqu’5K VPC) et étendre cette interconnexion vers l’On-premise via un tunnel IPsec ou un Direct-Connect. Au-delà de sa capacité de fédérer les différents types de connexions, la TGW offre la possibilité de faire du service-chainning en associant les services interconnectés via la TGW aux différentes tables de routage (ça ressemble au principe de VRF).

TGW Attachment :

La TGW s’attache aux VPCs via des « attachements ». Ce sont des interfaces réseaux élastiques ENI de la TGW positionnées aux seins des subnets de la VPC. La TGW peut s’attacher à un ou plusieurs subnet de la VPC. Pour assurer la résilience. Toutefois il est recommandé à minima d’attacher la VPC à deux subnets associés à différentes zones de disponibilité.

Une TGW peut être attachée à :

  • Des VPC de la même région,
  • Une AWS Direct-Connect Gateway,
  • Une connexion VPN (IPsec),
  • Une autre transit Gateway dans la même ou différentes régions.

La Table de routage :

Chaque TGW peut avoir une ou plusieurs tables de routage selon le Traffic engineering qu’on souhaite accomplir. La table de routage est associée aux attachements et contient les routes nécessaires pour acheminer le trafic vers sa destination finale.

Association :

Il existe une relation 1 à N entre la table de routage et les attachements. Autrement dit une table de routage peut être associée à un ou plusieurs attachements, en revanche un attachement ne peut s’associer qu’a une seule table de routage.

Propagation :

L’insertion des routes dans la table de routage se fait soit :

  • Via la propagation automatique des VPC CIDR après l’attachement du VPC à la TGW.
  • Via la configuration statique des routes dans la table de routage

Diagram

Description automatically generated

Après cette brève présentation de la TGW, on va voir maintenant comment peut-on créer à l’aide de la TGW une architecture HUB & SPOKE pour faire passer tout le trafic Inter-VPC par un Firewall qui se trouve dans le VPC de TRANSIT.

L’architecture de référence ci-dessous illustre le principe d’e l’architecture HUB & Spoke qu’on souhaite accomplir :

Graphical user interface, application, Teams

Description automatically generated

Dans cette architecture, on a :

  • Deux VPCs SPOKE A et B ==> Dans chaque VPC, on a deux EC2 instances dans deux zones de disponibilité différentes
  • Un VPC TRANSIT qui héberge deux Firewalls étendus sur deux zones de disponibilité
  • Une TGW attachée aux trois VPC. Selon les bonnes pratiques, il faut avoir dans chaque VPC des subnets qui seront utilisés exclusivement pour attacher la
  • TGW à la VPC. https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html

Graphical user interface, text, application, email

Description automatically generated

Rappelez-vous que notre besoin consiste à faire communiquer les deux VPCs SPOKE via le firewall du VPC HUB. Pour cela, je dois :

  1. Créer deux tables de routage dans la TGW :
    • Une table de routage (SPOKE-RT) que j’associe aux attachements des VPC SPOKEs
    • Une table de routage (TRANSIT-RT) que j’associe seulement à l’attachement du VPC TRANSIT.

Graphical user interface, text, application, email

Description automatically generated

  • Propager dans la table de routage TRANSIT, les subnets associés aux attachements des VPC SPOKEs afin que le VPC TRANSIT puisse joindre les deux VPC SPOKEs.

Graphical user interface, text, application, email, website

Description automatically generated

  • Ne propager aucun attachement dans la table de routage TRANSIT du TGW mais plutôt créer manuellement dans l’onglet Routes, une route par défaut qui pointe sur l’attachement du VPC Transit

Graphical user interface, text, application

Description automatically generated

C’est fini maintenant pour la configuration du TGW.

Cette configuration n’est pas suffisante pour faire communiquer les deux VPC SPOKEs via le Firewall du VPC de TRANSIT car la configuration des tables de routages du TGW n’est pas poussée vers les subnets des VPC SPOKEs et TRANSIT. Par conséquent, je dois aller modifier les différentes tables de routage des VPCs TRANSIT et SPOKEs comme illustré dans l’architecture de référence ci-dessus.

Après avoir fini la configuration des différentes tables de routages. Le ping entre les EC2 instances de deux VPC est fonctionnels. (Wahoooo!!!)

Vérifiant si le trafic passe bien par les Firewalls, je fais un Tcpdump sur l’interface INSIDE des Firewalls :

Text

Description automatically generated

Le trafic est partagé sur les deux Firewalls car le ping lancé depuis la zone de disponibilité A des SPOKEs est envoyé par la TGW au Firewall dans la zone de disponibilité A du VPC TRANSIT. Par défaut, la TGW essaie de garder le trafic dans la même zone de disponibilité.

le trafic inter-zones n’est possible que s’il y a une défaillance dans la zone de disponibilité A du Firewall-A. Ce comportement n’est pas adapté quand on souhaite faire inspecter le trafic par un équipement statefull, Firewall par exemple.

Supposant par exemple dans notre architecture, l’instance EC2 du SPOKE A/AZ A souhaite communiquer avec l’instance EC2 du SPOKE B/AZ B. Le chemin du flux sera comme illustré dans le schéma ci-dessous :

Graphical user interface, application, Teams

Description automatically generated

Lors de la création de la TGW, on peut activer l’option « Appliance Mode ». Cette option permet à la TGW d’inspecter l’interface d’entrée du trafic dans l’étape 2 et redirige le trafic vers la même interface dans l’étape 5.

Comme j’ai déjà expliqué, l’architecture du Firewall dans le VPC TRANSIT est résiliente contre une défaillance d’une zone de disponibilité. En revanche qu’est ce qui se passe lorsque je perds seulement le Firewall et pas la zone de disponibilité dans laquelle il réside.

Supposant pour l’instant qu’on avait perdu le Firewall A du VPC TRANSIT, les flux en provenance des Zones de disponibilité A vont continuer (Par défaut) à être redirigés vers l’interface INSIDE du Firewall A et bloqués là-bas.

Il existe deux solutions pour résoudre ce problème et les deux demandent une supervision de l’état des Firewalls et déclencher un script pour appliquer le scénario de la solution choisie.

  • La première solution consiste à recréer le Firewall défaillant à partir d’un backup config et remettre en fonction le Firewall A
  • La deuxième solution consiste à désassocier le subnet du firewall défaillant de l’attachement TGW afin que le trafic soit redirigé vers le Firewall de l’AZ B.

Graphical user interface, application

Description automatically generated

Le temps de reprise de service pour ces deux scénarios est pratiquement long, il consiste à détecter la panne via l’outil de monitoring puis déclencher le script de rectification. Ce temps de coupure pourrait être inadéquat pour des services qui ne tolèrent pas un temps de coupure assez conséquent.

Dans le prochain article, on va voir comment peut-on intégrer une couche de firewall en HA qui ne nécessite ni monitoring ni script de correction et assure la continuité de service en cas de panne de l’un des deux firewalls.

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.

Author

Driss JABBAR Un Architect réseaux avec plus de 10 ans d'expérience dans la conception et l'implémentation des architectures complexes LAN/WAN/DC. Pendant son parcours professionnelle, Driss a travaillé chez des intégrateurs et aussi des opérateurs. Driss possède actuellement trois certifications d'expertise Cisco CCIE RS & SP et CCDE. En dehors du travail, Driss consacre plus de temps pour sa famille mais il réserve toujours un petit créneau pour apprendre des nouvelles technologies ou pour regarder un match de foot de son club préféré. Driss est contributeur du blog MHD et joignable à l’adresse : driss.jabbar@mhd-experts.com

Write A Comment