Cloud VPN drejt një VM në GCP: përdorni IP-në e brendshme, jo IP-në NAT

Kur një rrjet lokal arrin një VPC përmes Cloud VPN, destinacioni për një shërbim Compute Engine është zakonisht adresa e brendshme e VM-së. Adresa IPv4 e jashtme nuk është një adresë e dytë që mund të zëvendësohet në të njëjtën rrugë private. Pjesa më e madhe e konfuzionit në këtë fushë vjen nga trajtimi i tri adresave me tri detyra si të këmbyeshme, prandaj filloni duke emërtuar cilën përdor një paketë e caktuar.

Tri adresa, tri detyra

Emërtoni të tria përpara se të korrigjoni ndonjë prej tyre, sepse përgjigja ndryshon objektin që do të inspektoni më pas.

E para i përket tunelit. E dyta i përket projektimit të rrugës dhe murit të zjarrit. E treta i përket aksesit hyrës nga interneti dhe hartëzohet, nuk shtohet. Një projektim që funksionon për njërën prej tyre nuk thotë asgjë për dy të tjerat.

Pse adresa e jashtme nuk është një ndërfaqe e dytë

Udhëzuesi i adresimit është autoriteti për mënyrën se si ndryshon arritshmëria e brendshme dhe e jashtme në Compute Engine. Një IPv4 e jashtme e Compute Engine është një hartëzim një-për-një mbi NIC-në e vetme të brendshme të instancës, kështu që mysafiri nuk sheh kurrë një ndërfaqe të dytë ose një adresë të dytë në atë NIC. Ajo që raporton VM-ja nga brenda është ende një adresë e vetme e brendshme parësore.

Kjo është arsyeja pse një klient privat që drejton trafikun përmes tunelit drejt 10.24.1.7 dhe një klient që synon adresën e jashtme të VM-së ndodhen në rrugë të ndryshme. Hapja e një rregulli të murit të zjarrit për adresën publike nuk ndryshon asgjë në rrugën e VPC-së që duhet të mbajë trafikun e tunelit, dhe redaktimi i një rruge në mysafir nuk e lëviz hartëzimin e platformës. Zgjidhni adresën që emërton rruga juaj dhe më pas inspektoni vetëm objektet që e qeverisin atë. Kjo disiplinë heq pjesën më të madhe të hamendjes nga kjo rrugë e zgjidhjes së problemeve.

Ecni rrugën me gcloud

Filloni nga instanca dhe lexoni të dyja adresat nga i njëjti objekt, që të dini për cilën flet dokumentacioni juaj:

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

Më pas konfirmoni rrugëtimin dhe lejen nga të cilat varet vërtet rruga:

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

Lexoni intervalet e shpallura dhe të mësuara të tunelit, rrugën e VPC-së për nënrrjetin e ngarkesës së punës dhe rregullin e murit të zjarrit që lejon burimin lokal. Këto tri duhet të përputhen përpara se një dëgjues në mysafir të jetë edhe i rëndësishëm.

Më pas kontrolloni mysafirin: a dëgjon shërbimi në adresën e brendshme dhe a kalon rruga e tij e kthimit përsëri përmes VPC-së? Një dëgjues i lidhur vetëm me një adresë publike do të dështojë në këtë test edhe kur çdo objekt në anën e resë është i saktë.

Një parashtesë publike është një pyetje tjetër

Asgjë nga sa më sipër nuk do të thotë që çdo adresë e transportuar brenda një VPN duhet të jetë RFC1918. Një rrjet i largët mund të numërohet ligjërisht nga hapësira publike, me kusht që platforma të mbështesë rrugëtimin dhe operatori të ketë autoritetin e adresës. Kjo është një zgjedhje normale projektimi.

Kjo nuk është e njëjtë me trajtimin e një adrese të zakonshme NAT të jashtme sikur të ishte një adresë tjetër e nënrrjetit të brendshëm. Njëra është një parashtesë që ju e drejtoni; tjetra është një hartëzim që platforma e zbaton në aksesin hyrës.

IPv6 e jashtme dhe rregullimet e adresave të projektuara posaçërisht kanë semantikën e tyre. Nëse plani juaj varet nga njëra prej tyre, lexoni dokumentacionin e platformës për atë veçori në vend që të përgjithësoni nga rasti IPv4. Hartëzimi IPv4 është rasti i zakonshëm, jo i vetmi, dhe përjashtimet kanë secila rregullat e veta.

Intervalet e mbivendosura janë një problem tjetër

Intervalet private të mbivendosura janë një arsye e vërtetë pse njerëzit i drejtohen adresës publike, dhe është levë e gabuar. Ndryshimi i destinacionit në adresën NAT të VM-së nuk e zgjidh mbivendosjen; ndryshon për cilën adresë paketa pretendon se është, pa përcaktuar si funksionon rruga e kthimit.

Zgjidheni mbivendosjen qëllimisht: rinumeroni, përdorni një projektim përkthimi të mbështetur ose drejtojeni përmes një rrjeti ku parashtesat nuk përplasen. Secili prej këtyre është një projektim me pronar. Adresa NAT nuk është projektim.

Dokumentoni dy fushat veçmas

Regjistroni homologun e tunelit dhe destinacionin e ngarkesës së punës si dy fusha të veçanta runbook, secila me rrugën dhe rregullin e murit të zjarrit që e mbështet. Një tunel IPsec që ngrihet ju tregon vetëm se palët janë dakord; nuk thotë asgjë për adresën në të cilën ngarkesa e punës është e arritshme, as për atë nëse rruga e tij private është e plotë.

Verifikoni me një klient të vërtetë në anën tjetër: zgjidhni emrin, konfirmoni që kthen adresën e brendshme, lidhuni dhe kontrolloni trafikun e kthimit. Dokumentacioni i adresave IP të Compute Engine është referenca për dallimin midis të brendshmes dhe të jashtmes të përdorur më sipër.