Cloud VPN na ’n GCP-VM: gebruik die interne IP, nie die NAT-IP nie

Sodra ’n plaaslike netwerk ’n VPC deur Cloud VPN bereik, is die bestemming vir ’n Compute Engine-diens gewoonlik die VM se interne adres. Die eksterne IPv4-adres is nie ’n tweede adres wat jy in dieselfde private roete kan instuur nie. Die meeste verwarring hier kom daarvan dat drie adresse met drie take as uitruilbaar beskou word, so begin deur te benoem watter een ’n gegewe pakket gebruik.

Drie adresse, drie take

Benoem al drie voordat jy enigeen ontfout, want die antwoord verander die objek wat jy volgende ondersoek.

Die eerste een hoort by die tonnel. Die tweede hoort by jou roete- en brandmuurontwerp. Die derde hoort by inkomende internettoegang en word gekarteer, nie aangeheg nie. ’n Ontwerp wat vir een van hulle werk, sê niks oor die ander twee nie.

Waarom die eksterne adres nie ’n tweede koppelvlak is nie

Die adresseringsgids is die gesag vir hoe interne en eksterne bereikbaarheid op Compute Engine verskil. ’n Compute Engine eksterne IPv4 is ’n een-tot-een-kartering op die instansie se enkele interne NIC, so die gassisteem sien nooit ’n tweede koppelvlak of ’n tweede adres op daardie NIC nie. Wat die VM binne rapporteer, is steeds een primêre interne adres.

Dit is waarom ’n private kliënt wat deur die tonnel na 10.24.1.7 roeteer en ’n kliënt wat die VM se eksterne adres teiken, op verskillende paaie is. Om ’n brandmuurreël vir die publieke adres oop te maak, verander niks aan die VPC-roete wat die tonnelverkeer moet dra nie, en om ’n gassisteemroete te wysig, skuif nie die platform se kartering nie. Kies die adres wat jou roete benoem en kyk dan net na die objekte wat dit beheer. Daardie dissipline verwyder die meeste raaiskote uit hierdie foutsporingspad.

Stap die pad met gcloud

Begin by die instansie en lees albei adresse uit dieselfde objek, sodat jy weet van watter een jou dokumentasie praat:

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

Bevestig dan die roetering en die toestemming waarvan die pad werklik afhang:

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 die tonnel se aangekondigde en geleerde reekse, die VPC-roete vir die werklassubnet en die brandmuurreël wat die plaaslike bron toelaat. Daardie drie moet ooreenstem voordat ’n luisteraar op die gassisteem hoegenaamd ter sprake is.

Kyk dan na die gassisteem: luister die diens op die interne adres, en wys sy terugpad terug deur die VPC? ’n Luisteraar wat net aan ’n publieke adres gebind is, sal hierdie toets faal selfs wanneer elke wolkekant-objek korrek is.

’n Publieke voorvoegsel is ’n ander vraag

Niks van die bostaande beteken dat elke adres wat binne ’n VPN gedra word RFC1918 moet wees nie. ’n Afgeleë netwerk kan wettig uit publieke ruimte genommer word, mits die platform die roetering ondersteun en die operateur die adresgesag het. Dit is ’n normale ontwerpkeuse.

Dit is nie dieselfde as om ’n gewone eksterne NAT-adres te behandel asof dit ’n ander interne subnetadres is nie. Een is ’n voorvoegsel wat jy roeteer; die ander is ’n kartering wat die platform op inkomende toegang toepas.

Eksterne IPv6 en spesiaal ontwerpte adresreëlings het hul eie semantiek. As jou plan van een van dié afhang, lees die platformdokumentasie vir daardie funksie eerder as om van die IPv4-geval te veralgemeen. Die IPv4-kartering is die algemene geval, nie die enigste nie, en die uitsonderings het elkeen hul eie reëls.

Oorvleuelende reekse is ’n ander probleem

Oorvleuelende private reekse is ’n werklike rede waarom mense na die publieke adres gryp, en dit is die verkeerde hefboom. Om die bestemming na die VM se NAT-adres te verander, los nie die oorvleueling op nie; dit verander vir watter adres die pakket sê dit is, sonder om te definieer hoe die terugpad werk.

Los die oorvleueling doelbewus op: hernommer, gebruik ’n ondersteunde vertaalontwerp, of roeteer deur ’n netwerk waar die voorvoegsels nie bots nie. Elkeen van dié is ’n ontwerp met ’n eienaar. Die NAT-adres is nie ’n ontwerp nie.

Dokumenteer die twee velde afsonderlik

Teken die tonnel-eweknie en die werklasbestemming as twee afsonderlike runbook-velde aan, elkeen met die roete en brandmuurreël wat dit ondersteun. ’n IPsec-tonnel wat opkom, sê net dat die eweknieë eens is; dit sê niks oor watter adres die werklas bereikbaar is nie, en niks oor of sy private roete volledig is nie.

Verifieer met ’n werklike kliënt aan die ander kant: los die naam op, bevestig dat dit die interne adres teruggee, maak verbinding en kontroleer die terugverkeer. Die Compute Engine IP-adresdokumentasie is die verwysing vir die interne-versus-eksterne onderskeid wat hierbo gebruik word.