A schimbat VPN-ul DNS-ul meu? Comparați înainte și după

Te conectezi la tunel, deschizi un panou privat și numele se rezolvă într-o adresă pe care nu ai mai văzut-o. Sau se întâmplă invers: browserul continuă să funcționeze în timp ce un instrument de linie de comandă nu mai rezolvă brusc nimic. Ambele rezultate provin din aceeași schimbare, iar oamenii o explică de obicei printr-o singură frază despre VPN-ul care „își folosește propriul DNS”, ceea ce nu este suficient de precis pentru depanare sau verificare. În acea frază se ascund două întrebări: ce interogări ar trebui să preia acest profil și dacă mașina ta le-a trimis într-adevăr rezolverului care i-a fost dat. Păstrarea lor separate este întreaga metodă, pentru că un test care le amestecă produce un răspuns greșit și sigur pe sine în ambele direcții.

De ce un profil oferă deloc un rezolver

În interiorul unui tunel, numele din spatele capătului îndepărtat se rezolvă de obicei în adrese care există doar în acea rețea. O zonă privată precum corp.internal nu are delegare publică, așa că rezolverul care o deservește trebuie să fie accesibil din interiorul tunelului. Același mecanism servește unui al doilea scop: când interogările ar ieși altfel prin furnizorul tău, un rezolver din partea îndepărtată ține interogarea în interiorul căii criptate. De aceea adresa serverului DNS vine ca parte a politicii conexiunii și nu ca o setare globală pe care ai ales-o o dată pentru mașină.

Adresa singură nu decide nimic. Un rezolver poate răspunde doar dacă există o rută către el, iar cea mai frecventă defecțiune este un rezolver accesibil doar cât timp tunelul este ridicat. Când tunelul cade și politica rămâne, interogările merg către o adresă fără cale, iar simptomul este un timeout, nu o eroare curată. Această diferență contează când citești următorul rezultat de test, pentru că un timeout trimite oamenii în setări de transport care nu au fost niciodată implicate.

Compară cele două proiecte înainte de a compara răspunsurile

Tunelul complet și DNS-ul divizat produc așteptări opuse și niciunul nu este o defecțiune. Sub un tunel complet, fiecare interogare poate trece la furnizor sau la rezolverul corporativ, așa că un răspuns diferit al numelor publice după conectare este de așteptat. Sub DNS divizat, doar domeniile listate merg la rezolverul privat, iar restul rămâne local; în Windows lista de domenii trăiește în Name Resolution Policy Table, în macOS în domeniile corespunzătoare din setările DNS, iar pe un host systemd-resolved în domeniile de rutare pe legătură.

Aceasta este comparația care trebuie făcută prima, pentru că ea decide ce contează drept defect. Cu DNS divizat, un nume public care răspunde de la un rezolver nou este ceea ce merită investigat, în timp ce un nume intern care răspunde corect este sistemul care își face treaba. Cu un tunel complet, anomalia este un nume public care încă răspunde de la rezolverul furnizorului tău. Documentația Microsoft despre rezolvarea numelor VPN descrie ordinea Windows a acestor reguli, inclusiv modul în care o intrare de politică potrivită este consultată înaintea serverelor proprii ale adaptorului.

Există și un al treilea rezolver în cameră, ușor de uitat. DNS-ul securizat al browserului rezolvă nume pe cont propriu și poate continua să răspundă după ce tunelul a schimbat politica sistemului de operare, așa că o pagină care se încarcă dovedește că rezolverul browserului a funcționat, nu că profilul a fost aplicat. Dacă compari doar ce arată browserul, jumătate din timp testezi stratul greșit.

Înregistrează o linie de bază cu o singură variabilă

