AWS Site-to-Site VPN vers NAT Gateway : VGW ou Transit Gateway

Tout le monde dessine le même schéma la première fois : VPN vers le VPC, NAT gateway vers Internet, terminé. Mais AWS ne prend pas en charge ce chemin lorsque le VPN se termine sur une virtual private gateway, et la panne est assez silencieuse pour que les équipes la reconstruisent plus d’une fois. Le design qui fonctionne exige un transit gateway, ce qui change la passerelle et les tables de routage des deux côtés. Comparez les deux formes avant de dessiner quoi que ce soit.

La topologie qui paraît évidente et qui n’est pas prise en charge

La documentation du NAT gateway d’AWS trace une ligne qui surprend quiconque n’a construit que des designs à VPC unique : le trafic d’une connexion Site-to-Site VPN ne peut pas être routé vers un NAT gateway via une virtual private gateway. Le type de passerelle sur lequel le VPN se termine décide s’il existe seulement un chemin de traduction. L’erreur survit parce que le tunnel est UP et qu’une instance EC2 du même subnet atteint Internet sans problème. Aucune des deux observations ne teste la direction cassée.

En pratique, le paquet arrive avec une adresse source du réseau local et ne trouve aucun saut suivant pris en charge qui le traduirait. Selon les tables, il est jeté à la frontière de sortie, et comme le tunnel reste UP pendant qu’une instance du même subnet atteint Internet, la panne est signalée comme un problème de pare-feu local.

Virtual private gateway ou transit gateway

Une virtual private gateway appartient à un seul VPC. Elle termine le VPN, installe des routes dans les tables de ce VPC et s’arrête là. Elle n’a pas de modèle d’attachement : elle ne peut donc remettre du trafic ni à un autre VPC ni à un segment de sortie partagé. Cette portée d’un seul VPC constitue toute la limitation, et aucune route ajoutée dans le VPC ne la change.

Un transit gateway est un hub régional où le VPN, chaque VPC en spoke et un VPC de services partagés apparaissent comme des attachements. Il possède ses propres tables de routage, qui choisissent l’attachement recevant un préfixe donné.

Ce hub rend la sortie centralisée possible : le VPN arrive comme un attachement, le VPC de sortie comme un autre, et une table du transit gateway envoie les préfixes destinés à Internet du premier vers le second. Avec une virtual private gateway, il n’y a pas de second attachement où envoyer quoi que ce soit, et c’est pourquoi le design ne peut pas être corrigé après coup.

Le chemin de sortie pris en charge, saut par saut

Le design de référence comporte cinq sauts, et chaque flèche est une décision de routage à configurer. Le trafic quitte le réseau local vers l’attachement Site-to-Site VPN, la table du transit gateway le transmet à l’attachement du VPC de sortie, où la table du subnet l’envoie vers un NAT gateway public. Le NAT gateway traduit la source et l’internet gateway fait sortir le paquet.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Deux détails décident si les derniers sauts fonctionnent. Le NAT gateway doit être public, avec une elastic IP et une route vers une internet gateway, car un NAT gateway privé traduit entre réseaux et ne devient jamais une sortie Internet.

Prévoyez un NAT gateway par Availability Zone que vous comptez desservir, chaque table de subnet pointant vers celui de la zone. Gardez la table du transit gateway et les tables du VPC comme des objets distincts dans vos notes, car l’une choisit un attachement et l’autre une ressource à l’intérieur du VPC. Une route par défaut dans une seule des deux laisse la moitié du chemin indéfinie et produit les pannes partielles les plus difficiles à attribuer.

Le chemin de retour est là où ces designs échouent

Un NAT gateway conserve l’état des flux qu’il a déjà vus, si bien que les réponses à une connexion sortante reviennent sans nouvelle règle entrante. Cette propriété ne publie pas un service local sur Internet, et la traiter comme si c’était le cas coûte une journée à une équipe qui débogue une connexion qui n’aurait jamais abouti. Pour le trafic initié par le client, quatre routes doivent s’accorder : la politique locale, la table du transit gateway, la table du subnet de sortie et la table du subnet NAT. Ratez la dernière et la requête quitte le bâtiment tandis que la réponse meurt dans AWS.

Validez avec un vrai client derrière le VPN et regardez quelle adresse source publique il présente. Si c’est l’elastic IP du NAT gateway, la traduction a lieu ; si c’est autre chose, vous mesurez une autre sortie.

La version asymétrique de cette panne mérite d’être reconnue tôt. Quand la table du subnet NAT d’une Availability Zone possède la route de retour vers le préfixe client et qu’une autre ne l’a pas, les nouvelles connexions réussissent ou échouent selon la zone où le flux atterrit, et le schéma est mal lu comme un Internet instable. Comparez les tables de subnet de chaque zone desservie au lieu de réparer celle où le ticket a été ouvert, car la route manquante est toute la panne et rien ne doit changer de l’autre côté.

Quand un proxy explicite est le meilleur design

Un proxy HTTP sur une instance du VPC de sortie est une alternative légitime et souvent moins chère. Les clients sont configurés pour l’utiliser, le proxy ouvre sa propre connexion vers l’extérieur, et le chemin de retour devient son problème plutôt qu’un casse-tête de routage symétrique. Pour quelques applications, cela supprime l’essentiel du travail lié au transit gateway. Cela donne aussi une journalisation par utilisateur qu’un NAT gateway ne peut pas produire.

Il n’est pas transparent pour autant. Tout ce qui ignore les réglages du proxy, et chaque protocole qui n’est pas HTTP, ne suivra pas ce chemin.

Le choix dépend de ce que vos applications parlent réellement et de la quantité d’identité nécessaire dans les journaux. Là où elles parlent HTTP, le proxy mérite sa place ; là où il faut une sortie générale pour des protocoles arbitraires, le design avec transit gateway est celui qu’AWS prend en charge. Le décider en amont coûte moins cher que le découvrir une fois les tables de routage construites.