Prečo Azure Point-to-Site VPN nemení vašu verejnú IP adresu

Pripojím klienta Azure VPN na notebooku s Windows, otvorím stránku s ozvenou adresy a vidím tú istú verejnú adresu, ktorú mi pridelil domáci router. Medzitým jump box na 10.20.0.4 odpovedá a názov súkromného koncového bodu sa prekladá, takže tunel nie je pokazený. Brána point-to-site robí presne to, čo hovorí jej predvolená konfigurácia: prenáša súkromné prefixy a všetko ostatné necháva na lokálnom spoji. Získať odchádzajúcu adresu, ktorú vlastní Azure, je zmena návrhu smerovania, nie oprava.

Čo brána inzeruje predvolene

Brána posiela trasy pre adresný priestor virtuálnej siete, plus partnerské siete, kde je povolený tranzit brány, a lokálne prefixy naučené cez spojenie site-to-site alebo BGP. V tejto množine nie je žiadna 0.0.0.0/0. Váš operačný systém drží predvolenú trasu na Wi-Fi alebo Ethernete, takže paket k verejnému API do tunela vôbec nevstúpi.

Adresa, ktorú klient dostane v tuneli, je súkromná zápožička z fondu point-to-site. Identifikuje klienta voči prostriedkom vo VNet; nie je to adresa, ktorú môže vidieť internet, a nikdy sa neobjaví ako zdroj odchádzajúcej požiadavky na SaaS API. Záznam v zozname povolených postavený okolo tejto zápožičky nemôže fungovať, nech čakáte akokoľvek dlho, kým sa objaví v logoch dodávateľa.

Rozdelený tunel a vynútené tunelovanie vedľa seba

Len druhý riadok mení adresu, ktorú vidí vzdialená služba. Všetko ostatné v tej tabuľke sú náklady a prevádzková plocha, ktoré prijímate, keď sa odchod musí kontrolovať alebo prekladať vnútri Azure. Ak vás niekto požiada, aby ste zmenili verejnú IP, žiada celý pravý stĺpec, nie drobnú úpravu klienta.

Než čokoľvek prestavíte, stojí za to pomenovať strednú možnosť. Proxy alebo bránová VM vo VNet vám dá riadenú zdrojovú adresu pre aplikácie, ktoré na ňu možno nasmerovať, bez posunutia predvolenej trasy klienta. Bežné prehliadanie tak zostane lokálne a partner, ktorý potrebuje len jedno volanie API z Azure, je stále spokojný. Zlyhá, keď sa požiadavka skutočne týka všetkej prevádzky, pretože všetko, čo nastavenie proxy ignoruje, aj tak odchádza lokálne.

Prinúťte tunel niesť predvolenú trasu

Na bráne virtuálnej siete je podporovaný spôsob, ako nasmerovať všetku internetovú prevádzku klienta do tunela, pridať vlastné trasy do konfigurácie point-to-site. Dve polovice pokrývajú celý priestor IPv4 a každá je konkrétnejšia ako lokálna predvolená trasa, takže klient ich uprednostní bez toho, aby čokoľvek mazal:

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

Tento riadok je ilustratívny, nie kompletný na kopírovanie: najprv získajte objekt brány pomocou Get-AzVirtualNetworkGateway a dosaďte ho za GWOBJ, a pred spustením potvrďte, že SKU a model nasadenia prijímajú vlastné trasy. Rovnaké prefixy sa objavujú na portáli na stránke konfigurácie point-to-site, čo je bezpečnejšie miesto na ich nastavenie, ak bránu ešte nespravujete skriptom.

Zmena týchto prefixov zneplatní klientsky balík. Stiahnite balík klienta VPN znova a preinštalujte ho, pretože trasy cestujú vnútri profilu. Klient, ktorý sa znova pripojí so starým profilom, si ponechá starú sadu trás, a môžete stratiť hodinu ladením zmeny, ktorá sa k nemu nikdy nedostala.

V zabezpečenom centre virtuálnej WAN je ekvivalentom predvolená trasa v tabuľke trás centra priradenej k bráne point-to-site, pričom prevádzku preberá Azure Firewall v centre. Firewall prekladá spojenia smerujúce do internetu na svoje vlastné verejné IP adresy a práve z tohto prekladu pochádza nová odchádzajúca adresa. Keď má firewall niekoľko verejných IP, ako zdroj sa môže objaviť ktorákoľvek z nich, takže zoznam povolených musí obsahovať všetky.

Oba návrhy vyššie sú IPv4. Dva prefixy /1 nerobia pre IPv6 nič a podpora IPv6 v point-to-site je dosť úzka na to, aby ste kombináciu otestovali, skôr než sľúbite paritu.

Skontrolujte trasu, potom výstup

Po preinštalovaní balíka a opätovnom pripojení potvrďte, že klient obe polovice skutočne nainštaloval. Vo Windows by Get-NetRoute -DestinationPrefix 0.0.0.0/1 a rovnaký dotaz pre 128.0.0.0/1 mali uviesť rozhranie tunela a route print ukazuje obe vedľa vašej pôvodnej predvolenej trasy. V Linuxe musí ip route show vypísať oba prefixy; ak nie, profil ich nikdy neprevážal.

Potom znova skontrolujte verejnú adresu z klienta a prečítajte log firewallu pre to isté spojenie. Zdrojom by mala byť verejná IP firewallu s preloženým portom. Klient, ktorý stále odchádza lokálne, hoci existujú obe trasy, znamená, že pakety dorazili do Azure a odišli inou cestou: trasou definovanou používateľom v podsieti brány, firewallom, ktorý je sám vynútene tunelovaný k lokálnej sieti, alebo pravidlom, ktoré tok zahodí pred prekladom.

Znovu otestujte jeden súkromný cieľ v tej istej relácii. Jump host, ktorý po zmene prestane odpovedať, je obvyklým znakom, že nové prefixy niečo vytlačili: buď užšiu lokálnu trasu, ktorá sa predtým inzerovala, alebo preklad názvov, ktorý teraz ide k resolveru bez forwardera pre vaše súkromné zóny.

Kedy nechať rozdelený tunel na pokoji

Ak je cieľom len dosiahnuť súkromné API, súkromný koncový bod alebo internú administračnú stránku, predvolené správanie je lacnejšie a tichšie. Vynútené tunelovanie pridáva hodiny firewallu a poplatky za spracovanie dát, dlhšiu cestu a ďalšie miesto, kde každý klientsky tok môže zlyhať. Zachytí aj oveľa viac prevádzky ako jediný cieľ, o ktorý vám išlo.

Chyťte sa ho, keď je požiadavka vyjadrená z hľadiska odchodu: partner musí vidieť pevnú adresu Azure, bezpečnosť chce mať spojenia zalogované a skontrolované, alebo dáta musia odchádzať jedným riadeným bodom. Aj vtedy návrh dáva každému používateľovi zdieľaný výstup, takže zodpovednosť za jednotlivého používateľa musí vychádzať z identity v aplikácii, nie zo zdrojovej adresy.

Pred uzavretím zmeny potvrďte štyri veci: nainštalovaný klientsky balík je nový, dve trasy /1 sedia na rozhraní tunela, súkromný cieľ stále odpovedá a log vzdialenej služby ukazuje adresu firewallu.