Zašto Azure Point-to-Site VPN ne mijenja vašu javnu IP adresu

Povezujem Azure VPN klijent na Windows prijenosnom računalu, otvaram stranicu odjeka adrese i vidim istu javnu adresu koju je dodijelio moj kućni usmjerivač. U međuvremenu jump box na 10.20.0.4 odgovara i ime privatne krajnje točke se razrješava, pa tunel nije pokvaren. Gateway od točke do lokacije radi točno ono što njegova zadana konfiguracija kaže: prenosi privatne prefikse i sve ostalo ostavlja na lokalnoj vezi. Dobivanje izlazne adrese koju posjeduje Azure je promjena dizajna usmjeravanja, a ne popravak.

Što gateway oglašava po zadanom

Gateway gura rute za adresni prostor virtualne mreže, plus peer mreže gdje je dopušten tranzit kroz gateway i on-premises prefikse naučene preko site-to-site veze ili BGP-a. U tom skupu nema 0.0.0.0/0. Vaš operativni sustav zadržava zadanu rutu na Wi-Fi ili Ethernetu, pa paket prema javnom API-ju nikad ne uđe u tunel.

Adresa koju klijent dobije unutar tunela privatni je zakup iz point-to-site poola. Ona identificira klijenta resursima u VNetu; nije adresa koju internet može vidjeti i nikad se neće pojaviti kao izvor odlaznog zahtjeva prema SaaS API-ju. Unos na allowlisti izgrađen oko tog zakupa ne može funkcionirati, koliko god dugo čekali da se pojavi u logovima dobavljača.

Split tunnel i prisilno tuneliranje jedno uz drugo

Samo drugi red mijenja adresu koju vidi udaljena usluga. Sve ostalo u toj tablici trošak je i operativna površina koju prihvaćate kad se izlaz mora pregledati ili prevesti unutar Azurea. Ako vas netko zamoli da promijenite javnu IP, traži cijeli desni stupac, a ne sitnu prilagodbu klijenta.

Postoji srednja opcija koju valja imenovati prije nego bilo što ponovno izgradite. Proxy ili gateway VM unutar VNeta daje vam kontroliranu izvornu adresu za aplikacije koje se mogu usmjeriti na njega, bez pomicanja zadane rute klijenta. To zadržava normalno pregledavanje lokalnim i još zadovoljava partnera kojem treba samo jedan API poziv iz Azurea. Ne uspijeva kad se zahtjev zapravo odnosi na sav promet, jer sve što ignorira proxy postavku i dalje izlazi lokalno.

Neka tunel nosi zadanu rutu

Na gatewayu virtualne mreže podržan način da sav internetski promet klijenta usmjerite u tunel jest dodavanje prilagođenih ruta u point-to-site konfiguraciju. Dvije polovice pokrivaju cijeli IPv4 prostor i svaka je specifičnija od lokalne zadane rute, pa ih klijent preferira bez brisanja ičega:

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

Ta je linija ilustrativna, a ne spremna za kopiranje: prvo dohvatite objekt gatewaya s Get-AzVirtualNetworkGateway i zamijenite njime GWOBJ, pa prije pokretanja potvrdite da SKU i model implementacije prihvaćaju prilagođene rute. Isti se prefiksi pojavljuju na portalu na stranici point-to-site konfiguracije, što je sigurnije mjesto za njihovo postavljanje ako gateway već ne skriptirate.

Promjena tih prefiksa poništava klijentski paket. Ponovno preuzmite VPN klijentski paket i reinstalirajte ga, jer rute putuju unutar profila. Klijent koji se ponovno poveže sa starim profilom zadržava stari skup ruta i možete izgubiti sat vremena na otklanjanje promjene koja do njega nikad nije stigla.

U zaštićenom virtualnom WAN čvorištu ekvivalent je zadana ruta u tablici ruta čvorišta povezanoj s point-to-site gatewayom, a promet preuzima Azure Firewall u čvorištu. Vatrozid prevodi veze prema internetu u svoje javne IP adrese i upravo iz tog prijevoda dolazi nova izlazna adresa. Kad vatrozid ima nekoliko javnih IP adresa, bilo koja od njih može se pojaviti kao izvor, pa allowlista mora sadržavati sve.

Oba su dizajna gore IPv4. Dva prefiksa /1 ne rade ništa za IPv6, a point-to-site IPv6 podrška toliko je uska da kombinaciju treba testirati prije nego obećate paritet.

Provjerite rutu, zatim izlaz

Nakon ponovne instalacije paketa i ponovnog povezivanja potvrdite da je klijent doista instalirao polovice. Na Windowsu Get-NetRoute -DestinationPrefix 0.0.0.0/1 i isti upit za 128.0.0.0/1 trebaju navesti tunelsko sučelje, a route print prikazuje oba uz vašu izvornu zadanu rutu. Na Linuxu ip route show mora navesti ta dva prefiksa; ako ne, profil ih nikad nije nosio.

Zatim ponovno provjerite javnu adresu s klijenta i pročitajte log vatrozida za istu vezu. Izvor bi trebala biti javna IP adresa vatrozida s prevedenim portom. Klijent koji i dalje izlazi lokalno dok obje rute postoje znači da su paketi stigli u Azure i otišli drugim putem: korisnički definiranom rutom na podmreži gatewaya, vatrozidom koji je i sam prisilno tuneliran prema on-premisesu ili pravilom koje odbacuje tok prije prijevoda.

Ponovno testirajte jedno privatno odredište u istoj sesiji. Jump host koji prestane odgovarati nakon promjene uobičajen je znak da su novi prefiksi nešto potisnuli: ili užu on-premises rutu koja se prije oglašavala, ili razrješavanje imena koje sada ide prema resolveru bez forwardera za vaše privatne zone.

Kada ostaviti split tunnel na miru

Ako je cilj samo doći do privatnog API-ja, privatne krajnje točke ili interne admin stranice, zadano ponašanje je jeftinije i tiše. Prisilno tuneliranje dodaje sate vatrozida i troškove obrade podataka, dulji put i još jedno mjesto gdje svaki klijentski tok može pasti. Ono također hvata mnogo više prometa od jedinog odredišta koje vas je zanimalo.

Posegnite za njim kad je zahtjev izražen u terminima izlaza: partner mora vidjeti fiksnu Azure adresu, sigurnost želi da se veze logiraju i pregledavaju ili podaci moraju izaći kroz jednu kontroliranu točku. Čak i tada dizajn svakom korisniku daje zajednički izlaz, pa odgovornost po korisniku mora doći iz identiteta u aplikaciji, a ne iz izvorne adrese.

Prije nego zatvorite promjenu, potvrdite četiri stvari: instalirani klijentski paket je novi, dvije rute /1 sjede na tunelskom sučelju, privatno odredište još odgovara i log udaljene usluge pokazuje adresu vatrozida.