Cloud VPN til ein VM på GCP: bruk den interne IP-en, ikkje NAT-IP-en

Når eit lokalt nettverk når ein VPC via Cloud VPN, er målet for ein Compute Engine-teneste vanlegvis den interne adressa til VM-en. Den eksterne IPv4-adressa er ikkje ei andre adresse du kan setje inn i den same private ruta. Mesteparten av forvirringa her kjem av at tre adresser med tre oppgåver vert handsama som utbyttbare, så byrja med å namngje kva ei gitt pakke brukar.

Tre adresser, tre oppgåver

Namngje alle tre før du feilsøkjer noka av dei, fordi svaret endrar objektet du undersøkjer neste gong.

Den første høyrer til tunnelen. Den andre høyrer til rute- og brannmurdesignet ditt. Den tredje høyrer til innkommande internettilgang og vert mappa, ikkje fest. Eit design som fungerer for éin av dei, seier ingenting om dei to andre.

Kvifor den eksterne adressa ikkje er eit andre grensesnitt

Adresseringsrettleiinga er autoriteten for korleis intern og ekstern tilgjengelegheit skil seg på Compute Engine. Ein ekstern Compute Engine-IPv4 er ei ein-til-ein-mapping på den einaste interne NIC-en til instansen, så gjesten ser aldri eit andre grensesnitt eller ei andre adresse på den NIC-en. Det VM rapporterer innanfrå, er framleis éi primær intern adresse.

Det er derfor ein privat klient som rutar gjennom tunnelen mot 10.24.1.7, og ein klient som rettar seg mot den eksterne adressa til VM-en, er på ulike vegar. Å opne ein brannmurregel for den offentlege adressa endrar ingenting i VPC-ruta som må bera tunneltrafikken, og redigering av ei gjesterute flyttar ikkje mappinga til plattforma. Vel adressa ruta di namngjev, og kontroller deretter berre objekta som styrer henne. Den disiplinen fjernar mesteparten av gjettinga frå denne feilsøkingsvegen.

Gå vegen med gcloud

Start ved instansen og les båe adressene frå same objekt, slik at du veit kva dokumentasjonen din snakkar om:

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

Stadfest deretter rutinga og løyvet som vegen faktisk er avhengig av:

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

Les dei annonserte og lærde områda til tunnelen, VPC-ruta for subnettet til arbeidslasta og brannmurregelen som lèt den lokale kjelda gjennom. Desse tre må stemma før ein lyttar på gjesten i det heile er relevant.

Kontroller deretter gjesten: lyttar tenesta på den interne adressa, og går returvegen attende gjennom VPC-en? Ein lyttar som berre er bunden til ei offentleg adresse, vil feile denne testen sjølv når kvart objekt på skysida er rett.

Eit offentleg prefiks er eit anna spørsmål

Ingenting av det ovanståande tyder på at kvar adresse som vert boren inne i ein VPN må vere RFC1918. Eit nettverk på avstand kan med rette nummererast frå offentleg rom, så sant plattforma støttar rutinga og operatøren har adressemakta. Det er eit normalt designval.

Det er ikkje det same som å handsame ei vanleg ekstern NAT-adresse som om ho var ei anna intern subnettadresse. Den eine er eit prefiks du rutar; den andre er ei mapping plattforma brukar på innkommande tilgang.

Ekstern IPv6 og spesielt utforma adresseoppsett har si eiga semantikk. Viss planen din er avhengig av eitt av dei, les plattformdokumentasjonen for den funksjonen i staden for å generalisere frå IPv4-tilfellet. IPv4-mappinga er det vanlege tilfellet, ikkje det einaste, og unntaka har kvar sine reglar.

Overlappande område er eit anna problem

Overlappande private område er ein reell grunn til at folk grip etter den offentlege adressa, og det er feil spak. Å endre målet til NAT-adressa til VM-en løyser ikkje overlappinga; det endrar kva adresse pakka hevdar å vere for, utan å definere korleis returvegen fungerer.

Løys overlappinga medvite: nummerer om, bruk eit støtta omsetjingsdesign, eller rut gjennom eit nettverk der prefiksa ikkje kolliderer. Kvart av desse er eit design med ein eigar. NAT-adressa er ikkje eit design.

Dokumenter dei to felta kvar for seg

Registrer tunnelpeeren og målet for arbeidslasta som to separate runbook-felt, kvart med ruta og brannmurregelen som støttar det. Ein IPsec-tunnel som kjem opp fortel deg berre at partane er samde; han seier ingenting om kva adresse arbeidslasta er tilgjengeleg på, og ingenting om korvidt den private ruta hennar er komplett.

Verifiser med ein ekte klient på den andre sida: slå opp namnet, stadfest at det returnerer den interne adressa, kople til og kontroller returtrafikken. Compute Engine-dokumentasjonen om IP-adresser er referansen for skillet mellom intern og ekstern som er brukt ovanfor.