J'implémente une passerelle de transit dans un compte de passerelle de transit dédié. Je cherche alors à connecter jusqu'à 6 AWS VPC à partir de comptes séparés. Je pense que je dois ajouter les 6 pièces jointes de Transit Gateway à la même table de routage de Transit Gateway pour permettre la connectivité entre elles - car AWS ne vous permet pas d'associer une pièce jointe TGW à plus d'une table de routage TGW.
Cela fonctionne et tous les VPC peuvent communiquer entre eux, mais quelle est la meilleure pratique pour contrôler l'accès entre les VPC. Disons que D est le compte Transit Gateway.
Les VPC A / B / C / D sont tous sur la table de routage TGW. Que faire si je ne veux pas que le VPC A parle au VPC B, mais permette au VPC A de parler au VPC C. Je sais que cela ne se produira pas à moins que j'ajoute les routes VPC du sous-réseau / les propage, mais j'aimerais plus de contrôle.
Par exemple, deux tables de routage TGW, une avec l'attachement TGW (D), VPC A, VPC B. Une autre table de routage TGW avec l'attachement TGW (D), VPC A, VPC C.
Je suppose qu'une façon de le faire serait d'ajouter des NACL aux sous-réseaux de Transit Gateway, mais cela ne bloquerait que des VPC entiers.
4 Réponses :
En réponse à la question, le modèle doit être le suivant ...
Chaque VPC doit avoir une pièce jointe de passerelle de transit. Chaque VPC doit avoir une table de routage de passerelle de transit créée. Chaque table de routage de passerelle de transit doit être associée à cette pièce jointe de passerelle de transit. Les règles de routage doivent ensuite être ajoutées à la table de routage de la passerelle de transit en tant que règles de sortie.
Dans cet exemple, les VPC A et B peuvent communiquer et A et C. Mais B ne peut parler qu'à A.
VPC A (10.10.10.0/16) <-> TGW ATT A VPC B (10.10.11.0/16) <-> TGW ATT B VPC C (10.10.12.0/16) <-> TGW ATT C TGW RT TBL A 10.10.11.0/16 (VPC B) -> TGW ATT B 10.10.12.0/16 (VPC C) -> TGW ATT C TGW RT TBL B 10.10.10.0/16 (VPC A) -> TGW ATT A TGW RT TBL C 10.10.10.0/16 (VPC A) -> TGW ATT A
De plus, des règles de routage de sous-réseau devront être ajoutées aux VPC et SG ouverts.
Dans un modèle Hub and Spoke: Compte A = Hub Compte B, C et D = Rayons
Cas d'utilisation 1 - Les comptes B, C et D peuvent communiquer avec le compte A.
Cas d'utilisation 2 - Les comptes B et C peuvent communiquer directement entre eux
La seule différence entre eux en ce qui concerne la configuration de TGW est, les tables de routage. Tables de routage VPC: Compte B VPC aura un itinéraire vers le compte C CIDR & TGW ID (TGW défini dans le compte A) Compte C VPC aura un itinéraire vers le compte B CIDR & TGW ID (TGW défini dans le compte A)
et
Tables de routage TGW: La table de routage TGW du compte B est propagée à la pièce jointe du compte C La table de routage TGW du compte C est propagée à la pièce jointe du compte B
Dans ce scénario, les comptes B et C ne communiquent pas avec A car il n'y a pas de table de routage VPC et il n'y a pas de propagation de route TGW vers l'attachement VPC A.
reportez-vous à cette documentation pour le code terraform complet et l'explication de ce scénario
http://i-cloudconsulting.com/ aws-transit-gateway-hub-and-spoke-model /
En septembre 2020, il y avait pas mal de changements sur la configuration de TGW, donc une mise à jour pourrait être utile ici.
Nous avons déployé quelque chose de similaire avec un TGW et 3 tables de routage (modèle Hub and Spoke comme indiqué précédemment).
Pièces jointes TGW
Tables de routage:
Le TransitVPC contient désormais une NVA (Application virtuelle réseau, par exemple Fortigate, Barracuda, Palo Alto). La NVA a deux interfaces pour la connexion privée et publique et donc deux tables de routage:
La NVA utilisera sa propre table de routage intégrée avec les adresses IP de la passerelle de transit eni comme prochain saut, sinon elle bouclera dans la table de routage du sous-réseau privé.
Vous pouvez déployer une solution de contrôle d'accès / IDS / IPS / AV / xxx fonctionnelle avec cette configuration et isoler tout le trafic en fonction des politiques de pare-feu.
Cette configuration est également capable d'héberger un VPC de service partagé (VPC Endpoints) à l'aide de route53.
Vous devez concevoir votre réseau en fonction de vos besoins.
Par exemple, nous avons 4 VPC - VPC A, B, C, D.
Condition:
Que faire si je ne veux pas que le VPC A parle au VPC B, mais permette au VPC A de parler au VPC C. Je sais que cela ne se produira pas à moins que j'ajoute les routes VPC du sous-réseau dans / les propage mais Id comme plus de contrôle.
Dans la conception:
VPC A <--> VPC C VPC A <--> VPC D
Vous devez créer deux choses:
Passerelle de transit - tgw
Pièces jointes de passerelle de transit: associez tous les VPC A, C, D à la passerelle de transit que vous avez créée. Pièce jointe A (VPC A) -> tgw Pièce jointe C (VPC C) -> tgw Pièce jointe D (VPC D) -> tgw
Table de routage de la passerelle de transit (tgw-rt1): Créez une table de routage de la passerelle de transit et associez-la à toutes les pièces jointes (A, C et D). Créez une propagation et ajoutez toutes les pièces jointes A, C et D. Cela générera automatiquement une route.
Voici le flux, lorsque le trafic provient du VPC A vers le VPC C. Le sous-réseau du VPC A doit avoir une route vers tgw, de sorte que le trafic atteint tgw. tgw regarde de quelle pièce jointe le trafic provient et sa pièce jointe A (c'est-à-dire VPC A) et trouve la table de routage respective tgw-rt1. Maintenant, le tgw-rt1 a des routes pour propager le trafic vers la pièce jointe respective (c'est-à-dire le VPC C). Et ce n'est qu'un moyen, pour que le trafic revienne vers le VPC A, vous devriez également avoir une route dans votre VPC C.
Il semble que j'ai mal compris Transit Gateway, la solution semble être ... Créez une pièce jointe de passerelle de transit pour chaque VPC que vous souhaitez connecter, créez une table de routage de passerelle de transit pour chaque VPC et attachez la pièce jointe TGW, en spécifiant les routes vers ce transit attachement de passerelle.