Schimbă tunelul. Nu schimba și numele, instrumentul sau sufixul de căutare în același pas. Alege un nume pentru care ai voie să interoghezi, notează ce aplicație ai folosit și scrie fie adresa care a revenit, fie eroarea exactă. În Windows, Get-DnsClientServerAddress -AddressFamily IPv4 afișează serverele pe adaptor, iar Get-DnsClientNrptPolicy afișează intrările de politică; în Linux cu systemd-resolved, resolvectl status arată serverele DNS și domeniile de rutare pe legătură; în macOS, scutil --dns afișează ordinea rezolverelor pe care sistemul o va urma efectiv.

Apoi conectează-te prin controalele obișnuite ale clientului și repetă exact aceleași comenzi. Păstrează prima ieșire în loc de o amintire despre ea, pentru că comparația este tot rostul, iar o a doua citire făcută după golirea cache-ului este deja altă măsurătoare. Dacă linia de bază a fost luată cu browserul în față și rularea de după conectare are loc într-un terminal, compari doi rezolveri, nu două stări ale unui rezolver.

O interogare explicită și o căutare a aplicației sunt teste diferite

A întreba un anumit server, cu nslookup name 10.20.0.1 sau dig @10.20.0.1 name, dovedește un singur lucru: că serverul pe care l-ai numit răspunde când poți ajunge la el. Ocolește complet logica de selecție, deci nu poate spune dacă sistemul ar fi ales acel server pentru acest nume. Folosește-l pentru a verifica dacă rezolverul atribuit este accesibil, și nu îl folosi pentru a verifica politica.

O căutare prin rezolverul local exercită într-adevăr selecția. resolvectl query name parcurge aceleași reguli de domenii de rutare și raportează ce protocol a răspuns, Resolve-DnsName în Windows trece prin tabelul de politică și prin cache-ul clientului, iar scutil --dns arată ordinea pe care ar urma-o o căutare. Rulează ambele tipuri și ține-le în coloane separate ale notițelor tale. O interogare explicită reușită lângă o căutare a aplicației eșuată este o problemă de rutare sau de selecție, nu un rezolver care refuză să funcționeze.

Cache-ul stă între tine și răspuns. Sistemul de operare, rezolverul stub local, browserul și cache-ul negativ păstrează toate rezultate, așa că o căutare poate reuși fără ca un singur pachet să părăsească mașina. Înregistrează rezultatul înainte de a goli orice: ipconfig /flushdns, resolvectl flush-caches sau sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder în macOS. Sari peste resetarea amplă a rețelei în această etapă, pentru că distruge dovezile pe care încă le aduni.

Ce înseamnă diferența

Compară cele două rânduri înregistrate și clasifică schimbarea înainte de a atinge o singură setare.

Un rând merită accentuat. Un nume care se rezolvă nu este un serviciu care funcționează, iar succesul DNS spune doar că s-a găsit o adresă. Nu spune nimic despre redirecționare, regulile de firewall sau dacă contul tău poate folosi serviciul, așa că termină testând aplicația reală în loc să presupui că defecțiunea s-a retras singură.

Restaurează linia de bază și verifică-o

Deconectează-te prin controalele clientului însuși, nu omorând procesul, apoi recitește aceleași trei comenzi. Serverele pe legătură, intrările de politică și răspunsul pentru numele tău de test ar trebui să revină la linia de bază pe care ai scris-o mai devreme. O intrare de politică rămasă după o deconectare curată este un defect real care merită înregistrat, și tot de aceea editările manuale ale unui fișier de rezolver generat sunt un obicei prost: fișierul este rescris și editarea dispare, sau editarea supraviețuiește și fixează un rezolver care nu mai are rută.

Parcurge această listă o dată, în ordine. Decide ce proiect implementează profilul înainte de a judeca orice rezultat. Ține numele, instrumentul și sufixul fixe în ambele rulări. Separă interogarea explicită de căutarea aplicației. Citește politica efectivă, nu doar răspunsul. Golește cache-urile la final, după ce comparația este scrisă. Verifică cu aplicația reală, apoi repornește o dată și confirmă că starea deconectată este încă curată.