Veřejné DNS funguje, ale to neznamená, že je Active Directory k nalezení

VPN se připojí, prohlížeč otevře veřejný web a notebook se přesto nemůže přihlásit do domény. Obvyklý závěr je, že DNS je v pořádku, protože se názvy překládají. V pořádku není, a důvod je ten, že test v prohlížeči procvičí jen jeden dotaz z řetězce, který klient připojený k doméně potřebuje. Zjišťování domény nejprve žádá záznamy služeb, potom adresy řadičů, které tyto záznamy jmenují, a nakonec trasu k portům, na kterých tyto řadiče naslouchají. Veřejná odpověď nesplňuje ani jeden z těchto kroků.

Mýtus: názvy se překládají, takže DNS je hotové

Když se veřejný web přeloží, říká to jen to, že některý překladač odpověděl na jeden dotaz A nebo AAAA pro název ve veřejné zóně. Active Directory používá stejný protokol pro jinou otázku: kde jsou služby domény a který řadič má tento klient použít. Otázka je vyjádřena záznamy SRV v zóně pojmenované po doméně a rekurzivní veřejný překladač nemá důvod je držet.

Když záznam chybí, překladač vrátí negativní odpověď, což je platná odpověď DNS, a ne výpadek. Klient se pak vrátí k uloženým informacím o řadičích, pokud nějaké má, a právě proto může stolní počítač hodiny vypadat dobře a selhat po restartu nebo změně hesla.

Co klient domény skutečně žádá, v pořadí

Pro doménu jako corp.example je obecný dotaz lokátoru _ldap._tcp.dc._msdcs.corp.example. Odpovědi SRV jmenují kandidáty na řadiče a jejich porty a klient pak potřebuje adresní záznamy pro tato jména hostitelů, než může otevřít spojení. Zjišťování s ohledem na lokalitu přidává dotazy pod subdoménou lokality a odpovědi určují, kteří řadiče jsou upřednostňováni, a ne který je povinný.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Sledujte řetězec v tomto pořadí, ze sítě, kde problém vzniká. Jméno hostitele, které se přeloží na nedostupnou adresu, je chyba směrování, ne chyba DNS. Dostupný řadič, kterému chybí záznamy lokátoru, je chyba DNS, ne chyba směrování. Obě dávají podobné stížnosti uživatelů a zcela odlišné opravy.

Proč veřejný překladač odpovídá a přihlášení přesto selhává

Pokud adaptér předá klientovi veřejný překladač, veřejné názvy fungují a vnitřní jmenný prostor ne. Přidání druhého veřejného překladače nepomůže, protože ani jeden zónu nedrží. Ani obvyklý seznam „nejprve vnitřní, potom veřejný“ se nechová jako pravidlo pro jednotlivé domény: negativní odpověď prvního serveru je legitimní odpověď a klient nezkouší druhý server jen proto, že odpověď byla prázdná.

Oba vnitřní překladače, pokud máte dva, musí držet jmenný prostor AD a být dostupné z aktuální sítě klienta. To je část, kterou návrhy rozděleného tunelu rozbíjejí: VPN může nést podsíť tunelu, zatímco vnitřní překladač sedí na prefixu, který tunel nesměruje, takže dotaz odejde k překladači, který na něj nedokáže odpovědět.

Windows také uplatňuje zásadu překladu názvů, která může směrovat konkrétní jmenné prostory na konkrétní servery, a adresy DNS zobrazené adaptérem nejsou celý příběh. Změna seznamu adaptéru bez změny této zásady může ponechat účinnou konfiguraci nedotčenou, a proto oprava, která vypadá použité, nemá žádný účinek.

Udržujte DNS tunelu a jeho trasy v souladu

Profil VPN, který protlačí překladač, ale ne prefix, který jej obsahuje, vytvoří překladač, který klient nedokáže dosáhnout; profil, který protlačí prefix, ale žádný překladač, nechá klienta ptát se lokálního. Berte dvojici jako jednu konfigurační položku a po každé změně profilu zkontrolujte obojí, protože přeřazené protlačení nebo nová zásada rozděleného tunelu je může oddělit.

Zkontrolujte také, co klient s protlačeným nastavením dělá. Někteří klienti použijí server DNS jen na rozhraní tunelu a překladač fyzického adaptéru nechají na místě, takže o vítězi rozhoduje metrika rozhraní a dotazovaný název. Pokud vnitřní odpověď dorazí jen při vypnutém fyzickém adaptéru, je to mechanismus k opravě, ne záznamy domény.

Přijímejte s voláním zjišťování a jednou živou operací

Užitečný přijímací test spustí dotaz lokátoru a potom provede jednu skutečnou ověřenou operaci, například otevře sdílený prostředek založený na adresáři nebo vyžádá lístek. Udělejte to před přechodem na VPN a znovu po něm, na stejném počítači, bez restartu mezi tím. Uložené přihlašovací údaje a již otevřené relace rády udělají z rozbité cesty zdravou, takže úspěšné přihlášení na plochu není test.

Doporučení Microsoftu pro klienta DNS vedou stejnou hranici mezi překladem vnitřního jmenného prostoru a předáváním veřejných dotazů dál, a to je uspořádání, které je třeba zachovat při zavádění VPN.

Pokud je selhání jen pomalé, a ne neúspěšné, držte zpoždění odděleně od diagnózy. Časový limit během zjišťování může pocházet z nedostupného řadiče, blokovaného portu nebo překladače, který odpovídá pozdě, a nic z toho samo čekání neprokazuje. Zaznamenejte skutečný dotaz, jeho odpověď a pokus o spojení, než změníte nastavení překladače.