Cloud VPN GCP-ko VM batera: erabili barneko IPa, ez NAT IPa

Lokala den sare bat Cloud VPN bidez VPC batera iristen denean, Compute Engine zerbitzu baten helmuga VMren barneko helbidea izan ohi da. Kanpoko IPv4 helbidea ez da ibilbide pribatu berean ordezkatu dezakezun bigarren helbidea. Arlo honetako nahasmen gehiena hiru zeregin dituzten hiru helbide trukagarri gisa tratatzetik dator, beraz, hasi pakete jakin batek zein erabiltzen duen izendatzen.

Hiru helbide, hiru zeregin

Izenda itzazu hirurak horietako edozein araztu aurretik, erantzunak hurrengo egiaztatuko duzun objektua aldatzen baitu.

Lehenengoa tunelekoa da. Bigarrena zure ibilbide eta suebaki diseinuarena. Hirugarrena sarrerako internet sarbidearena da eta mapatu egiten da, ez da erantsi. Horietako batentzat balio duen diseinuak ez du ezer esaten beste biei buruz.

Zergatik kanpoko helbidea ez den bigarren interfaze bat

Helbideratze gidak du autoritatea Compute Enginen barneko eta kanpoko irisgarritasunak nola bereizten diren jakiteko. Compute Engineko kanpoko IPv4 bat instantziaren barneko NIC bakarrera egindako bat-bateko mapatzea da, beraz ostalariak ez du inoiz bigarren interfazerik edo bigarren helbiderik ikusten NIC horretan. VMak barrutik jakinarazten duena barneko helbide nagusi bat da oraindik.

Horregatik daude tunelaren bidez 10.24.1.7 helbidera bideratzen duen bezero pribatu bat eta VMaren kanpoko helbidea helburu duen bezero bat ibilbide desberdinetan. Helbide publikorako suebaki arau bat irekitzeak ez du ezer aldatzen tunelaren trafikoa eraman behar duen VPC ibilbidean, eta ostalarian ibilbide bat editatzeak ez du plataformaren mapatzea mugitzen. Aukera ezazu zure ibilbideak izendatzen duen helbidea, eta gero egiaztatu hura gobernatzen duten objektuak soilik. Diziplina horrek asmatzeko gehiena kentzen du arazoak konpontzeko bide honetatik.

Ibilbidea gcloud-rekin egin

Hasi instantziatik eta irakurri bi helbideak objektu beretik, zure dokumentazioak zeini buruz hitz egiten duen jakiteko:

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

Gero berretsi bideak benetan mendeko dituen bideratzea eta baimena:

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

Irakurri tunelek iragarritako eta ikasitako barrutiak, lan-kargaren azpisarearen VPC ibilbidea eta tokiko iturburua onartzen duen suebaki araua. Hirurek bat etorri behar dute ostalariko entzule bat behin ere garrantzitsua izan baino lehen.

Gero egiaztatu ostalaria: zerbitzuak barneko helbidean entzuten al du, eta haren itzulera-bideak VPCtik berriro igarotzen al du? Helbide publiko batera soilik lotutako entzule batek huts egingo du proba honetan, hodeiko aldeko objektu guztiak zuzenak direnean ere.

Aurrizki publikoa beste galdera bat da

Aurrekoak ez du esan nahi VPN baten barruan eroaten den helbide oro RFC1918 izan behar denik. Urrutiko sare bat espazio publikotik zenbakia daiteke zilegi, plataformak bideratzea onartzen badu eta operadoreak helbidearen aginpidea badu. Diseinu aukeraketa arrunta da.

Ez da gauza bera kanpoko NAT helbide arrunt bat barneko azpisare helbide bat balitz bezala tratatzea. Bata bideratzen duzun aurrizki bat da; bestea plataformak sarrerako sarbideari aplikatzen dion mapatzea da.

Kanpoko IPv6ak eta bereziki diseinatutako helbide antolamenduek beren semantika dute. Zure plana horietako baten mende badago, irakurri plataformaren dokumentazioa eginbide horretarako, IPv4 kasutik orokortu beharrean. IPv4 mapatzea ohiko kasua da, ez bakarra, eta salbuespenek bakoitzak bere arauak ditu.

Gainjartzen diren barrutiak beste arazo bat dira

Gainjartzen diren barruti pribatuak helbide publikora jendea jotzeko benetako arrazoi bat dira, eta palanka okerra da. Helmuga VMaren NAT helbidera aldatzeak ez du gainjartzea konpontzen; paketeak zein helbiderentzat dioen aldatzen du, itzulera-bidea nola dabilen zehaztu gabe.

Konpondu gainjartzea nahita: zenbaki berriak eman, onartutako itzulpen diseinu bat erabili edo aurrizkiak talka egiten ez duten sare batetik bideratu. Horietako bakoitza jabea duen diseinu bat da. NAT helbidea ez da diseinu bat.

Dokumentatu bi eremuak bereizita

Erregistratu tunelaren parekoa eta lan-kargaren helmuga runbook eremu bereizi gisa, bakoitza hura eusten duen ibilbide eta suebaki arauarekin. Igotzen den IPsec tunel batek aldeak ados daudela besterik ez dizu esaten; ez du ezer esaten lan-karga zein helbidetan den irisgarri, ez eta haren ibilbide pribatua osoa ote den ere.

Egiaztatu beste aldean benetako bezero batekin: ebatzi izena, berretsi barneko helbidea itzultzen duela, konektatu eta egiaztatu itzulera-trafikoa. Compute Engine IP helbideen dokumentazioa da goian erabilitako barneko eta kanpoko arteko bereizketarako erreferentzia.