Zakaj Azure Point-to-Site VPN ne spremeni vašega javnega IP

Povežem odjemalca Azure VPN na prenosniku z Windows, odprem stran z odmevom naslova in vidim isti javni naslov, ki ga je dodelil moj domači usmerjevalnik. Medtem se jump box na 10.20.0.4 odziva in ime zasebne končne točke se razreši, zato tunel ni pokvarjen. Prehod point-to-site dela natanko to, kar pravi njegova privzeta konfiguracija: prenaša zasebne predpone in vse ostalo pusti na lokalni povezavi. Pridobitev izhodnega naslova v lasti Azure je sprememba zasnove usmerjanja, ne popravilo.

Kaj prehod oglašuje privzeto

Prehod potiska poti za naslovni prostor navideznega omrežja ter za enakovredna omrežja, kjer je dovoljen tranzit prehoda, in lokalne predpone, naučene prek povezave site-to-site ali BGP. V tem naboru ni 0.0.0.0/0. Vaš operacijski sistem ohrani privzeto pot na Wi-Fi ali Ethernetu, zato paket do javnega API nikoli ne vstopi v tunel.

Naslov, ki ga odjemalec prejme v tunelu, je zasebni najem iz bazena point-to-site. Odjemalca identificira pred viri v VNet; ni naslov, ki bi ga internet lahko videl, in nikoli se ne bo pojavil kot vir odhodne zahteve do API SaaS. Vnos na seznamu dovoljenih, zgrajen okoli tega najema, ne more delovati, ne glede na to, kako dolgo čakate, da se pojavi v dnevnikih ponudnika.

Razdeljeni tunel in prisilno tuneliranje drug ob drugem

Samo druga vrstica spremeni naslov, ki ga vidi oddaljena storitev. Vse ostalo v tej tabeli so stroški in operativna površina, ki jih sprejmete, ko je treba izhod pregledati ali prevesti znotraj Azure. Če vas kdo prosi, da spremenite javni IP, prosi za celoten desni stolpec, ne za majhen popravek pri odjemalcu.

Preden karkoli obnovite, velja omeniti vmesno možnost. VM s posrednikom ali prehodom v VNet vam da nadzorovan izvorni naslov za aplikacije, ki jih je mogoče usmeriti nanjo, brez premikanja privzete poti odjemalca. To ohrani običajno brskanje lokalno in še vedno zadovolji partnerja, ki potrebuje le en klic API iz Azure. Spodleti, ko se zahteva resnično nanaša na ves promet, ker vse, kar ignorira nastavitev posrednika, vseeno odide lokalno.

Poskrbite, da bo tunel nosil privzeto pot

Na prehodu navideznega omrežja je podprt način za usmerjanje vsega internetnega prometa odjemalca v tunel dodajanje poti po meri v konfiguracijo point-to-site. Dve polovici pokrijeta ves prostor IPv4 in vsaka je bolj specifična od lokalne privzete poti, zato jih odjemalec raje uporabi, ne da bi karkoli izbrisal:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Ta vrstica je ponazoritvena, ne pa popolna za kopiranje: najprej pridobite objekt prehoda z Get-AzVirtualNetworkGateway in ga vstavite namesto GWOBJ, ter pred izvajanjem potrdite, da SKU in model uvajanja sprejmeta poti po meri. Iste predpone se pojavijo na portalu na strani konfiguracije point-to-site, ki je varnejše mesto za njihovo nastavitev, če prehoda še ne skriptirate.

Sprememba teh predpon razveljavi paket odjemalca. Znova prenesite paket odjemalca VPN in ga znova namestite, ker poti potujejo znotraj profila. Odjemalec, ki se znova poveže s starim profilom, obdrži star nabor poti, in lahko izgubite uro z odpravljanjem napak pri spremembi, ki ga ni nikoli dosegla.

V zaščitenem središču navideznega WAN je enakovredna privzeta pot v tabeli poti središča, povezani s prehodom point-to-site, promet pa prevzame Azure Firewall v središču. Požarni zid prevede povezave proti internetu v svoje javne IP naslove in prav iz tega prevoda izvira novi izhodni naslov. Ko ima požarni zid več javnih IP, se lahko kot vir pojavi katerikoli od njih, zato mora seznam dovoljenih vsebovati vse.

Obe zgornji zasnovi sta IPv4. Dve predponi /1 ne storita nič za IPv6, podpora IPv6 pri point-to-site pa je dovolj ozka, da kombinacijo preizkusite, preden obljubite pariteto.

Preverite pot, nato izhod

Ko paket znova namestite in se znova povežete, potrdite, da je odjemalec res namestil polovici. V sistemu Windows bi morala Get-NetRoute -DestinationPrefix 0.0.0.0/1 in enaka poizvedba za 128.0.0.0/1 navesti vmesnik tunela, route print pa pokaže oba ob vaši izvirni privzeti poti. V sistemu Linux mora ip route show navesti obe predponi; če ju ne, ju profil ni nikoli prenesel.

Nato znova preverite javni naslov z odjemalca in preberite dnevnik požarnega zidu za isto povezavo. Vir bi moral biti javni IP požarnega zidu s prevedenim vratom. Odjemalec, ki še vedno odhaja lokalno, čeprav obstajata obe poti, pomeni, da so paketi dosegli Azure in odšli po drugi poti: s potjo, ki jo določi uporabnik, v podomrežju prehoda, s požarnim zidom, ki je sam prisilno tuneliran v lokalno omrežje, ali s pravilnikom, ki tok zavrže pred prevodom.

Znova preizkusite en zasebni cilj v isti seji. Skakalni gostitelj, ki po spremembi preneha odgovarjati, je običajen znak, da so nove predpone nekaj izrinile, bodisi ožjo lokalno pot, ki se je prej oglaševala, bodisi razreševanje imen, ki zdaj gre k razreševalniku brez posredovalnika za vaše zasebne cone.

Kdaj pustiti razdeljeni tunel pri miru

Če je cilj le doseči zasebni API, zasebno končno točko ali interno skrbniško stran, je privzeto vedenje cenejše in tišje. Prisilno tuneliranje doda ure požarnega zidu in stroške obdelave podatkov, daljšo pot in še eno mesto, kjer lahko vsak tok odjemalca spodleti. Zajame tudi veliko več prometa kot edini cilj, ki vas je skrbel.

Segajte po njem, ko je zahteva izražena z vidika izhoda: partner mora videti fiksni naslov Azure, varnost želi, da so povezave zabeležene in pregledane, ali podatki morajo oditi skozi eno nadzorovano točko. Tudi takrat zasnova vsakemu uporabniku da skupni izhod, zato mora odgovornost na uporabnika izhajati iz identitete v aplikaciji, ne iz izvornega naslova.

Preden spremembo zaprete, potrdite štiri stvari: nameščeni paket odjemalca je nov, obe poti /1 sta na vmesniku tunela, zasebni cilj se še odziva in dnevnik oddaljene storitve kaže naslov požarnega zidu.