Cloud VPN nei in GCP-VM: brûk it ynterne IP, net it NAT-IP

As in lokaal netwurk in VPC berikt fia Cloud VPN, is it bestimmingsadres foar in Compute Engine-tsjinst normaal it ynterne adres fan de VM. It eksterne IPv4-adres is gjin twadde adres dat jo yn deselde privee rûte pleatse kinne. It measte betizing hjir komt derfan dat trije adressen mei trije taken as útwikselber behannele wurde, dus begjin mei te beneamen hokker in bepaald pakket brûkt.

Trije adressen, trije taken

Beneam alle trije foardat jo ien fan har debugge, want it antwurd feroaret it objekt dat jo dêrnei ûndersykje.

It earste heart by de tunnel. It twadde heart by jo rûte- en firewallûntwerp. It tredde heart by ynkommende ynternet tagong en wurdt mapt, net taheakke. In ûntwerp dat foar ien fan har wurket, seit neat oer de oare twa.

Wêrom't it eksterne adres gjin twadde ynterface is

De adresearringsgids is it gesach foar hoe't ynterne en eksterne berikberens op Compute Engine ferskille. In eksterne Compute Engine-IPv4 is in ien-op-ien mapping op 'e iennige ynterne NIC fan 'e ynstânsje, dus de gast sjocht nea in twadde ynterface of in twadde adres op dy NIC. Wat de VM binnen rapportearret is noch altyd ien primêr yntern adres.

Dêrom binne in privee klant dy't fia de tunnel nei 10.24.1.7 rûtet en in klant dy't it eksterne adres fan 'e VM rjochtet op ferskillende paden. In firewallregel iepenje foar it publike adres feroaret neat oan 'e VPC-rûte dy't it tunnelferkear drage moat, en in gastrûte bewurkje ferpleatst de mapping fan it platfoarm net. Kies it adres dat jo rûte beneamt, en kontrolearje dan allinnich de objekten dy't it bestjoere. Dy dissipline hellet it measte rieden út dit probleemoplossingspaad.

Kui it paad mei gcloud

Begjin by de ynstânsje en lês beide adressen út itselde objekt, sadat jo witte oer hokker jo dokumintaasje praat:

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

Befêstigje dan de routing en de tastimming dêr't it paad echt fan ôfhinklik is:

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 de oankundige en learde berikken fan 'e tunnel, de VPC-rûte foar it subnet fan 'e wurkdracht en de firewallregel dy't de lokale boarne tastiet. Dy trije moatte oerienkomme foardat in listener op 'e gast ea relevant is.

Kontrolearje dan de gast: harket de tsjinst op it ynterne adres, en giet syn werompaad wer troch de VPC? In listener dy't allinnich oan in publiek adresbân is, sil dizze test net helje, sels as elk objekt oan 'e wolkekant korrekt is.

In publike prefiks is in oare fraach

Neat fan it boppesteande betsjut dat elk adres dat binnen in VPN ferfierd wurdt RFC1918 wêze moat. In netwurk op ôfstân kin legitimaal nûmere wurde út 'e publike romte, mits it platfoarm de routing stipet en de operator it adresgesach hat. Dat is in normale ûntwerpkar.

Dat is net itselde as it behanneljen fan in gewoan ekstern NAT-adres as wie it in oar yntern subnetadres. It iene is in prefiks dat jo rûte, it oare is in mapping dy't it platfoarm op ynkommende tagong tapast.

Eksterne IPv6 en spesjaal ûntwurpen adresregelingen hawwe har eigen semantyk. As jo plan fan ien fan dy ôfhinklik is, lês dan de platfoarmdokumintaasje foar dy funksje ynstee fan te generalisearjen út it IPv4-gefal. De IPv4-mapping is it gewoane gefal, net it iennige, en de útsûnderingen hawwe elk har eigen regels.

Oerlaapjende berikken binne in oar probleem

Oerlaapjende privee berikken binne in echte reden wêrom't minsken nei it publike adres gripe, en it is de ferkearde hefboom. It bestimmingsadres feroarje nei it NAT-adres fan 'e VM lost de oerlaap net op; it feroaret foar hokker adres it pakket seit dat it is, sûnder te definiearjen hoe't it werompaad wurket.

Los de oerlaap bewust op: nûmerje opnij, brûk in stipe oersettingsûntwerp, of rûte troch in netwurk dêr't de prefiksen net botsingje. Elk fan dy is in ûntwerp mei in eigner. It NAT-adres is gjin ûntwerp.

Dokumintearje de twa fjilden apart

Skriuw de tunnelpartner en it bestimmingsadres fan 'e wurkdracht as twa aparte runbook-fjilden, elk mei de rûte en firewallregel dy't it stipet. In IPsec-tunnel dy't omheech komt fertelt jo allinnich dat de partijen it iens binne; hy seit neat oer op hokker adres de wurkdracht berikber is, en neat oer oft syn privee rûte folslein is.

Ferifiearje mei in echte klant oan 'e oare kant: los de namme op, befêstigje dat dy it ynterne adres weromjout, meitsje ferbining en kontrolearje it weromferkear. De Compute Engine-dokumintaasje oer IP-adressen is de referinsje foar it ûnderskied tusken yntern en ekstern dat hjirboppe brûkt is.