Numele interne scurte eșuează pe VPN: sufixul pe care nu îl vezi niciodată
Un nume scurt funcționează doar pentru că un sufix de căutare îl completează. Comparați numele complet și cel scurt pentru a separa lipsa sufixului de o defecțiune a resolverului.
Numele scurt funcționa în birou și eșuează pe VPN, în timp ce numele complet se rezolvă fără probleme. Nimic nu este stricat. Un nume gol precum intranet nu este un nume complet; clientul adaugă un sufix din lista sa de căutare și întreabă despre rezultat. Dacă profilul VPN nu furnizează acel sufix, forma scurtă familiară încetează să existe.
Asta este tot mitul. DNS nu s-a stricat, politica de căutare s-a schimbat.
Un nume gol nu este un nume
Când tastați o singură etichetă, resolverul trebuie să decidă ce să întrebe. Încearcă numele așa cum este dat, apoi adaugă intrări din lista de căutare una câte una până când ceva răspunde. Pe Linux, resolv.conf controlează acea ordine cu setările search și ndots. Pe Windows, lista de sufixe și politica de rezolvare a numelor fac același lucru. Scoateți sufixul și resolverul nu are ce să adauge.
Un nume scurt funcțional este așadar dovada unei politici, nu dovada unui server DNS sănătos.
Ce fac lista de sufixe și adresa resolverului
Acestea două sunt confundate constant. Adresa resolverului spune pe cine să întrebați; lista de sufixe spune despre ce nume să întrebați. Un VPN vă poate da un resolver privat fără sufix, sau un sufix cu resolverul greșit. Doar una dintre aceste defecțiuni arată ca o pană de DNS.
Verificați-le separat, pentru că repararea celei greșite consumă o fereastră de suport.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Trei simptome, trei responsabili diferiți.
Testați mai întâi numele complet
Cereți numele complet calificat documentat de administrator, nu o presupunere. Un FQDN funcțional dovedește că resolverul este accesibil și că înregistrarea există, ceea ce elimină jumătate din cauzele posibile cu o singură interogare. Folosiți un instrument care arată ce server a răspuns, ca să nu citiți un rezultat din cache.
Păstrați testul privat. Trimiterea de variante interne către un resolver public dezvăluie nume și testează o politică pe care nimeni nu a intenționat-o.
Unde se aplică remedierea
Corectați profilul proprietar sau sistemul de management care îl generează. O modificare manuală a configurației locale a resolverului dispare de obicei la reconectare, sau se aplică fiecărei rețele în care intră mașina, ceea ce este mai rău.
Pe Windows, inspectați politica efectivă în loc de căsuța pe care o țineți minte. Get-DnsClientNrptPolicy arată regulile de rezolvare a numelor care sunt cu adevărat în vigoare.
Pe macOS, scutil --dns tipărește configurația resolverului pentru fiecare interfață cu domeniu, inclusiv domeniile de căutare trimise de VPN.
Pe Linux, citiți linia search din /etc/resolv.conf, dar verificați dacă un client VPN a rescris-o. Dacă fișierul este gestionat, editați sursa adevărului în loc de fișierul randat. O linie search veche rămasă de la o rețea anterioară este o cauză obișnuită.
Ce păstrați împreună cu profilul
Păstrați numele complet corectat, lista de sufixe și adresa resolverului lângă profilul clientului. Următoarea persoană care raportează că site-ul intranet este picat poate compara trei valori cunoscute în loc să pornească de la o pagină goală.
Și dacă doar forma scurtă eșuează, spuneți asta în tichet. Acea propoziție economisește o după-amiază echipei de resolvere.