Cloud VPN a una VM de GCP: feu servir la IP interna, no la IP de NAT

Quan una xarxa local arriba a una VPC mitjançant Cloud VPN, la destinació d'un servei de Compute Engine normalment és l'adreça interna de la VM. L'adreça IPv4 externa no és una segona adreça que pugueu substituir dins de la mateixa ruta privada. La major part de la confusió en aquest àmbit ve de tractar tres adreces amb tres feines com si fossin intercanviables, així que comenceu per anomenar quina fa servir un paquet concret.

Tres adreces, tres feines

Anomeneu les tres abans de depurar-ne cap, perquè la resposta canvia l'objecte que inspeccioneu després.

La primera pertany al túnel. La segona pertany al disseny de la ruta i del tallafoc. La tercera pertany a l'accés d'entrada d'Internet i es mapeja, no s'adjunta. Un disseny que funciona per a una d'elles no diu res sobre les altres dues.

Per què l'adreça externa no és una segona interfície

La guia d'adreçament és l'autoritat sobre com difereixen la connectivitat interna i l'externa a Compute Engine. Una IPv4 externa de Compute Engine és un mapatge u a u sobre l'única NIC interna de la instància, de manera que el convidat no veu mai una segona interfície ni una segona adreça en aquesta NIC. El que la VM informa des de dins continua sent una adreça interna primària.

És per això que un client privat que encamina el trànsit pel túnel cap a 10.24.1.7 i un client que apunta a l'adreça externa de la VM van per camins diferents. Obrir una regla de tallafoc per a l'adreça pública no canvia res a la ruta de la VPC que ha de portar el trànsit del túnel, i editar una ruta al convidat no mou el mapatge de la plataforma. Trieu l'adreça que anomena la vostra ruta i, després, reviseu només els objectes que la governen. Aquesta disciplina elimina la major part de les conjectures d'aquest camí de resolució de problemes.

Recorreu el camí amb gcloud

Comenceu per la instància i llegiu les dues adreces del mateix objecte, perquè sapigueu de quina parla la vostra documentació:

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

Després confirmeu l'encaminament i el permís dels quals depèn realment el camí:

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

Llegiu els rangs anunciats i après del túnel, la ruta de la VPC per a la subxarxa de la càrrega de treball i la regla de tallafoc que permet l'origen local. Aquestes tres coses han de coincidir abans que un oient al convidat sigui ni tan sols rellevant.

Després reviseu el convidat: el servei escolta a l'adreça interna i la seva ruta de retorn torna a passar per la VPC? Un oient lligat només a una adreça pública fallarà aquesta prova fins i tot quan tots els objectes del costat del núvol siguin correctes.

Un prefix públic és una altra qüestió

Res de l'anterior no vol dir que tota adreça transportada dins d'una VPN hagi de ser RFC1918. Una xarxa remota es pot numerar legítimament des de l'espai públic, sempre que la plataforma admeti l'encaminament i l'operador tingui l'autoritat sobre l'adreça. És una decisió de disseny normal.

No és el mateix que tractar una adreça NAT externa ordinària com si fos una altra adreça de subxarxa interna. Una és un prefix que encamineu; l'altra és un mapatge que la plataforma aplica a l'accés d'entrada.

La IPv6 externa i els arranjaments d'adreces dissenyats especialment tenen la seva pròpia semàntica. Si el vostre pla depèn d'un d'aquests, llegiu la documentació de la plataforma per a aquesta funció en lloc de generalitzar a partir del cas IPv4. El mapatge IPv4 és el cas habitual, no l'únic, i les excepcions tenen cadascuna les seves regles.

Els rangs superposats són un altre problema

Els rangs privats superposats són un motiu real pel qual la gent recorre a l'adreça pública, i és la palanca equivocada. Canviar la destinació a l'adreça NAT de la VM no resol la superposició; canvia per a quina adreça diu el paquet que és, sense definir com funciona la ruta de retorn.

Resoleu la superposició deliberadament: renombreu, feu servir un disseny de traducció compatible o encamineu per una xarxa on els prefixos no col·lideixin. Cadascun d'aquests és un disseny amb un responsable. L'adreça NAT no és un disseny.

Documenteu els dos camps per separat

Registreu el parell del túnel i la destinació de la càrrega de treball com dos camps separats del runbook, cadascun amb la ruta i la regla de tallafoc que el sostenen. Un túnel IPsec que s'aixeca només us diu que els parells estan d'acord; no diu res sobre a quina adreça és accessible la càrrega de treball ni sobre si la seva ruta privada és completa.

Verifiqueu-ho amb un client real a l'altre costat: resoleu el nom, confirmeu que retorna l'adreça interna, connecteu-vos i comproveu el trànsit de retorn. La documentació d'adreces IP de Compute Engine és la referència per a la distinció entre intern i extern que s'ha fet servir més amunt.