Pse VPN point-to-site i Azure nuk e ndryshon IP-në tënde publike
Një tunel point-to-site transporton vetëm rrugët e rrjetit virtual, kështu që IP-ja tënde publike mbetet lokale derisa tunelimi i detyruar dhe SNAT-i i firewall-it ta zhvendosin daljen në Azure.
Lidh klientin Azure VPN në një laptop Windows, hap një faqe jehone adrese dhe shoh të njëjtën adresë publike që dha router-i i shtëpisë. Ndërkohë jump box-i në 10.20.0.4 përgjigjet dhe një emër pike fundore private zgjidhet, pra tuneli nuk është prishur. Një gateway point-to-site bën pikërisht atë që thotë konfigurimi i tij i parazgjedhur: transporton prefikset private dhe lë gjithçka tjetër në lidhjen lokale. Marrja e një adrese dalëse në pronësi të Azure është një ndryshim i projektimit të rrugëtimit, jo një riparim.
Çfarë njofton gateway-i si parazgjedhje
Gateway-i shtyn rrugë për hapësirën e adresave të rrjetit virtual, plus rrjetet e bashkërenduara ku lejohet transitimi përmes gateway-it dhe prefikset lokale të mësuara përmes një lidhjeje site-to-site ose BGP. Në atë grup nuk ka 0.0.0.0/0. Sistemi yt operativ mban rrugën e parazgjedhur në Wi-Fi ose Ethernet, kështu që një paketë drejt një API publike nuk hyn kurrë në tunel.
Adresa që një klient merr brenda tunelit është një qira private nga grupi point-to-site. Ajo identifikon klientin përballë burimeve në VNet; nuk është adresë që interneti mund ta shohë dhe nuk do të shfaqet kurrë si burim i një kërkese dalëse drejt një API SaaS. Një zë në listën e lejuar i ndërtuar rreth asaj qiraje nuk mund të funksionojë, sado gjatë të presësh që të shfaqet në regjistrat e furnizuesit.
Tunel i ndarë dhe tunelim i detyruar krah për krah
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Vetëm rreshti i dytë ndryshon adresën që sheh një shërbim i largët. Gjithçka tjetër në atë tabelë është kosto dhe sipërfaqe operative që pranon kur dalja duhet të inspektohet ose të përkthehet brenda Azure. Nëse dikush të kërkon të ndryshosh IP-në publike, po kërkon të gjithë kolonën e djathtë, jo një rregullim të vogël te klienti.
Ka një mundësi të ndërmjetme që ia vlen të përmendet para se të rindërtosh diçka. Një VM proxy ose gateway brenda VNet ju jep një adresë burimi të kontrolluar për aplikacionet që mund të drejtohen drejt saj, pa lëvizur rrugën e parazgjedhur të klientit. Kjo e mban shfletimin normal lokal dhe ende kënaq një partner që ka nevojë vetëm për një thirrje API nga Azure. Dështon kur kërkesa është vërtet për gjithë trafikun, sepse çdo gjë që injoron cilësimin e proxy-t del gjithsesi lokalisht.
Bëje tunelin të mbajë rrugën e parazgjedhur
Në një gateway rrjeti virtual, mënyra e mbështetur për të drejtuar gjithë trafikun e internetit të klientit në tunel është shtimi i rrugëve të personalizuara në konfigurimin point-to-site. Dy gjysma mbulojnë gjithë hapësirën IPv4, dhe secila është më specifike se rruga e parazgjedhur lokale, kështu që klienti i preferon ato pa fshirë asgjë:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Ai rresht është ilustrues dhe jo i plotë për t'u kopjuar: merr së pari objektin e gateway-it me Get-AzVirtualNetworkGateway dhe zëvendëso GWOBJ me të, dhe konfirmo para ekzekutimit që SKU-ja dhe modeli i vendosjes pranojnë rrugë të personalizuara. Të njëjtat prefikse shfaqen në portal në faqen e konfigurimit point-to-site, që është vendi më i sigurt për t'i vendosur nëse nuk e skripton ende gateway-in.
Ndryshimi i këtyre prefikseve e bën të pavlefshëm paketën e klientit. Shkarko përsëri paketën e klientit VPN dhe riinstaloje, sepse rrugët udhëtojnë brenda profilit. Një klient që rilidhet me profilin e vjetër mban grupin e vjetër të rrugëve, dhe mund të humbësh një orë duke korrigjuar një ndryshim që nuk i arriti kurrë.
Në një hub WAN virtual të sigurt, ekuivalenti është një rrugë e parazgjedhur në tabelën e rrugëve të hub-it të lidhur me gateway-in point-to-site, ndërsa trafikun e merr Azure Firewall në hub. Firewall-i i përkthen lidhjet drejt internetit në adresat e veta IP publike, dhe pikërisht nga ai përkthim vjen adresa e re dalëse. Kur një firewall ka disa IP publike, cilado prej tyre mund të shfaqet si burim, prandaj lista e lejuar duhet t'i përmbajë të gjitha.
Të dy projektimet më sipër janë IPv4. Dy prefikset /1 nuk bëjnë asgjë për IPv6, dhe mbështetja IPv6 point-to-site është mjaft e ngushtë sa duhet ta testosh kombinimin përpara se të premtosh barazi.
Kontrollo rrugën, pastaj daljen
Pasi të riinstalosh paketën dhe të rilidhesh, konfirmo që klienti i instaloi vërtet gjysmat. Në Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 dhe e njëjta pyetje për 128.0.0.0/1 duhet të emërtojnë ndërfaqen e tunelit, dhe route print i shfaq të dyja pranë rrugës tënde të parazgjedhur origjinale. Në Linux, ip route show duhet të listojë dy prefikset; nëse nuk e bën, profili nuk i transportoi kurrë.
Më pas rikontrollo adresën publike nga klienti dhe lexo regjistrin e firewall-it për të njëjtën lidhje. Burimi duhet të jetë IP-ja publike e firewall-it me një port të përkthyer. Një klient që del ende lokalisht ndërkohë që ekzistojnë të dyja rrugët do të thotë që paketat arritën në Azure dhe dolën nga një rrugë tjetër: një rrugë e përcaktuar nga përdoruesi në nënrrjetin e gateway-it, një firewall që vetë është i detyruar në tunel drejt rrjetit lokal, ose një politikë që e hedh rrjedhën para përkthimit.
Ritesto një destinacion privat në të njëjtin sesion. Një host kërcimi që ndalon së përgjigjuri pas ndryshimit është shenja e zakonshme që prefikset e reja kanë zhvendosur diçka, ose një rrugë lokale më të ngushtë që njoftohej më parë, ose zgjidhjen e emrave që tani shkon drejt një zgjidhësi pa përcjellës për zonat e tua private.
Kur ta lësh tunelin e ndarë në paqe
Nëse qëllimi është vetëm të arrish një API private, një pikë fundore private ose një faqe administrimi të brendshme, sjellja e parazgjedhur është më e lirë dhe më e qetë. Tunelimi i detyruar shton orë firewall-i dhe kosto të përpunimit të të dhënave, një rrugë më të gjatë dhe një vend më shumë ku çdo rrjedhë klienti mund të dështojë. Kap gjithashtu shumë më tepër trafik sesa destinacioni i vetëm që të interesonte.
Përdore kur kërkesa shprehet në terma daljeje: një partner duhet të shohë një adresë fikse Azure, siguria do që lidhjet të regjistrohen dhe inspektohen, ose të dhënat duhet të dalin përmes një pike të kontrolluar. Edhe atëherë projektimi i jep çdo përdoruesi një dalje të përbashkët, prandaj përgjegjshmëria për përdorues duhet të vijë nga identiteti në aplikacion, jo nga adresa e burimit.
Përpara se ta mbyllësh ndryshimin, konfirmo katër gjëra: paketa e klientit e instaluar është e reja, dy rrugët /1 ndodhen në ndërfaqen e tunelit, një destinacion privat ende përgjigjet, dhe regjistri i shërbimit të largët tregon adresën e firewall-it.