Proč Azure VPN typu point-to-site nemění vaši veřejnou IP adresu

Připojím klienta Azure VPN na notebooku s Windows, otevřu stránku pro ozvěnu adresy a vidím stejnou veřejnou adresu, kterou mi přidělil domácí router. Mezitím jump box na 10.20.0.4 odpovídá a jméno privátního koncového bodu se překládá, takže tunel není rozbitý. Brána point-to-site dělá přesně to, co říká její výchozí konfigurace: přenáší privátní prefixy a všechno ostatní nechává na lokálním spoji. Získat odchozí adresu vlastněnou Azure je změna návrhu směrování, ne oprava.

Co brána ve výchozím stavu inzeruje

Brána posílá trasy pro adresní prostor virtuální sítě, plus partnerské sítě, kde je povolen tranzit brány, a lokální prefixy naučené přes spojení site-to-site nebo BGP. V této sadě není žádná 0.0.0.0/0. Váš operační systém drží výchozí trasu na Wi-Fi nebo Ethernetu, takže paket k veřejnému API do tunelu vůbec nevstoupí.

Adresa, kterou klient v tunelu dostane, je privátní zápůjčka z poolu point-to-site. Identifikuje klienta vůči prostředkům ve VNetu; není to adresa, kterou by internet mohl vidět, a nikdy se neobjeví jako zdroj odchozího požadavku na SaaS API. Záznam v allowlistu postavený kolem této zápůjčky nemůže fungovat, ať čekáte, jak dlouho chcete, než se objeví v logech dodavatele.

Rozdělený tunel a vynucené tunelování vedle sebe

Jen druhý řádek mění adresu, kterou vzdálená služba vidí. Všechno ostatní v té tabulce jsou náklady a provozní plocha, kterou přijímáte, když se odchozí provoz musí kontrolovat nebo překládat uvnitř Azure. Pokud vás někdo požádá, abyste změnili veřejnou IP, žádá celý pravý sloupec, ne drobnou úpravu klienta.

Než cokoli přestavíte, stojí za to pojmenovat prostřední možnost. Proxy nebo bránová VM uvnitř VNetu vám dá řízenou zdrojovou adresu pro aplikace, které na ni lze nasměrovat, aniž byste posunuli výchozí trasu klienta. Běžné prohlížení tak zůstane lokální a partner, kterému stačí jedno volání API z Azure, je stále spokojený. Selže, když se požadavek skutečně týká veškerého provozu, protože cokoli, co nastavení proxy ignoruje, stejně odchází lokálně.

Přinuťte tunel nést výchozí trasu

Na bráně virtuální sítě je podporovaný způsob, jak nasměrovat veškerý internetový provoz klienta do tunelu, přidat vlastní trasy do konfigurace point-to-site. Dvě poloviny pokrývají celý prostor IPv4 a každá je konkrétnější než lokální výchozí trasa, takže je klient upřednostní, aniž by cokoli mazal:

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

Tento řádek je ilustrativní, ne kompletní pro kopírování: nejprve získejte objekt brány pomocí Get-AzVirtualNetworkGateway a dosaďte ho za GWOBJ, a před spuštěním potvrďte, že SKU a model nasazení přijímají vlastní trasy. Stejné prefixy se objevují na portálu na stránce konfigurace point-to-site, což je bezpečnější místo pro jejich nastavení, pokud bránu už nespravujete skriptem.

Změna těchto prefixů zneplatní klientský balíček. Stáhněte balíček klienta VPN znovu a přeinstalujte ho, protože trasy cestují uvnitř profilu. Klient, který se znovu připojí se starým profilem, si ponechá starou sadu tras a můžete ztratit hodinu laděním změny, která se k němu nikdy nedostala.

V zabezpečeném hubu virtuální WAN je ekvivalentem výchozí trasa v tabulce tras hubu přidružené k bráně point-to-site, přičemž provoz přebírá Azure Firewall v hubu. Firewall překládá připojení směřující do internetu na své vlastní veřejné IP adresy a právě z tohoto překladu pochází nová odchozí adresa. Když má firewall několik veřejných IP, jako zdroj se může objevit kterákoli z nich, takže allowlist musí obsahovat všechny.

Oba návrhy výše jsou IPv4. Dva prefixy /1 nedělají pro IPv6 nic a podpora IPv6 u point-to-site je dost úzká na to, abyste kombinaci otestovali, než slíbíte paritu.

Zkontrolujte trasu, pak výstup

Po přeinstalování balíčku a opětovném připojení potvrďte, že klient obě poloviny skutečně nainstaloval. Ve Windows by Get-NetRoute -DestinationPrefix 0.0.0.0/1 a stejný dotaz pro 128.0.0.0/1 měly uvést rozhraní tunelu a route print ukazuje obě vedle vaší původní výchozí trasy. V Linuxu musí ip route show vypsat oba prefixy; pokud ne, profil je nikdy nevezl.

Potom znovu zkontrolujte veřejnou adresu z klienta a přečtěte log firewallu pro stejné spojení. Zdroj by měla být veřejná IP firewallu s přeloženým portem. Klient, který stále odchází lokálně, i když obě trasy existují, znamená, že pakety dorazily do Azure a odešly jinou cestou: uživatelsky definovanou trasou v podsíti brány, firewallem, který je sám vynuceně tunelovaný k místní síti, nebo zásadou, která tok zahodí před překladem.

Znovu otestujte jeden privátní cíl ve stejné relaci. Jump host, který po změně přestane odpovídat, je obvyklým znamením, že nové prefixy něco vytlačily: buď užší místní trasu, která se dřív inzerovala, nebo překlad jmen, který teď jde k resolveru bez forwarderu pro vaše privátní zóny.

Kdy nechat rozdělený tunel být

Pokud je cílem jen dosáhnout privátního API, privátního koncového bodu nebo interní administrační stránky, je výchozí chování levnější a tišší. Vynucené tunelování přidává hodiny firewallu a poplatky za zpracování dat, delší cestu a další místo, kde může selhat každý klientský tok. Zachytí také mnohem víc provozu než jediný cíl, o který vám šlo.

Sáhněte po něm, když je požadavek vyjádřen z hlediska odchozího provozu: partner musí vidět pevnou adresu Azure, bezpečnost chce mít spojení zalogovaná a zkontrolovaná, nebo data musí odcházet jedním řízeným bodem. I tehdy návrh dává každému uživateli sdílený výstup, takže odpovědnost za jednotlivého uživatele musí vycházet z identity v aplikaci, ne ze zdrojové adresy.

Než změnu uzavřete, potvrďte čtyři věci: nainstalovaný klientský balíček je nový, dvě trasy /1 sedí na rozhraní tunelu, privátní cíl stále odpovídá a log vzdálené služby ukazuje adresu firewallu.