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

Når et lokalt netværk når en VPC via Cloud VPN, er destinationen for en Compute Engine-tjeneste normalt VM'ens interne adresse. Den eksterne IPv4-adresse er ikke en anden adresse, du kan sætte ind i den samme private rute. Det meste af forvirringen her stammer fra, at tre adresser med tre opgaver behandles som udskiftelige, så begynd med at navngive, hvilken en given pakke bruger.

Tre adresser, tre opgaver

Navngiv alle tre, før du fejlretter nogen af dem, fordi svaret ændrer det objekt, du undersøger næste gang.

Den første hører til tunnelen. Den anden hører til dit rute- og firewalldesign. Den tredje hører til indgående internetadgang og bliver mappet, ikke tilknyttet. Et design, der virker for en af dem, siger intet om de to andre.

Hvorfor den eksterne adresse ikke er et andet interface

Adresseringsguiden er autoriteten for, hvordan intern og ekstern tilgængelighed adskiller sig på Compute Engine. En ekstern Compute Engine-IPv4 er en en-til-en-mapping på instansens eneste interne NIC, så gæsten ser aldrig et andet interface eller en anden adresse på det NIC. Det, VM'en rapporterer indeni, er stadig én primær intern adresse.

Det er derfor, en privat klient, der router gennem tunnelen mod 10.24.1.7, og en klient, der peger på VM'ens eksterne adresse, er på forskellige veje. At åbne en firewallregel for den offentlige adresse ændrer intet ved den VPC-rute, der skal bære tunneltrafikken, og redigering af en gæsterute flytter ikke platformens mapping. Vælg den adresse, din rute navngiver, og kontroller derefter kun de objekter, der styrer den. Den disciplin fjerner det meste af gætteriet fra denne fejlretningsvej.

Gå vejen med gcloud

Start ved instansen, og læs begge adresser fra det samme objekt, så du ved, hvilken din dokumentation taler om:

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

Bekræft derefter den routing og den tilladelse, som vejen faktisk afhænger af:

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 tunnelens annoncerede og indlærte intervaller, VPC-ruten for arbejdsbelastningens undernet og den firewallregel, der tillader den lokale kilde. De tre skal stemme overens, før en lytter på gæsten overhovedet er relevant.

Kontroller derefter gæsten: lytter tjenesten på den interne adresse, og fører dens returvej tilbage gennem VPC'en? En lytter, der kun er bundet til en offentlig adresse, vil fejle denne test, selv når hvert objekt på cloud-siden er korrekt.

Et offentligt præfiks er et andet spørgsmål

Intet af ovenstående betyder, at hver adresse, der bæres inde i en VPN, skal være RFC1918. Et fjernnetværk kan med rette nummereres fra offentligt rum, forudsat at platformen understøtter routing, og operatøren har adressemyndigheden. Det er et normalt designvalg.

Det er ikke det samme som at behandle en almindelig ekstern NAT-adresse, som om den var en anden intern undernetsadresse. Den ene er et præfiks, du router; den anden er en mapping, platformen anvender på indgående adgang.

Ekstern IPv6 og særligt designede adresseordninger har deres egen semantik. Hvis din plan afhænger af en af dem, så læs platformens dokumentation for den funktion i stedet for at generalisere fra IPv4-tilfældet. IPv4-mappingen er det almindelige tilfælde, ikke det eneste, og undtagelserne har hver deres regler.

Overlappende intervaller er et andet problem

Overlappende private intervaller er en reel grund til, at folk griber efter den offentlige adresse, og det er den forkerte håndtag. At ændre destinationen til VM'ens NAT-adresse løser ikke overlapningen; det ændrer, hvilken adresse pakken hævder at være til, uden at definere, hvordan returvejen fungerer.

Løs overlapningen bevidst: omnummerér, brug et understøttet oversættelsesdesign, eller rut gennem et netværk, hvor præfikserne ikke støder sammen. Hver af dem er et design med en ejer. NAT-adressen er ikke et design.

Dokumentér de to felter hver for sig

Registrér tunnelpeer og arbejdsbelastningsdestination som to separate runbook-felter, hver med den rute og firewallregel, der understøtter det. En IPsec-tunnel, der kommer op, fortæller dig kun, at parterne er enige; den siger intet om, hvilken adresse arbejdsbelastningen kan nås på, og intet om, hvorvidt dens private rute er komplet.

Verificér med en rigtig klient på den anden side: slå navnet op, bekræft, at det returnerer den interne adresse, opret forbindelse, og kontroller returtrafikken. Compute Engine-dokumentationen om IP-adresser er referencen for den intern-ekstern-skel, der bruges ovenfor.