Quelle adresse IP source une passerelle NAT AWS utilise-t-elle vers un VPN ?

Vous ouvrez la console VPC parce qu’un partenaire a demandé quelle plage source arrivera par le VPN site à site. La page Passerelles NAT affiche une passerelle publique avec une Elastic IP associée, et la tentation est d’envoyer cette adresse et de passer à autre chose. C’est la bonne réponse pour le chemin internet et la mauvaise pour le chemin VPN, et la différence tient à la passerelle vers laquelle pointe la table de routage. Parcourez la route avant d’écrire la liste d’adresses autorisées.

Commencez par la page Passerelles NAT, pas par la liste d’adresses autorisées

La page Passerelles NAT vous donne le sous-réseau, le type et l’Elastic IP, et ces trois champs suffisent pour commencer. Ce qu’elle ne dit pas, c’est le chemin que prend ensuite le trafic. Cela vient des tables de routage associées au sous-réseau de la passerelle NAT.

Lisez d’abord le type, car public ou privé décide si une passerelle internet apparaîtra plus loin dans la chaîne. Lisez ensuite le sous-réseau, car c’est là que vit la seconde route.

Suivez les deux traductions

Les passerelles NAT publiques comme privées traduisent la source IPv4 privée de la charge de travail en l’adresse IPv4 privée de la passerelle NAT elle-même. Cette première traduction a lieu quel que soit le type. La seconde traduction est celle qu’on oublie : une passerelle NAT publique remet le trafic à la passerelle internet, qui associe l’adresse à l’Elastic IP associée.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

Sur le chemin privé, il n’y a pas de passerelle internet dans la chaîne. Lorsque le trafic sort par une passerelle de transit ou une passerelle privée virtuelle, le guide des passerelles NAT documente l’adresse privée de la passerelle NAT comme la source que reçoit le côté distant. C’est cette adresse que le partenaire doit autoriser, pas l’Elastic IP.

Le chemin VPN montre généralement l’adresse privée

Pour une charge de travail dans 10.20.1.0/24 qui atteint un préfixe partenaire, la table de routage du sous-réseau de la charge pointe vers la passerelle NAT, et la table de routage du sous-réseau de la passerelle NAT pointe vers le chemin de la passerelle privée. Les deux sauts comptent, et seul le second décide de ce que voit le partenaire. Si le sous-réseau NAT n’a aucune route vers le chemin VPN, le paquet n’arrive jamais, et c’est une défaillance différente d’une adresse source erronée.

Vérifiez cette seconde route avant même de parler d’adresses. Une route absente et une source mal déclarée se ressemblent exactement pour un partenaire qui ne voit tout simplement pas de trafic.

Quand une seconde traduction change la réponse

AWS propose aussi une correspondance NAT explicite et adaptée, une pour une, sur un attachement de passerelle de transit. Cette correspondance peut traduire la source une nouvelle fois avant que le service distant ne la voie, et ce n’est pas le comportement par défaut qui se contente de router. Comme elle doit être configurée volontairement, traitez-la comme une exception de conception et non comme quelque chose que vous héritez par accident. Si personne dans votre équipe ne se souvient l’avoir activée, supposez qu’elle est absente jusqu’à ce que vous ayez lu l’attachement.

Si votre conception l’utilise, la liste d’adresses autorisées doit décrire la correspondance finale et non l’adresse de la passerelle NAT. La même prudence vaut pour les chemins de disponibilité : lorsque plusieurs adresses de passerelle participent, l’ensemble source attendu est l’union, pas une adresse représentative. Notez à quelle traduction appartient chaque adresse, car une liste sans provenance est impossible à auditer plus tard.

On ne peut pas donner de service internet à une passerelle NAT privée en la pointant vers une passerelle internet ; AWS documente que ce trafic est écarté. Choisissez le type d’après le chemin complet, pas d’après le mot VPN dans l’exigence.

Écrivez le contrat sur lequel votre partenaire peut agir

Le contrat utilisable comporte quatre parties : la direction depuis laquelle les flux sont lancés, l’identité traduite que verra le partenaire, la route de retour pour cette identité et la portée de protection qui s’applique. Les flux de passerelle NAT sont lancés depuis le côté source pris en charge, ce n’est donc pas un service de redirection de ports entrants pour exposer une charge de travail privée. Le dire à voix haute tôt évite une revue de conception où chaque côté supposait que l’autre avait lancé le flux.

La traduction achète un soulagement du chevauchement d’adresses et une politique de source prévisible, et elle vous coûte l’identité individuelle de la charge de travail dans les journaux du partenaire. Si l’audit exige une attribution par charge de travail, gardez cette identité au niveau applicatif plutôt que de tenter de la retrouver à partir d’une adresse source traduite.

Vérifiez ensuite les deux tables de routage après tout changement, car un nouvel attachement ou un sous-réseau réassocié réécrit silencieusement la réponse.