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

Når et lokalt nettverk når en VPC via Cloud VPN, er målet for en Compute Engine-tjeneste vanligvis VM-ens interne adresse. Den eksterne IPv4-adressen er ikke en andre adresse du kan sette inn i den samme private ruten. Mesteparten av forvirringen her kommer av at tre adresser med tre jobber behandles som utskiftbare, så begynn med å navngi hvilken en gitt pakke bruker.

Tre adresser, tre jobber

Navngi alle tre før du feilsøker noen av dem, fordi svaret endrer objektet du undersøker neste gang.

Den første hører til tunnelen. Den andre hører til rute- og brannmurdesignet ditt. Den tredje hører til innkommende internettilgang og blir mappet, ikke festet. Et design som fungerer for én av dem, sier ingenting om de to andre.

Hvorfor den eksterne adressen ikke er et andre grensesnitt

Adresseringsveiledningen er autoriteten for hvordan intern og ekstern tilgjengelighet er forskjellig på Compute Engine. En ekstern Compute Engine-IPv4 er en en-til-en-mapping på instansens eneste interne NIC, så gjesten ser aldri et andre grensesnitt eller en andre adresse på den NIC-en. Det VM rapporterer innenfra, er fortsatt én primær intern adresse.

Det er derfor en privat klient som ruter gjennom tunnelen mot 10.24.1.7, og en klient som retter seg mot VM-ens eksterne adresse, er på forskjellige veier. Å åpne en brannmurregel for den offentlige adressen endrer ingenting i VPC-ruten som må bære tunneltrafikken, og redigering av en gjesterute flytter ikke plattformens mapping. Velg adressen ruten din navngir, og kontroller deretter bare objektene som styrer den. Den disiplinen fjerner mesteparten av gjettingen fra denne feilsøkingsveien.

Gå veien med gcloud

Start ved instansen og les begge adressene fra samme objekt, slik at du vet hvilken dokumentasjonen din snakker om:

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

Bekreft deretter rutingen og tillatelsen som veien faktisk avhenger 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 tunnelens annonserte og lærte områder, VPC-ruten for arbeidsbelastningens subnett og brannmurregelen som tillater den lokale kilden. Disse tre må stemme før en lytter på gjesten i det hele tatt er relevant.

Kontroller deretter gjesten: lytter tjenesten på den interne adressen, og går returveien tilbake gjennom VPC-en? En lytter som bare er bundet til en offentlig adresse, vil feile denne testen selv når hvert objekt på skysiden er riktig.

Et offentlig prefiks er et annet spørsmål

Ingenting av det ovenstående betyr at hver adresse som bæres inne i en VPN må være RFC1918. Et eksternt nettverk kan med rette nummereres fra offentlig rom, forutsatt at plattformen støtter rutingen og operatøren har adressemyndigheten. Det er et normalt designvalg.

Det er ikke det samme som å behandle en vanlig ekstern NAT-adresse som om den var en annen intern subnettadresse. Den ene er et prefiks du ruter; den andre er en mapping plattformen bruker på innkommende tilgang.

Ekstern IPv6 og spesielt utformede adresseoppsett har sin egen semantikk. Hvis planen din avhenger av en av dem, les plattformdokumentasjonen for den funksjonen i stedet for å generalisere fra IPv4-tilfellet. IPv4-mappingen er det vanlige tilfellet, ikke det eneste, og unntakene har hver sine regler.

Overlappende områder er et annet problem

Overlappende private områder er en reell grunn til at folk griper etter den offentlige adressen, og det er feil spak. Å endre målet til VM-ens NAT-adresse løser ikke overlappingen; det endrer hvilken adresse pakken hevder å være for, uten å definere hvordan returveien fungerer.

Løs overlappingen bevisst: omnummerer, bruk et støttet oversettelsesdesign, eller rut gjennom et nettverk der prefiksene ikke kolliderer. Hver av disse er et design med en eier. NAT-adressen er ikke et design.

Dokumenter de to feltene hver for seg

Registrer tunnelpeeren og arbeidsbelastningsmålet som to separate runbook-felt, hvert med ruten og brannmurregelen som støtter det. En IPsec-tunnel som kommer opp forteller deg bare at partene er enige; den sier ingenting om hvilken adresse arbeidsbelastningen er tilgjengelig på, og ingenting om hvorvidt dens private rute er komplett.

Verifiser med en ekte klient på den andre siden: slå opp navnet, bekreft at det returnerer den interne adressen, koble til og kontroller returtrafikken. Compute Engine-dokumentasjonen om IP-adresser er referansen for skillet mellom intern og ekstern som brukes ovenfor.