Veikiantis viešasis DNS nereiškia, kad Active Directory galima rasti

VPN prisijungia, naršyklė atidaro viešą svetainę, o nešiojamasis kompiuteris vis tiek negali prisijungti prie domeno. Įprasta išvada — DNS tvarkingas, nes vardai išsprendžiami. Jis netvarkingas, o priežastis ta, kad naršyklės testas išbando tik vieną užklausą iš grandinės, kurios reikia prie domeno prijungtam klientui. Domeno aptikimas pirmiausia prašo paslaugų įrašų, paskui valdiklių, kuriuos įvardija tie įrašai, adresų, o galiausiai maršruto į prievadus, kuriuose tie valdikliai klausosi. Viešas atsakymas neužtikrina nė vieno iš šių žingsnių.

Mitas: vardai išsprendžiami, vadinasi, DNS baigtas

Tai, kad vieša svetainė išsprendžiama, sako tik tiek, kad koks nors sprendiklis atsakė į vieną A arba AAAA užklausą dėl vardo viešoje zonoje. Active Directory naudoja tą patį protokolą kitam klausimui: kur yra domeno paslaugos ir kurį valdiklį turi naudoti šis klientas. Klausimas išreiškiamas SRV įrašais zonoje, pavadintoje domeno vardu, o rekursyvus viešas sprendiklis neturi priežasties jų laikyti.

Kai įrašo nėra, sprendiklis grąžina neigiamą atsakymą, kuris yra galiojantis DNS atsakymas, o ne sutrikimas. Tada klientas grįžta prie podėlyje saugomos valdiklių informacijos, jei jos turi, ir būtent todėl stalinis kompiuteris gali valandas atrodyti gerai, o po perkrovimo ar slaptažodžio pakeitimo nepavykti.

Ko domeno klientas iš tikrųjų prašo, iš eilės

Domenui, pavyzdžiui, corp.example, bendra lokatoriaus užklausa yra _ldap._tcp.dc._msdcs.corp.example. SRV atsakymai įvardija kandidatus valdiklius ir jų prievadus, o paskui klientui reikia adresų įrašų tiems pagrindinio kompiuterio vardams, kol jis gali atidaryti ryšį. Vietovę atsižvelgiantis aptikimas prideda užklausas po vietovės subdomenu, o atsakymai nustato, kurie valdikliai yra pageidaujami, o ne kuris yra privalomas.

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

Sekite grandinę šia tvarka, iš tinklo, kuriame problema kyla. Pagrindinio kompiuterio vardas, kuris išsprendžiamas į nepasiekiamą adresą, yra maršrutizavimo gedimas, o ne DNS gedimas. Pasiekiamas valdiklis, kuriam trūksta lokatoriaus įrašų, yra DNS gedimas, o ne maršrutizavimo gedimas. Abu sukelia panašius naudotojų nusiskundimus ir visiškai skirtingus taisymus.

Kodėl viešas sprendiklis atsako, o prisijungimas vis tiek lūžta

Jei adapteris klientui duoda viešą sprendiklį, viešieji vardai veikia, o vidinė vardų erdvė ne. Antro viešo sprendiklio pridėjimas nepadeda, nes nė vienas jų neturi zonos. Įprastas sąrašas „pirmiausia vidinis, paskui viešas“ taip pat nesielgia kaip taisyklė atskiram domenui: pirmojo serverio neigiamas atsakymas yra teisėtas atsakymas, ir klientas nekartoja antrojo serverio vien todėl, kad atsakymas buvo tuščias.

Abu vidiniai sprendikliai, jei juos du naudojate, turi turėti AD vardų erdvę ir būti pasiekiami iš dabartinio kliento tinklo. Būtent tai laužo skaidyto tunelio sprendimai: VPN gali nešti tunelio potinklį, o vidinis sprendiklis yra priešdėlyje, kurio tunelis nemaršrutizuoja, todėl užklausa išeina sprendikliui, kuris negali į ją atsakyti.

Windows taip pat taiko vardų sprendimo politiką, kuri gali nukreipti konkrečias vardų erdves į konkrečius serverius, o adapterio rodomi DNS adresai nėra visa istorija. Pakeitus adapterio sąrašą nepakeitus šios politikos, veiksminga konfigūracija gali likti nepaliesta, ir todėl pataisa, kuri atrodo pritaikyta, neturi jokio poveikio.

Laikykite tunelio DNS ir jo maršrutus suderintus

VPN profilis, kuris stumia sprendiklį, bet ne jį turintį priešdėlį, sukuria sprendiklį, kurio klientas negali pasiekti; profilis, kuris stumia priešdėlį be sprendiklio, palieka klientą klausti vietinio. Traktuokite porą kaip vieną konfigūracijos elementą ir tikrinkite abu po kiekvieno profilio pakeitimo, nes pertvarkytas stūmimas ar nauja skaidyto tunelio politika gali juos atskirti.

Patikrinkite ir tai, ką klientas daro su stumiamu nustatymu. Kai kurie klientai DNS serverį taiko tik tunelio sąsajai ir palieka fizinio adapterio sprendiklį vietoje, todėl kuris laimi, priklauso nuo sąsajos metrikos ir užklausiamo vardo. Jei vidinis atsakymas ateina tik tada, kai fizinis adapteris išjungtas, tai yra taisytinas mechanizmas, o ne domeno įrašai.

Priimkite su aptikimo iškvietimu ir viena gyva operacija

Naudingas priėmimo testas paleidžia lokatoriaus užklausą ir tada atlieka vieną tikrą autentifikuotą operaciją, pavyzdžiui, atidaro katalogu pagrįstą bendrinimą arba paprašo bilieto. Atlikite tai prieš VPN perėjimą ir dar kartą po jo, tame pačiame kompiuteryje, be perkrovimo tarp jų. Podėlyje saugomi prisijungimo duomenys ir jau atidarytos sesijos mielai padarys sugedusį kelią sveiką, todėl sėkmingas darbalaukio prisijungimas nėra testas.

Microsoft DNS kliento rekomendacijos brėžia tą pačią ribą tarp vidinės vardų erdvės sprendimo ir viešų užklausų persiuntimo aukštyn, ir tai yra tvarka, kurią reikia išsaugoti įdiegiant VPN.

Jei gedimas tik lėtas, o ne nepavykęs, laikykite delsą atskirai nuo diagnozės. Aptikimo metu skirtasis laikas gali kilti iš nepasiekiamo valdiklio, užblokuoto prievado ar vėlai atsakančio sprendiklio, ir nė vieno iš jų neįrodo vien laukimas. Užfiksuokite tikrąją užklausą, jos atsakymą ir prisijungimo bandymą prieš keisdami sprendiklio nustatymą.