Un VPN site à site pour plusieurs VPC sur AWS Transit Gateway

Deux VPC ont besoin du réseau du bureau ce trimestre, et c'est au second tunnel que l'estimation casse. AWS Transit Gateway peut servir de concentrateur de routage partagé : le VPN est attaché une fois, et chaque VPC est attaché au même concentrateur. Le réseau local atteint alors chaque VPC attaché par une seule connexion. Cela change qui détient la décision de routage, et c'est la partie que la plupart des conceptions ratent.

L'attachement du VPN et les attachements des VPC sont des objets distincts sur la même passerelle, c'est pourquoi les relations de routage doivent être construites ensuite.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Pourquoi le peering n'est pas le raccourci espéré

L'alternative tentante est de terminer le VPN sur le VPC A et d'appairer le VPC B avec lui. Le peering ordinaire de VPC n'offre pas de transit de bout en bout par la connexion VPN de A. Un pair atteint les adresses que le peering lui-même fournit, et une extrémité VPN n'en fait pas partie. Le transit, c'est ce qu'un concentrateur donne ; le peering donne une paire.

Cette restriction est une propriété du peering, pas un quota que l'on peut augmenter.

L'association et la propagation font des travaux différents

Dans la passerelle de transit, l'association choisit la table de routage utilisée pour rechercher le trafic arrivant d'un attachement. La propagation décide quelles tables reçoivent les préfixes appris ou connectés d'un attachement. Un même attachement peut être associé à une table tout en propageant vers plusieurs. Confondre les deux est la façon dont une conception finit avec une joignabilité que personne n'avait planifiée.

Un petit concentrateur entièrement maillé est le cas facile.

Placez chaque attachement dans une seule table et le VPN, avec les deux préfixes de VPC, se résout proprement. Cela autorise aussi une joignabilité entre VPC que l'organisation n'a peut-être jamais voulue, car une table partagée ne connaît pas la notion de spoke.

Les routes des charges de travail vivent ailleurs

Chaque sous-réseau de charge de travail a toujours besoin de sa propre route vers la passerelle de transit pour les préfixes locaux prévus. Ces tables de routage de VPC sont des objets distincts des tables propres à la passerelle de transit. Ajoutez les préfixes nécessaires et conservez les routes existantes au lieu de remplacer chaque destination par une nouvelle route par défaut. Une route de sous-réseau n'annonce rien non plus au périphérique client.

Choisissez le routage dynamique ou statique délibérément ; le peering ne fournit ni l'un ni l'autre.

Isoler les spokes sans perdre l'accès local

Quand A et B peuvent tous deux atteindre le bureau mais ne doivent pas router l'un vers l'autre, séparez les tables. La table associée de l'attachement VPN contient les préfixes des VPC. La table associée des attachements de VPC contient les préfixes locaux, sans route reliant A à B. La propagation produit cette relation, vous n'avez donc jamais à accepter toutes les associations par défaut.

C'est de l'isolement de routage, et ce n'est pas une autorisation applicative.

Les groupes de sécurité, les ACL réseau, les pare-feu des hôtes et les autorisations propres à chaque service décident toujours du trafic admis. Si une inspection est requise, concevez explicitement son chemin pris en charge au lieu de supposer que le concentrateur l'exécute.

Ce que le concentrateur ne corrige pas

Les plans d'adressage doivent toujours être sans chevauchement, car le concentrateur ne permet pas à un préfixe d'identifier deux charges de travail. Chaque attachement de VPC a besoin de la couverture Availability Zone qu'attendent ses charges de travail. Avec BGP, les routes du périphérique client vers chaque préfixe requis doivent correspondre à la conception et à sa politique d'importation. Une annonce manquante ressemble exactement à un tunnel cassé.

La connexion VPN et la passerelle de transit sont désormais une infrastructure partagée.

Planifiez la redondance des tunnels, la capacité des périphériques, la supervision et la maintenance autour de tous les VPC dépendants au lieu de traiter chacun comme connecté indépendamment.

La migration depuis une disposition existante avec virtual private gateway mérite le même plan explicite. Construisez les attachements et les politiques, déplacez un chemin de charge de travail contrôlé, et confirmez les relations autorisées et refusées avant de retirer l'ancien chemin. La centralisation aide quand elle donne à l'équipe réseau un seul endroit pour gérer la connectivité partagée, et nuit quand elle cache qui peut atteindre qui derrière une seule grande table.