Ko lokalno omrežje doseže VPC prek Cloud VPN, je cilj storitve Compute Engine običajno notranji naslov VM. Zunanji naslov IPv4 ni drugi naslov, ki bi ga lahko vstavili v isto zasebno pot. Večina zmede na tem področju izhaja iz tega, da se trije naslovi s tremi nalogami obravnavajo kot zamenljivi, zato začnite z imenovanjem, katerega uporablja določen paket.

Trije naslovi, tri naloge

Imenujte vse tri, preden katero koli razhroščujete, ker odgovor spremeni objekt, ki ga boste pregledali naslednjič.

AddressJob
Cloud VPN endpointwhere the IPsec peers meet
Internal IPthe address your route and firewall must name
External IPv4the platform's inbound mapping, not a guest address

Prvi pripada tunelu. Drugi pripada vaši zasnovi poti in požarnega zidu. Tretji pripada dohodnemu internetnemu dostopu in se preslika, ne pripne. Zasnova, ki deluje za enega od njih, ne pove ničesar o drugih dveh.

Zakaj zunanji naslov ni drugi vmesnik

Vodnik po naslavljanju je merodajen za to, kako se v Compute Engine razlikujeta notranja in zunanja dosegljivost. Zunanji naslov IPv4 v Compute Engine je preslikava ena proti ena na edini notranji NIC instance, zato gost nikoli ne vidi drugega vmesnika ali drugega naslova na tem NIC. Kar VM poroča od znotraj, je še vedno en primarni notranji naslov.

Zato sta zasebni odjemalec, ki usmerja promet skozi tunel proti 10.24.1.7, in odjemalec, ki cilja zunanji naslov VM, na različnih poteh. Odpiranje pravila požarnega zidu za javni naslov ne spremeni ničesar na poti v VPC, ki mora nositi promet tunela, urejanje poti v gostu pa ne premakne preslikave platforme. Izberite naslov, ki ga imenuje vaša pot, in nato preverjajte samo objekte, ki ga upravljajo. Ta disciplina odstrani večino ugibanja s te poti odpravljanja težav.

Prehodite pot z gcloud

Začnite pri instanci in preberite oba naslova iz istega objekta, da boste vedeli, o katerem govori vaša dokumentacija:

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

Nato potrdite usmerjanje in dovoljenje, od katerih je pot v resnici odvisna:

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

Preberite oglaševane in naučene obsege tunela, pot v VPC za podomrežje delovne obremenitve in pravilo požarnega zidu, ki dovoljuje lokalni vir. Ti trije se morajo ujemati, preden je poslušalec v gostu sploh pomemben.

Nato preverite gosta: ali storitev posluša na notranjem naslovu in ali gre njena povratna pot znova skozi VPC? Poslušalec, vezan samo na javni naslov, bo na tem preizkusu padel tudi takrat, ko je vsak objekt na strani oblaka pravilen.

Javna predpona je drugo vprašanje

Nič od navedenega ne pomeni, da mora biti vsak naslov, ki se prenaša znotraj VPN, RFC1918. Oddaljeno omrežje je mogoče zakonito oštevilčiti iz javnega prostora, če platforma podpira usmerjanje in ima operater pooblastilo za naslov. To je običajna zasnova.

To ni isto kot obravnavati običajen zunanji naslov NAT, kot da bi bil še en notranji naslov podomrežja. Eno je predpona, ki jo usmerjate; drugo je preslikava, ki jo platforma uporabi za dohodni dostop.

Zunanji IPv6 in posebej zasnovane razporeditve naslovov imajo svojo semantiko. Če je vaš načrt odvisen od katere od njih, preberite dokumentacijo platforme za to funkcijo, namesto da bi posploševali iz primera IPv4. Preslikava IPv4 je običajen primer, ne edini, in vsaka izjema ima svoja pravila.

Prekrivajoči se obsegi so druga težava

Prekrivajoči se zasebni obsegi so resničen razlog, da ljudje posežejo po javnem naslovu, in to je napačna ročica. Sprememba cilja na naslov NAT VM ne reši prekrivanja; spremeni, za kateri naslov paket trdi, da je, ne da bi določila, kako deluje povratna pot.

Prekrivanje rešite namerno: preštevilčite, uporabite podprto zasnovo prevajanja ali usmerite skozi omrežje, kjer se predpone ne trčijo. Vsaka od teh je zasnova z lastnikom. Naslov NAT ni zasnova.

Dokumentirajte obe polji ločeno

Zabeležite partnerja tunela in cilj delovne obremenitve kot dve ločeni polji v runbooku, vsako s potjo in pravilom požarnega zidu, ki ju podpirata. Tunel IPsec, ki se dvigne, vam pove le, da so se strani dogovorile; ne pove ničesar o tem, na katerem naslovu je delovna obremenitev dosegljiva, niti o tem, ali je njena zasebna pot popolna.

Preverite s pravim odjemalcem na drugi strani: razrešite ime, potrdite, da vrne notranji naslov, povežite se in preverite povratni promet. Dokumentacija o naslovih IP v Compute Engine je referenca za razlikovanje notranjega in zunanjega, uporabljeno zgoraj.

Sorodni članki