Azure P2S VPN nedokáže preložiť názov súkromného koncového bodu

Pripojíte tunel point-to-site, pingnete súkromnú adresu, otvoríte aplikáciu a namiesto toho dostanete 403 alebo chybu certifikátu. Oba príznaky ukazujú na DNS, ale sú to rôzne poruchy: jeden znamená, že klient preložil verejnú adresu, druhý, že preložil súkromnú adresu a potom ponúkol názov, ktorý certifikát nepokrýva. Prejdite nižšie uvedené kontroly po poradí a zastavte sa pri prvom zlyhaní, pretože záznam v hosts alebo odpoveď z vyrovnávacej pamäte môžu spôsobiť, že každá ďalšia kontrola prejde zo nesprávneho dôvodu. Toto poradie mám v textovom súbore vedľa svojich profilov VPN, pretože oprava nemení nič na tuneli a všetko na tom, čo klient vie.

Začnite adresou, ktorú klient skutočne dostane

Pýtajte sa resolvera priamo, namiesto toho, aby ste dôverovali aplikácii. V Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net ukáže, ktorý pohľad klient dostal. Verejná odpoveď znamená, že nič ďalej sa ku koncovému bodu nedostane; súkromná adresa koncového bodu znamená, že DNS je hotový a ďalšou kontrolou je samotné pripojenie.

Súkromný koncový bod nepreimenúva službu. Konto alebo aplikácia si zachováva svoje obvyklé plne kvalifikované meno a koncový bod mení len adresu, na ktorú sa toto meno prekladá pre klientov vo virtuálnej sieti. Preto sa rovnaký názov hostiteľa prekladá súkromne z VM v sieti a verejne z notebooku, ktorému sa nikdy nedal súkromný pohľad.

Skontrolujte zónu, jej prepojenie a záznam ešte pred tunelom

Musia platiť tri podmienky súčasne: súkromná zóna existuje, je prepojená s virtuálnou sieťou, do ktorej vstupujú brána VPN a klienti do Azure, a obsahuje záznam A pre koncový bod ukazujúci na súkromnú adresu. Prepojte zónu s nesúvisiacou sieťou a brána bude ďalej prekladať verejný záznam, zatiaľ čo všetko na tuneli bude vyzerať zdravo.

Názvy zón patria službám, nie súkromným prepojeniam všeobecne. App Service zvyčajne používa privatelink.azurewebsites.net, úložisko a SQL majú vlastné priestory názvov a požičanie zóny inej služby vytvorí zónu, ktorá existuje a neodpovedá nič užitočné.

Dajte klientovi resolver, na ktorý skutočne dosiahne

168.63.129.16 odpovedá z virtuálnych počítačov Azure a nie je DNS serverom pre notebook na druhej strane tunela point-to-site. Klient potrebuje resolver dostupný cez tunel: prichádzajúci koncový bod Azure DNS Private Resolver, preposielač vo vnútri virtuálnej siete alebo položky DNS servera prenášané v profile klienta VPN, aby sa klient pýtal virtuálnej siete priamo.

Nakonfigurovaný, ale nedostupný resolver sa správa presne ako žiadny resolver a príznakom je vypršanie času, nie nesprávna odpoveď, preto sa to nesprávne číta ako problém brány firewall. Otestujte ho dopytom, ktorý má tunel prenášať, nie verejným menom, ktoré by cez lokálne spojenie prešlo tak či tak.

Ak preposielate, namiesto toho, aby ste nastavenia tlačili, preposielajte priestor názvov, ktorý vlastní súkromná zóna, privatelink.azurewebsites.net, nie celý azurewebsites.net. Podmienečný preposielač, ktorý prehltne celý nadradený suffix, posiela do Azure každé hľadanie služby, vrátane tých, ktoré majú zostať lokálne.

Použite názov, pre ktorý bol certifikát vydaný

