Cloud VPN að VM á GCP: notaðu innra IP-ið, ekki NAT-IP-ið

Þegar staðbundið net nær VPC í gegnum Cloud VPN er áfangastaðurinn fyrir Compute Engine þjónustu venjulega innra heimilisfang VM. Ytra IPv4 heimilisfangið er ekki annað heimilisfang sem þú getur sett í sömu einkaleiðina. Mest rugl á þessu sviði kemur frá því að þrjú heimilisföng með þrjú hlutverk eru meðhöndluð sem skiptanleg, svo byrjaðu á að nefna hvaða eitt tiltekið pakki notar.

Þrjú heimilisföng, þrjú hlutverk

Nefndu öll þrjú áður en þú villuleitar eitthvað þeirra, því svarið breytir hlutnum sem þú skoðar næst.

Það fyrsta tilheyrir göngunni. Annað tilheyrir leiðar- og eldveggjahönnun þinni. Þriðja tilheyrir innkominni nettengingu og er varpað, ekki tengt. Hönnun sem virkar fyrir eitt þeirra segir ekkert um hin tvö.

Hvers vegna ytra heimilisfangið er ekki annað tengi

Heimilisfangaleiðbeiningin er valdið um hvernig innra og ytra aðgengi er frábrugðið á Compute Engine. Ytra IPv4 á Compute Engine er einn-á-einn vörpun á eina innra NIC tilviksins, svo gesturinn sér aldrei annað tengi eða annað heimilisfang á því NIC. Það sem VM tilkynnir að innan er enn eitt aðal innra heimilisfang.

Þess vegna eru einkaklient sem beinir umferð um gönguna að 10.24.1.7 og klient sem miðar á ytra heimilisfang VM á ólíkum leiðum. Að opna eldveggjareglu fyrir opinbera heimilisfangið breytir engu á VPC leiðinni sem verður að bera umferð ganganna, og að breyta leið á gestinum færir vörpun verkvangsins ekki. Veldu heimilisfangið sem leiðin þín nefnir, og athugaðu þá aðeins hlutina sem stjórna því. Sú agi fjarlægir mestu giskunina af þessari villuleitarleið.

Gakktu leiðina með gcloud

Byrjaðu á tilvikinu og lestu bæði heimilisföngin úr sama hlut, svo þú vitir hvort skjöl þín tala um:

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

Staðfestu síðan beininguna og heimildina sem leiðin byggir í raun á:

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

Lestu tilkynnt og lært svið ganganna, VPC leiðina fyrir undirnet vinnuálagsins og eldveggjaregluna sem leyfir staðbundna uppsprettuna. Þessi þrjú verða að stemma áður en hlustandi á gestinum er yfirhöfuð viðeigandi.

Athugaðu síðan gestinn: hlustar þjónustan á innra heimilisfanginu og fer endaleið hennar aftur í gegnum VPC? Hlustandi sem er aðeins bundinn við opinbert heimilisfang mun falla á þessu prófi jafnvel þótt hver hlutur á skýjuhliðinni sé réttur.

Opinbert forskeyti er önnur spurning

Ekkert af ofangreindu þýðir að hvert heimilisfang sem flutt er inni í VPN verði að vera RFC1918. Hægt er að númera fjarnet löglega úr opinberu rými, að því tilskildu að verkvangurinn styðji beininguna og rekstraraðilinn hafi heimildina yfir heimilisfanginu. Það er eðlileg hönnunarákvörðun.

Það er ekki það sama og að meðhöndla venjulegt ytra NAT-heimilisfang eins og það væri annað innra undirnetsheimilisfang. Annað er forskeyti sem þú beinir; hitt er vörpun sem verkvangurinn beitir á innkomið aðgengi.

Ytra IPv6 og sérstaklega hönnuð heimilisfangafyrirkomulag hafa sína eigin merkingarfræði. Ef áætlun þín byggir á einhverju þeirra skaltu lesa skjöl verkvangsins fyrir þann eiginleika í stað þess að alhæfa frá IPv4 tilfellinu. IPv4 vörpunin er algenga tilfellið, ekki það eina, og undantekningarnar hafa hver sínar reglur.

Skörun sviða er annað vandamál

Skörun einkasviða er raunveruleg ástæða þess að fólk grípur til opinbera heimilisfangsins, og það er rangt tæki. Að breyta áfangastaðnum í NAT-heimilisfang VM leysir skörunina ekki; það breytir því fyrir hvaða heimilisfang pakkinn segist vera, án þess að skilgreina hvernig endaleiðin virkar.

Leystu skörunina viljandi: númeraðu upp á nýtt, notaðu studda þýðingahönnun eða beindu í gegnum net þar sem forskeytin rekast ekki á. Hvert þeirra er hönnun með eiganda. NAT-heimilisfangið er ekki hönnun.

Skjalfestu reitina tvo sérstaklega

Skráðu göngufélagann og áfangastað vinnuálagsins sem tvo aðskilda runbook-reiti, hvorn með leiðinni og eldveggjareglunni sem styður hann. IPsec-ganga sem kemst upp segir þér aðeins að aðilarnir séu sammála; hún segir ekkert um á hvaða heimilisfangi vinnuálagið er aðgengilegt, og ekkert um hvort einkaleið þess sé heil.

Staðfestu með raunverulegum klient á hinum endanum: leystu nafnið, staðfestu að það skili innra heimilisfanginu, tengstu og athugaðu endaumferðina. Compute Engine skjöl um IP-heimilisföng eru tilvísunin fyrir aðgreininguna innra gegn ytra sem notuð er hér að ofan.