Cloud VPN vers une VM GCP : utilisez l’IP interne, pas l’IP NAT

Lorsqu’un réseau local atteint un VPC via Cloud VPN, la destination d’un service Compute Engine est normalement l’adresse interne de la VM. L’adresse IPv4 externe n’est pas une seconde adresse que vous pouvez substituer dans la même route privée. L’essentiel de la confusion ici vient du fait que trois adresses ayant trois rôles sont traitées comme interchangeables ; commencez donc par nommer celle qu’un paquet donné utilise.

Trois adresses, trois rôles

Nommez les trois avant de déboguer l’une d’elles, car la réponse change l’objet que vous inspectez ensuite.

La première appartient au tunnel. La deuxième appartient à votre conception de route et de pare-feu. La troisième appartient à l’accès entrant depuis Internet et elle est mappée, non attachée. Une conception qui fonctionne pour l’une ne dit rien des deux autres.

Pourquoi l’adresse externe n’est pas une seconde interface

Le guide d’adressage fait autorité pour la différence entre accessibilité interne et externe sur Compute Engine. Une IPv4 externe Compute Engine est un mappage un-pour-un sur l’unique NIC interne de l’instance : l’invité ne voit donc jamais une seconde interface ni une seconde adresse sur ce NIC. Ce que la VM signale à l’intérieur reste une adresse interne principale.

C’est pourquoi un client privé qui route vers 10.24.1.7 à travers le tunnel et un client qui cible l’adresse externe de la VM empruntent des chemins différents. Ouvrir une règle de pare-feu pour l’adresse publique ne change rien à la route du VPC qui doit transporter le trafic du tunnel, et modifier une route sur l’invité ne déplace pas le mappage de la plateforme. Choisissez l’adresse que votre route nomme, puis n’inspectez que les objets qui la gouvernent. Cette discipline élimine l’essentiel des suppositions dans ce chemin de dépannage.

Parcourir le chemin avec gcloud

Partez de l’instance et lisez les deux adresses sur le même objet, afin de savoir de laquelle votre documentation parle :

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Confirmez ensuite le routage et l’autorisation dont le chemin dépend réellement :

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Lisez les plages annoncées et apprises du tunnel, la route du VPC pour le sous-réseau de la charge de travail et la règle de pare-feu qui autorise la source locale. Ces trois éléments doivent concorder avant qu’un écouteur sur l’invité ne soit même pertinent.

Vérifiez ensuite l’invité : le service écoute-t-il sur l’adresse interne, et son chemin de retour repasse-t-il par le VPC ? Un écouteur lié uniquement à une adresse publique échouera à ce test même lorsque tous les objets côté cloud sont corrects.

Un préfixe public est une autre question

Rien de ce qui précède ne signifie que toute adresse transportée dans un VPN doit être RFC1918. Un réseau distant peut légitimement être numéroté dans l’espace public, à condition que la plateforme prenne en charge le routage et que l’opérateur détienne l’autorité sur l’adresse. C’est un choix de conception normal.

Ce n’est pas la même chose que de traiter une adresse NAT externe ordinaire comme s’il s’agissait d’une autre adresse de sous-réseau interne. L’une est un préfixe que vous routez ; l’autre est un mappage que la plateforme applique à l’accès entrant.

L’IPv6 externe et les agencements d’adresses spécialement conçus ont leur propre sémantique. Si votre plan dépend de l’un d’eux, lisez la documentation de la plateforme pour cette fonctionnalité plutôt que de généraliser à partir du cas IPv4. Le mappage IPv4 est le cas courant, pas le seul, et les exceptions ont chacune leurs propres règles.

Les plages qui se chevauchent sont un autre problème

Les plages privées qui se chevauchent sont une vraie raison de se tourner vers l’adresse publique, et c’est le mauvais levier. Changer la destination pour l’adresse NAT de la VM ne résout pas le chevauchement ; cela change l’adresse à laquelle le paquet prétend être destiné, sans définir comment fonctionne le chemin de retour.

Résolvez le chevauchement délibérément : renumérotez, utilisez une conception de traduction prise en charge ou routez via un réseau où les préfixes ne se heurtent pas. Chacune de ces options est une conception avec un responsable. L’adresse NAT n’est pas une conception.

Documentez les deux champs séparément

Consignez le pair du tunnel et la destination de la charge de travail comme deux champs de runbook distincts, chacun avec la route et la règle de pare-feu qui le soutiennent. Un tunnel IPsec qui monte vous dit seulement que les pairs sont d’accord ; il ne dit rien de l’adresse à laquelle la charge de travail est joignable, ni si sa route privée est complète.

Vérifiez avec un vrai client de l’autre côté : résolvez le nom, confirmez qu’il renvoie l’adresse interne, connectez-vous et contrôlez le trafic de retour. La documentation des adresses IP de Compute Engine est la référence pour la distinction interne-externe utilisée ci-dessus.