Cloud VPN naar een GCP-VM: gebruik het interne IP, niet het NAT-IP

Wanneer een on-premises netwerk via Cloud VPN een VPC bereikt, is de bestemming voor een Compute Engine-service meestal het interne adres van de VM. Het externe IPv4-adres is geen tweede adres dat u in dezelfde privéroute kunt zetten. De meeste verwarring hier ontstaat doordat drie adressen met drie taken als uitwisselbaar worden behandeld, dus begin met het benoemen welke een bepaald pakket gebruikt.

Drie adressen, drie taken

Benoem alle drie voordat u een ervan debugt, want het antwoord bepaalt welk object u hierna onderzoekt.

De eerste hoort bij de tunnel. De tweede hoort bij uw route- en firewallontwerp. De derde hoort bij inkomende internettoegang en wordt gemapt, niet aangehecht. Een ontwerp dat voor een van hen werkt, zegt niets over de andere twee.

Waarom het externe adres geen tweede interface is

De adresseringsgids is de autoriteit voor hoe interne en externe bereikbaarheid op Compute Engine verschillen. Een extern Compute Engine-IPv4 is een één-op-één-toewijzing op de enige interne NIC van de instantie, dus de gast ziet nooit een tweede interface of een tweede adres op die NIC. Wat de VM van binnenuit rapporteert, is nog steeds één primair intern adres.

Daarom zitten een private client die via de tunnel naar 10.24.1.7 routeert en een client die het externe adres van de VM als doel heeft, op verschillende paden. Een firewallregel openen voor het openbare adres verandert niets aan de VPC-route die het tunnelverkeer moet dragen, en het bewerken van een gastroute verplaatst de toewijzing van het platform niet. Kies het adres dat uw route benoemt en controleer daarna alleen de objecten die het beheren. Die discipline haalt het meeste giswerk uit dit probleemoplossingspad.

Loop het pad met gcloud

Begin bij de instantie en lees beide adressen uit hetzelfde object, zodat u weet over welke uw documentatie spreekt:

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

Bevestig daarna de routering en de toestemming waarvan het pad echt afhangt:

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

Lees de aangekondigde en geleerde bereiken van de tunnel, de VPC-route voor het subnet van de workload en de firewallregel die de lokale bron toestaat. Deze drie moeten overeenkomen voordat een listener op de gast überhaupt relevant is.

Controleer daarna de gast: luistert de service op het interne adres, en gaat het retourpad weer door de VPC? Een listener die alleen aan een openbaar adres is gebonden, zal deze test falen zelfs wanneer elk object aan de cloudzijde correct is.

Een openbaar prefix is een andere vraag

Niets van het bovenstaande betekent dat elk adres binnen een VPN RFC1918 moet zijn. Een netwerk op afstand mag legitiem uit de openbare ruimte worden genummerd, mits het platform de routering ondersteunt en de operator de adresbevoegdheid heeft. Dat is een normale ontwerpkeuze.

Dat is niet hetzelfde als een gewoon extern NAT-adres behandelen alsof het een ander intern subnetadres is. Het ene is een prefix dat u routeert; het andere is een toewijzing die het platform op inkomende toegang toepast.

Extern IPv6 en speciaal ontworpen adresindelingen hebben hun eigen semantiek. Als uw plan van een daarvan afhangt, lees dan de platformdocumentatie voor die functie in plaats van te generaliseren vanuit het IPv4-geval. De IPv4-toewijzing is het gewone geval, niet het enige, en de uitzonderingen hebben elk hun eigen regels.

Overlappende bereiken zijn een ander probleem

Overlappende privébereiken zijn een echte reden waarom mensen naar het openbare adres grijpen, en het is de verkeerde hefboom. De bestemming wijzigen naar het NAT-adres van de VM lost de overlap niet op; het verandert voor welk adres het pakket zegt te zijn, zonder te bepalen hoe het retourpad werkt.

Los de overlap bewust op: hernummer, gebruik een ondersteund vertaalontwerp of routeer via een netwerk waar de prefixen niet botsen. Elk daarvan is een ontwerp met een eigenaar. Het NAT-adres is geen ontwerp.

Documenteer de twee velden apart

Leg de tunnelpeer en de bestemming van de workload vast als twee afzonderlijke runbookvelden, elk met de route en de firewallregel die het ondersteunen. Een IPsec-tunnel die omhoog komt, vertelt u alleen dat de partijen het eens zijn; hij zegt niets over op welk adres de workload bereikbaar is, en niets over of het privépad volledig is.

Verifieer met een echte client aan de andere kant: los de naam op, bevestig dat die het interne adres teruggeeft, maak verbinding en controleer het retourverkeer. De Compute Engine-documentatie over IP-adressen is de referentie voor het onderscheid tussen intern en extern dat hierboven is gebruikt.