Une Elastic IP EC2 n'est pas l'adresse VPN privée de l'instance

L'instance possède une adresse privée, l'Elastic IP y est associée, et une route pour ce /32 public est ajoutée au VPN en espérant que les deux deviennent la même chose. Elles ne le deviennent pas. Une Elastic IP est une traduction effectuée en dehors de l'invité, par la passerelle internet, sur le trafic qui emprunte le chemin internet. Le système d'exploitation de l'invité ne voit jamais cette adresse configurée sur une interface. L'ajouter à une interface de tunnel ne reproduit pas la traduction en amont et crée une seconde identité, contradictoire, pour la même machine.

Deux adresses, une instance

L'interface réseau de l'instance détient une adresse privée à l'intérieur du VPC, et c'est l'adresse que l'invité connaît. L'Elastic IP est associée à la même interface mais vit du côté public de la correspondance.

Tout ce qui atteint l'instance par internet arrive traduit vers l'adresse privée. Tout ce que l'instance envoie vers internet part avec l'Elastic IP comme source, là encore à cause de cette traduction.

À l'intérieur de l'invité, une adresse existe. À l'extérieur, deux. Cette asymétrie explique l'essentiel de la confusion dans ce domaine. L'invité ne peut pas configurer ce que la passerelle traduit. Il ne peut répondre que sur l'adresse qu'il détient réellement.

Ce que fait réellement la passerelle internet

La documentation AWS sur la passerelle internet décrit le dispositif : l'instance connaît son adresse IPv4 privée, et la passerelle fournit la traduction correspondante en IPv4 publique ou en Elastic IP pour le trafic du chemin internet.

C'est de la traduction d'adresses réseau, pas un alias. La correspondance est tenue par la passerelle, liée à l'association, et ne s'applique qu'aux paquets qui la traversent. Retirez l'association et l'identité publique disparaît sans que l'invité s'aperçoive de rien.

C'est pourquoi un paquet VPN privé adressé au /32 public n'est pas réinterprété comme un paquet privé vers l'adresse locale de l'invité. Le paquet suit la route à laquelle il correspond, qui l'envoie vers la passerelle internet, et le comportement de la passerelle dépend de l'autorisation du chemin dans les deux sens.

Pourquoi l'astuce de l'interface de tunnel échoue

Attribuer l'Elastic IP à une interface de tunnel demande à l'invité de traiter une adresse publique comme locale. Désormais deux choses revendiquent la même adresse : la traduction de la passerelle sur le chemin internet et l'interface locale à l'intérieur du tunnel. Le trafic de retour n'a pas de réponse cohérente sur celle qui s'applique.

Même lorsque cela semble fonctionner, la conception a masqué la vraie question. Les clients atteignent soit l'adresse privée par le tunnel, soit le point de terminaison public par internet, et les deux chemins ont des groupes de sécurité différents, une journalisation différente et des modes de défaillance différents.

L'adresse n'a jamais été le problème. Le choix du chemin l'était.

Trois objectifs, trois conceptions

Si l'objectif est un point de terminaison VPN public, l'Elastic IP est le bon outil : les pairs distants s'y connectent par internet et le transport chiffré se termine sur l'instance. Le trafic interne de l'application utilise ensuite l'adresse privée.

Si l'objectif est un accès privé à l'application, la destination est l'adresse privée ou un nom DNS privé qui y résout, et la route VPN, le groupe de sécurité et le chemin de retour doivent tous s'accorder. L'Elastic IP n'apparaît pas du tout dans cette conception.

Si l'objectif est une identité de sortie publique stable pour les utilisateurs VPN, c'est une conception NAT côté sortie, pas une adresse sur le tunnel du client. Trois objectifs qui se ressemblent produisent trois schémas différents, et un seul implique de placer une Elastic IP à un nouvel endroit.

Vérifiez le chemin choisi

Pour l'accès privé, confirmez que la route VPN couvre le préfixe privé, que la table de routage du VPC renvoie le trafic vers le tunnel, que le groupe de sécurité autorise la source du client et que le pare-feu du client autorise la réponse. Testez ensuite une vraie requête plutôt qu'un ping.

Pour l'accès public, confirmez la sortie internet du client, le routage de l'entrée publique et sa politique de sécurité. Qu'un client VPN puisse atteindre un point de terminaison public par le tunnel dépend des règles de sortie et du pare-feu du tunnel, pas de l'association de l'Elastic IP.

Si un nom d'hôte public doit fonctionner des deux côtés, utilisez une conception DNS qui répond avec l'adresse privée pour les clients VPN et l'adresse publique pour tous les autres, et gardez le certificat valide pour le nom plutôt que pour l'adresse. Ordre du travail : nommez l'objectif, choisissez l'adresse qui lui appartient, puis vérifiez routes, politique et une requête.