Azure point-to-site se připojí, ale žádný privátní prostředek neodpovídá

Připojeno je stav tunelu, ne tvrzení o dosažitelnosti. Klient point-to-site může dokončit IKE, dostat adresu a přesto se nikam nedostat, protože brána přeposílá provoz jen pro sítě, které VNet už zná. Projděte těchto pět kontrol v pořadí a zastavte se u prvního selhání. Přeskakování dopředu je způsob, jak se problém DNS hodinu řeší jako problém firewallu.

Pořadí je důležitější než seznam.

Kontrola 1: rozhodněte, co má tunel přenášet

Azure VPN Gateway ukončuje tunel a přeposílá provoz, který patří do VNetu; neníobecný internetový výstup. Pokud uživatelé čekají, že jejich prohlížení odejde přes Azure, je návrh chybný dřív, než se do hry dostane jakékoli nastavení klienta. Zapněte split tunneling, aby místní internet zůstal na místní cestě, a použijte instanci NAT nebo tunel site-to-site, když je pevná výstupní adresa opravdu nutná.

Než cokoli otestujete, zapište, kam se má klient dostat. Bez takového seznamu vypadá každý dílčí výsledek jako pokrok.

Kontrola 2: porovnejte adresní prostory dřív než certifikáty

Překryv se posuzuje podle širších rozsahů, takže dvě sítě, které na úrovni podsítě vypadají různě, se přesto srazí, pokud se jejich nadřazené bloky překrývají. Podsíť brány musí být vyhrazená a dostatečně velká pro SKU a fond adres klienta se nesmí srazit s VNetem ani s čímkoli dosažitelným přes peering. Změňte plán a znovu nasaďte, protože přidávání tras jako kompenzace vytvoří tunel, který funguje pro některé cíle a nevysvětlitelně ne pro jiné. Zřizování zde selhává nahlas, což je dobrý případ.

Ověřování je další brána. Profily s certifikátem, RADIUS a Entra ID nejsou zaměnitelné a klientský balíček se pro každý liší.

Kontrola 3: přeložte privátní název zevnitř

Klient si drží vlastní resolver, pokud stažený profil nenese DNS servery VNetu, a tento seznam se vkládá při stahování. Přidejte forwarder uvnitř VNetu, nastavte jej jako DNS server VNetu, potom klienta znovu stáhněte a importujte. Opětovné použití starého balíčku testuje jen starý seznam resolverů.

Nejprve otestujte adresu, protože to v jednom kroku oddělí směrování od pojmenování: Test-NetConnection 10.20.1.4 -Port 3389.

Pokud adresa odpovídá a název ne, zeptejte se resolveru přímo pomocí Resolve-DnsName files.corp.example -Server 10.20.0.4. Pokud selže obojí, závada není v DNS a měli byste přestat upravovat nastavení DNS. DNS platformy Azure na 168.63.129.16 odpovídá jen zevnitř VNetu, takže klient mimo něj nemůže tuto adresu použít jako resolver.

Kontrola 4: otestujte službu za tunelem

Zdravý tunel a zavřený port vypadají z pohledu klienta stejně. Zkontrolujte firewall hosta, potom skupinu zabezpečení sítě na podsíti nebo NIC, potom zda služba naslouchá na privátní adrese, a ne jen na loopbacku. Povolte fond klientů jako zdroj, místo abyste otevírali pravidlo do internetu, a pamatujte, že SMB k Azure Files potřebuje cestu privátního koncového bodu vedenou tunelem. Když prostředek odpovídá na IP, ale ne na název, vraťte se ke kontrole 3, místo abyste sahali na bránu.

Jedna tabulka drží vrstvy oddělené, dokud pracujete:

Kontrola 5: zaznamenejte profil před eskalací

Do tiketu dejte typ brány, typ tunelu, metodu ověřování a operační systém klienta. Profil IKEv2 s certifikátem a profil RADIUS selhávají z různých důvodů a klient postavený pro jiný typ tunelu se připojí jen tehdy, když brána nabídne kompatibilní protokol.

Pro malý tým je trvalý návrh jedna VNet, jeden DNS forwarder a zdokumentovaný klient se split tunnelem. Pokud je požadavkem pevný veřejný výstup, ukončete tunel site-to-site na firewallu, který ovládáte, a internetový provoz tam směrujte, místo abyste po bráně point-to-site chtěli něco, pro co nebyla nikdy postavena.