Azure P2S VPN nedokáže přeložit název privátního koncového bodu

Připojíte tunel point-to-site, pingnete privátní adresu, otevřete aplikaci a místo toho dostanete 403 nebo chybu certifikátu. Oba příznaky ukazují na DNS, ale jsou to různé závady: jeden znamená, že klient přeložil veřejnou adresu, druhý, že přeložil privátní adresu a pak nabídl název, který certifikát nepokrývá. Projděte níže uvedené kontroly popořadě a zastavte se u prvního selhání, protože záznam v hosts nebo odpověď z mezipaměti mohou způsobit, že každá další kontrola projde ze špatného důvodu. Toto pořadí mám v textovém souboru vedle svých profilů VPN, protože oprava nemění nic na tunelu a všechno na tom, co klient ví.

Začněte adresou, kterou klient skutečně dostane

Ptejte se resolveru přímo, místo abyste věřili aplikaci. Ve Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net ukáže, který pohled klient dostal. Veřejná odpověď znamená, že se nic dalšího ke koncovému bodu nedostane; privátní adresa koncového bodu znamená, že DNS je hotové a další kontrolou je samotné připojení.

Privátní koncový bod nepřejmenovává službu. Účet nebo aplikace si zachovává své obvyklé plně kvalifikované jméno a koncový bod mění jen adresu, na kterou se toto jméno překládá pro klienty uvnitř virtuální sítě. Proto se stejný název hostitele překládá privátně z VM v síti a veřejně z notebooku, kterému se privátní pohled nikdy nedal.

Zkontrolujte zónu, její propojení a záznam ještě před tunelem

Musí platit tři podmínky současně: privátní zóna existuje, je propojená s virtuální sítí, do které vstupují brána VPN a klienti do Azure, a obsahuje záznam A pro koncový bod ukazující na privátní adresu. Propojte zónu s nesouvisející sítí a brána bude dál překládat veřejný záznam, zatímco všechno na tunelu vypadá zdravě.

Názvy zón patří službám, ne privátním propojením obecně. App Service obvykle používá privatelink.azurewebsites.net, úložiště a SQL mají vlastní obory názvů a vypůjčení zóny jiné služby vytvoří zónu, která existuje a neodpovídá ničím užitečným.

Dejte klientovi resolver, na který skutečně dosáhne

168.63.129.16 odpovídá z virtuálních počítačů Azure a není DNS serverem pro notebook na druhé straně tunelu point-to-site. Klient potřebuje resolver dostupný přes tunel: příchozí koncový bod Azure DNS Private Resolver, přesměrovač uvnitř virtuální sítě, nebo položky DNS serveru přenesené v profilu klienta VPN, aby se klient ptal virtuální sítě přímo.

Nakonfigurovaný, ale nedostupný resolver se chová přesně jako žádný resolver a příznakem je vypršení časového limitu, ne špatná odpověď, a proto se to mylně čte jako problém brány firewall. Otestujte ho dotazem, který má tunel přenášet, ne veřejným jménem, které by přes lokální spojení prošlo tak jako tak.

Pokud přesměrováváte, místo abyste nastavení tlačili, přesměrujte obor názvů, který privátní zóna vlastní, privatelink.azurewebsites.net, ne celý azurewebsites.net. Podmíněný přesměrovač, který spolkne celý nadřazený suffix, posílá do Azure každé hledání služby, včetně těch, která mají zůstat lokální.

Použijte jméno, pro které byl certifikát vydán

Jakmile je adresa správná, objeví se druhá závada. Úložiště a App Service publikují alias privatelink a tento alias nemusí být jméno v certifikátu. Nahrání přes AzCopy na privatelink.blob.core.windows.net neprošlo validací; stejné nahrání na <account>.blob.core.windows.net/<container> se přeložilo na privátní adresu a prošlo, takže zůstalo na privátní cestě bez obcházení.

Pravidlo platí v prohlížeči i pro App Service: připojujte se jménem hostitele, které certifikát pokrývá, a nechte DNS dodat privátní adresu. Nesahejte po obcházení validace, protože mění chybu v pojmenování na bezpečnostní regresi. Úspěšný ping dokazuje trasu a neříká nic o jménu uvnitř handshake, a proto to zůstávají oddělené kontroly.

Pořadí čtyř kroků, které izoluje každou vrstvu

1. Potvrďte, že klient VPN má adresu z fondu point-to-site a trasu k privátní adrese koncového bodu.
2. Přeložte přesné jméno, které aplikace používá, a porovnejte odpověď s adresou koncového bodu.
3. Otevřete TCP spojení ke koncovému bodu na portu služby a potom přečtěte jméno certifikátu předloženého v tomto spojení.
4. Teprve nyní testujte autorizaci, protože funkční cesta a platný certifikát ještě nedávají přístup ke zdroji.

Odmítnuté spojení při správné adrese ukazuje na skupinu zabezpečení sítě nebo stav připojení privátního koncového bodu, ne na DNS, takže to zkontrolujte, než znovu upravíte nastavení resolveru. Neshoda jména TLS vás vrací ke jménu hostitele v URL a k subjektu certifikátu. Uchovávejte výstup překladu, jméno certifikátu a přesnou URL pohromadě; tyto tři hodnoty vysvětlí většinu těchto případů, aniž byste se dotkli brány.

Použijte VM uvnitř virtuální sítě jako kontrolu. Pokud se jméno tam překládá privátně a z tunelu veřejně, zóna i záznam jsou správné a jediný rozdíl je cesta resolveru klienta, což se potvrdí rychleji než další průchod konfigurací koncového bodu.

Klienti také cachují. Záznam, který před deseti minutami odpověděl veřejně, odpovídá dál i po opravě zóny, takže před novým testem mezipaměť vyprázdněte. Ve Windows ipconfig /flushdns vymaže mezipaměť klienta; pravidla zásad překladu názvů však přetrvávají, rozhodují, který suffix jde na který server, a mohou dál posílat obor názvů resolveru, který jste právě nahradili.

Kam patří záznam v hosts

Přidání adresy koncového bodu do souboru hosts je dobrá diagnostika a špatný design. Dokazuje, že chybějícím dílkem je mapování jména na adresu, a umožní otestovat vše po tomto kroku, ale je neviditelné pro vaše uživatele, rozbije se, když se adresa koncového bodu změní, a skrývá zónu, která by měla odpovídat.

Zbylý testovací záznam je horší než zastaralá mezipaměť, protože podle směru chyby může opravenou cestu ukázat jako rozbitou nebo rozbitou cestu jako opravenou. Odstraňte ho před závěrečným průchodem a překládejte jen produkčním resolverem.

Krátká jména potřebují suffix hledání a plně kvalifikovaná ne, takže nejprve otestujte plně kvalifikované jméno a potom rozhodněte, zda pracovní postup potřebuje suffix protlačený profilem klienta. Microsoft dokumentuje názvy zón a tvary záznamů pro jednotlivé služby ve svých pokynech k DNS privátních koncových bodů; čtěte záznam pro svou službu, místo abyste kopírovali zónu z jiné.