Keď je adresa správna, objaví sa druhá porucha. Úložisko a App Service publikujú alias privatelink a tento alias nemusí byť názov v certifikáte. Nahranie cez AzCopy na privatelink.blob.core.windows.net neprešlo validáciou; to isté nahranie na <account>.blob.core.windows.net/<container> sa preložilo na súkromnú adresu a prešlo, takže zostalo na súkromnej ceste bez obchádzania.

Pravidlo platí v prehliadači aj pre App Service: pripájajte sa názvom hostiteľa, ktorý certifikát pokrýva, a nechajte DNS dodať súkromnú adresu. Nesiahajte po obchádzaní validácie, pretože mení chybu v pomenovaní na bezpečnostnú regresiu. Úspešný ping dokazuje trasu a nehovorí nič o názve vnútri handshake, preto to zostávajú oddelené kontroly.

Poradie štyroch krokov, ktoré izoluje každú vrstvu

1. Potvrďte, že klient VPN má adresu z fondu point-to-site a trasu k súkromnej adrese koncového bodu.
2. Preložte presný názov, ktorý aplikácia používa, a porovnajte odpoveď s adresou koncového bodu.
3. Otvorte TCP spojenie ku koncovému bodu na porte služby a potom prečítajte názov certifikátu predloženého v tomto spojení.
4. Až teraz testujte autorizáciu, pretože funkčná cesta a platný certifikát ešte nedávajú prístup k zdroju.

Odmietnuté spojenie pri správnej adrese ukazuje na skupinu zabezpečenia siete alebo stav pripojenia súkromného koncového bodu, nie na DNS, preto to skontrolujte, než znova upravíte nastavenia resolvera. Nezhoda názvu TLS vás vracia k názvu hostiteľa v URL a k subjektu certifikátu. Uchovávajte výstup prekladu, názov certifikátu a presnú URL spolu; tieto tri hodnoty vysvetlia väčšinu takýchto prípadov bez toho, aby ste sa dotkli brány.

Použite VM vo virtuálnej sieti ako kontrolu. Ak sa názov tam prekladá súkromne a z tunela verejne, zóna aj záznam sú správne a jediný rozdiel je cesta resolvera klienta, čo sa potvrdí rýchlejšie než ďalší priechod konfiguráciou koncového bodu.

Klienti tiež cachujú. Záznam, ktorý pred desiatimi minútami odpovedal verejne, odpovedá ďalej aj po oprave zóny, preto pred novým testom vyprázdnite vyrovnávaciu pamäť. V Windows ipconfig /flushdns vymaže vyrovnávaciu pamäť klienta; pravidlá zásad prekladu názvov však pretrvávajú, rozhodujú, ktorý suffix ide na ktorý server, a môžu ďalej posielať priestor názvov resolveru, ktorý ste práve nahradili.

Kam patrí záznam v hosts

Pridanie adresy koncového bodu do súboru hosts je dobrá diagnostika a zlý dizajn. Dokazuje, že chýbajúcim dielom je mapovanie názvu na adresu, a umožní otestovať všetko po tomto kroku, ale je neviditeľné pre vašich používateľov, rozbije sa, keď sa zmení adresa koncového bodu, a skrýva zónu, ktorá by mala odpovedať.

Zvyšný testovací záznam je horší než zastaraná vyrovnávacia pamäť, pretože podľa smeru chyby môže opravenú cestu ukázať ako rozbitú alebo rozbitú cestu ako opravenú. Odstráňte ho pred záverečným priechodom a prekladajte len produkčným resolverom.

Krátke názvy potrebujú suffix hľadania a plne kvalifikované nie, takže najprv otestujte plne kvalifikovaný názov a potom rozhodnite, či pracovný postup potrebuje suffix pretlačený profilom klienta. Microsoft dokumentuje názvy zón a tvary záznamov pre jednotlivé služby vo svojich pokynoch k DNS súkromných koncových bodov; čítajte záznam pre svoju službu, namiesto toho, aby ste kopírovali zónu z inej.