Un DNS public care funcționează nu înseamnă că Active Directory poate fi găsit

VPN-ul se conectează, browserul deschide un site public, iar laptopul tot nu se poate autentifica în domeniu. Concluzia obișnuită este că DNS-ul este în regulă pentru că numele se rezolvă. Nu este, iar motivul este că un test în browser exersează o singură interogare dintr-un lanț de care are nevoie un client înscris în domeniu. Descoperirea domeniului cere mai întâi înregistrări de serviciu, apoi adresele controlerelor pe care le numesc acele înregistrări și, în final, o rută către porturile pe care acele controlere ascultă. Un răspuns public nu satisface niciunul dintre acești pași.

Mitul: numele se rezolvă, deci DNS-ul este gata

Faptul că un site public se rezolvă spune doar că un resolver a răspuns la o interogare A sau AAAA pentru un nume dintr-o zonă publică. Active Directory folosește același protocol pentru altă întrebare: unde sunt serviciile domeniului și ce controler ar trebui să folosească acest client. Întrebarea este exprimată ca înregistrări SRV sub o zonă numită după domeniu, iar un resolver public recursiv nu are niciun motiv să le păstreze.

Când înregistrarea lipsește, resolverul returnează un răspuns negativ, care este un răspuns DNS valid și nu o pană. Clientul revine apoi la informațiile despre controlere din cache dacă le are, și exact de aceea un desktop poate arăta bine ore întregi și poate eșua după o repornire sau o schimbare de parolă.

Ce cere de fapt un client de domeniu, în ordine

Pentru un domeniu precum corp.example, interogarea generică de localizare este _ldap._tcp.dc._msdcs.corp.example. Răspunsurile SRV numesc controlere candidate și porturile lor, iar apoi clientul are nevoie de înregistrări de adresă pentru acele nume de gazdă înainte de a deschide o conexiune. Descoperirea conștientă de sit adaugă interogări sub subdomeniul sitului, iar răspunsurile determină ce controlere sunt preferate, nu care este obligatoriu.

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

Urmați lanțul în această ordine, din rețeaua în care apare problema. Un nume de gazdă care se rezolvă la o adresă inaccesibilă este o defecțiune de rutare, nu o defecțiune DNS. Un controler accesibil căruia îi lipsesc înregistrările de localizare este o defecțiune DNS, nu o defecțiune de rutare. Ambele produc reclamații similare ale utilizatorilor și reparații complet diferite.

De ce un resolver public răspunde și totuși autentificarea se rupe

Dacă adaptorul îi dă clientului un resolver public, numele publice funcționează, iar spațiul de nume intern nu. Adăugarea unui al doilea resolver public nu ajută, pentru că niciunul nu deține zona. Nici lista obișnuită „întâi intern, apoi public” nu se comportă ca o regulă pentru fiecare domeniu: un răspuns negativ de la primul server este un răspuns legitim, iar clientul nu reîncearcă al doilea server doar pentru că răspunsul a fost gol.

Ambele resolvere interne, dacă rulați două, trebuie să dețină spațiul de nume AD și să fie accesibile din rețeaua actuală a clientului. Exact aceasta este partea pe care o strică proiectele cu tunel divizat: VPN-ul poate transporta subrețeaua tunelului în timp ce resolverul intern stă pe un prefix pe care tunelul nu îl rutează, așa că interogarea iese către un resolver care nu o poate răspunde.

Windows aplică și o politică de rezolvare a numelor care poate direcționa spații de nume anume către servere anume, iar adresele DNS afișate de adaptor nu sunt toată povestea. Modificarea listei adaptorului fără modificarea acelei politici poate lăsa configurația efectivă neatinsă, și de aceea o corecție care pare aplicată nu are niciun efect.

Țineți DNS-ul tunelului și rutele lui în acord

Un profil VPN care împinge un resolver dar nu prefixul care îl conține creează un resolver pe care clientul nu îl poate atinge; unul care împinge prefixul fără resolver lasă clientul să întrebe resolverul local. Tratați perechea ca un singur element de configurare și verificați-le pe amândouă după fiecare schimbare de profil, pentru că o împingere reordonată sau o politică nouă de tunel divizat le poate separa.

Verificați și ce face clientul cu setarea împinsă. Unele clienți aplică serverul DNS doar interfeței tunelului și lasă resolverul adaptorului fizic pe loc, așa că cine câștigă depinde de metrica interfeței și de numele interogat. Dacă răspunsul intern vine doar când adaptorul fizic este dezactivat, acesta este mecanismul de reparat, nu înregistrările domeniului.

Acceptați cu un apel de descoperire și o operațiune reală

Un test de acceptare util rulează interogarea de localizare și apoi efectuează o operațiune autentificată reală, cum ar fi deschiderea unei partajări bazate pe director sau cererea unui bilet. Faceți-o înainte de tranziția VPN și din nou după, pe aceeași mașină, fără repornire între timp. Acreditările din cache și sesiunile deja deschise vor face bucuros un drum rupt să pară sănătos, așa că o autentificare reușită pe desktop nu este testul.

Recomandările Microsoft pentru clientul DNS trag aceeași linie între rezolvarea spațiului de nume intern și transmiterea interogărilor publice mai sus, iar aceasta este aranjarea care trebuie păstrată când se introduce un VPN.

Dacă defecțiunea este doar lentă și nu eșuată, țineți întârzierea separată de diagnostic. Un timeout în timpul descoperirii poate veni de la un controler inaccesibil, un port blocat sau un resolver care răspunde târziu, și niciuna dintre acestea nu este dovedită doar de așteptare. Înregistrați interogarea reală, răspunsul ei și încercarea de conectare înainte de a schimba o setare a resolverului.