Ajouter un sous-réseau local à un VPN AWS : VGW ou Transit Gateway

Un VPN Site-to-Site existant transporte 10.60.0.0/16, un nouveau réseau de service apparaît derrière la même passerelle locale en 10.70.0.0/16, et quelqu’un demande si un proxy est nécessaire. Généralement non : une route peut transporter le préfixe, mais seulement si trois choses concordent, et lesquelles trois dépend de l’architecture AWS que vous exploitez déjà. Une passerelle privée virtuelle possède une limite de table de routage ; un transit gateway en ajoute une seconde. Une annonce correcte avec une table erronée produit une session qui semble saine et ne livre rien.

Publiez un préfixe que la passerelle peut réellement livrer

La passerelle locale a besoin d’une route vers le nouveau réseau avant que toute annonce ait un sens. Annoncer 10.70.0.0/16 via BGP indique à AWS où envoyer les paquets pour cette plage ; cela ne crée pas le chemin de transfert local qui rend la plage joignable à l’autre bout. Vérifiez que la passerelle dispose d’une route pour le préfixe pointant vers l’équipement qui le détient, et que cet équipement est configuré pour répondre pour ces adresses. La politique d’export et les limites de préfixes acceptés sont la contrainte suivante, car un préfixe que la session filtre n’atteint jamais AWS.

Gardez les agrégats et les routes plus spécifiques délibérés. Des chemins qui se chevauchent et arrivent de deux directions sont une décision de conception, pas un détail découvert plus tard.

Premier chemin : la limite de la passerelle privée virtuelle

Avec une passerelle privée virtuelle, la documentation de routage du VPN AWS décrit deux modes de distribution, les routes statiques et les annonces BGP, et tous deux dépendent de la table de routage de sous-réseau que l’application utilise réellement. La propagation est pratique lorsque vous contrôlez toute la plage, et une route explicite est plus facile à raisonner lorsque vous voulez la destination listée à côté de la cible. Dans les deux cas, la vérification est la même : la table du sous-réseau applicatif concerné contient-elle un chemin fonctionnel vers la cible VPN pour le nouveau préfixe, et l’emporte-t-il sur quelque chose de plus spécifique ?

Une session BGP saine prouve que le canal existe. Elle ne dit rien sur la question de savoir si une table de sous-réseau donnée a consommé la route.

Deuxième chemin : le transit gateway ajoute une table

Un transit gateway divise cette unique question en deux. Le sous-réseau du VPC doit envoyer la destination vers l’attachement du transit gateway, puis la table de routage du transit gateway doit sélectionner l’attachement VPN pour ce même préfixe. Les choix d’association et de propagation déterminent quels réseaux attachés reçoivent la route, si bien qu’un préfixe peut être correctement annoncé par le VPN et ne jamais atteindre le VPC dont la table n’a jamais été associée à la bonne table de routage.

L’échec courant est une route qui existe dans une table et pas dans l’autre, chaque équipe étant convaincue que son côté est correct. Lorsque vous comparez les deux architectures, cette limite supplémentaire est toute la différence : plus d’endroits à examiner, et un contrôle plus précis de qui reçoit la route.

La propagation de routes n’accorde pas non plus le préfixe à chaque attachement. Elle le distribue aux tables configurées pour le recevoir.

Le chemin de retour est sa propre décision de politique

Le trafic qui arrive ne représente que la moitié de l’échange. Le nouveau réseau local a besoin d’une route de retour vers les préfixes source AWS via la bonne passerelle, et la politique de sécurité des deux côtés doit autoriser cette paire source-destination. Si le tunnel négocie un périmètre de protection avec des sélecteurs de trafic, le nouveau préfixe doit s’y trouver, sinon le paquet est abandonné avant toute consultation d’une table de routage.

Le chevauchement d’adresses est l’autre piège. Des plages disjointes et explicitement possédées gardent cela simple ; des plages qui se chevauchent impliquent une traduction ou une refonte, et ni l’une ni l’autre n’est une variante interchangeable de la même recette.

Testez avec une source dans le nouveau réseau et une destination dans le sous-réseau applicatif, puis répétez dans l’autre sens. Un test unidirectionnel ne prouve qu’une direction.

Quand le proxy est réellement la meilleure limite

Un proxy mérite sa place lorsque l’exigence est une interface de service étroite, lorsque l’application attend déjà cette architecture, ou lorsque le chemin réseau ne peut pas transporter le préfixe sans une traduction que vous ne voulez pas. Il n’est pas la solution de repli pour une entrée de table de routage que personne n’a vérifiée.

Décidez dans cet ordre : transfert local, annonce, limite de table, politique de retour. Corrigez la première qui échoue, et demandez seulement ensuite si le chemin routé est la bonne réponse.