Cloud VPN till en VM på GCP: använd den interna IP-adressen, inte NAT-IP:n

När ett lokalt nätverk når ett VPC via Cloud VPN är målet för en Compute Engine-tjänst vanligtvis VM:ns interna adress. Den externa IPv4-adressen är inte en andra adress som du kan sätta in i samma privata rutt. Det mesta av förvirringen här kommer av att tre adresser med tre uppgifter behandlas som utbytbara, så börja med att namnge vilken en given paket använder.

Tre adresser, tre uppgifter

Namnge alla tre innan du felsöker någon av dem, eftersom svaret ändrar objektet du undersöker härnäst.

Den första hör till tunneln. Den andra hör till din rutt- och brandväggsdesign. Den tredje hör till inkommande internetåtkomst och mappas, inte kopplas. En design som fungerar för en av dem säger ingenting om de andra två.

Varför den externa adressen inte är ett andra gränssnitt

Adresseringsguiden är auktoriteten för hur intern och extern nåbarhet skiljer sig åt på Compute Engine. En extern Compute Engine-IPv4 är en en-till-en-mappning på instansens enda interna NIC, så gästen ser aldrig ett andra gränssnitt eller en andra adress på det NIC:et. Det VM rapporterar inifrån är fortfarande en primär intern adress.

Det är därför en privat klient som routar genom tunneln mot 10.24.1.7 och en klient som riktar in sig på VM:ns externa adress är på olika vägar. Att öppna en brandväggsregel för den publika adressen ändrar ingenting i VPC-rutten som måste bära tunneltrafiken, och att redigera en gästrutt flyttar inte plattformens mappning. Välj adressen som din rutt namnger och kontrollera sedan bara de objekt som styr den. Den disciplinen tar bort det mesta av gissningarna från den här felsökningsvägen.

Gå vägen med gcloud

Börja vid instansen och läs båda adresserna från samma objekt, så att du vet vilken din dokumentation talar om:

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

Bekräfta sedan routningen och behörigheten som vägen faktiskt beror på:

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

Läs tunnelns annonserade och inlärda intervall, VPC-rutten för arbetsbelastningens subnät och brandväggsregeln som tillåter den lokala källan. Dessa tre måste stämma innan en lyssnare på gästen ens är relevant.

Kontrollera sedan gästen: lyssnar tjänsten på den interna adressen, och går dess returväg tillbaka genom VPC:n? En lyssnare som bara är bunden till en publik adress kommer att misslyckas i detta test även när varje objekt på molnsidan är korrekt.

Ett publikt prefix är en annan fråga

Inget av ovanstående betyder att varje adress som bärs inuti en VPN måste vara RFC1918. Ett fjärrnätverk kan numreras legitimt från publikt utrymme, förutsatt att plattformen stöder routningen och operatören har adressbehörigheten. Det är ett normalt designval.

Det är inte samma sak som att behandla en vanlig extern NAT-adress som om den vore en annan intern subnätadress. Den ena är ett prefix du routar; den andra är en mappning som plattformen tillämpar på inkommande åtkomst.

Extern IPv6 och särskilt utformade adressupplägg har sin egen semantik. Om din plan beror på något av dem, läs plattformens dokumentation för den funktionen i stället för att generalisera från IPv4-fallet. IPv4-mappningen är det vanliga fallet, inte det enda, och undantagen har var sina regler.

Överlappande intervall är ett annat problem

Överlappande privata intervall är en verklig anledning till att människor griper efter den publika adressen, och det är fel spak. Att ändra målet till VM:ns NAT-adress löser inte överlappningen; det ändrar vilken adress paketet hävdar att det är till för, utan att definiera hur returvägen fungerar.

Lös överlappningen medvetet: numrera om, använd en stödd översättningsdesign eller routa genom ett nätverk där prefixen inte kolliderar. Var och en av dessa är en design med en ägare. NAT-adressen är inte en design.

Dokumentera de två fälten var för sig

Registrera tunnelpeer och arbetsbelastningens mål som två separata runbook-fält, var och ett med rutten och brandväggsregeln som stöder det. En IPsec-tunnel som kommer upp talar bara om att parterna är överens; den säger ingenting om vilken adress arbetsbelastningen nås på, och ingenting om huruvida dess privata rutt är komplett.

Verifiera med en riktig klient på andra sidan: slå upp namnet, bekräfta att det returnerar den interna adressen, anslut och kontrollera returtrafiken. Compute Engine-dokumentationen om IP-adresser är referensen för distinktionen mellan internt och externt som används ovan.