VPN conectat, dar numele eșuează: unde se rupe de fapt DNS-ul

Tunelul e sus, pictograma verde, iar fiecare filă de browser raportează o eroare de rezolvare a numelor. Trei mecanisme diferite produc această imagine: resolverul poate fi inaccesibil, clientul poate întreba un resolver la care nu vă așteptați, sau doar numele private pot eșua. Separați-le înainte de a schimba ceva în protocolul tunelului, pentru că fiecare se repară într-un alt loc. Ordinea de mai jos începe cu observațiile care despart cele trei.

De ce are nevoie de fapt o interogare

O interogare are nevoie de trei lucruri: o adresă de resolver, o rută către acea adresă și un răspuns care se potrivește cu întrebarea. Fiecare poate eșua singur, iar simptomul vizibil este aceeași pagină care nu se încarcă. De aceea pagina de eroare nu vă spune aproape nimic până nu știți care dintre cele trei s-a rupt.

Clientul își învață resolverul din profilul VPN, din DHCP pe tunel sau din propria configurație, iar care sursă câștigă depinde de platformă. În Windows, ipconfig /all afișează serverele DNS pe fiecare adaptor, așa că vedeți dacă valoarea trimisă a ajuns într-adevăr. O valoare trimisă care nu a ajuns niciodată la sistemul de operare este o eșuare tăcută și obișnuită. Citiți valoarea configurată înainte de a atinge profilul.

Linux și macOS răspund la aceeași întrebare cu comenzi diferite, iar răspunsul merită aceeași lectură: resolvectl status și scutil --dns ambele listează serverele pe interfață. Comparați acea listă cu adresa pe care profilul susține că o trimite. O nepotrivire aici explică tot ce urmează, așa că rezolvați-o înainte de a testa nume.

Testați un nume public și unul privat

Interogați un nume de gazdă public obișnuit și numele de gazdă privat documentat de pe aceeași mașină și notați care server a răspuns la fiecare. Dacă ambele eșuează, resolverul sau ruta lui sunt stricate. Dacă doar numele privat eșuează, resolverul a răspuns, iar întrebarea devine zona sau rutarea. Rulați cele două interogări la mai puțin de un minut una de alta, ca o schimbare de rută să nu poată explica diferența.

Țineți numele interne în afara capturilor publice și a resolverelor publice. Un timeout și un răspuns despre un domeniu inexistent sunt observații diferite: primul spune că nu s-a întors nimic, al doilea că o autoritate a răspuns că numele nu există. Tratarea lor ca o singură eroare vă duce la stratul greșit, iar un avertisment de certificat este din nou un al treilea lucru, nu o eroare DNS.

nslookup afișează atât serverul întrebat, cât și răspunsul primit, și exact aceea este perechea de care aveți nevoie. Rulați-l de două ori în același shell și scrieți adresa care a răspuns lângă fiecare răspuns.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Confirmați că clientul poate ajunge într-adevăr la acel server

Un resolver privat trimis de profil este util doar dacă clientul poate ajunge la el cât timp tunelul este sus. O adresă care pare corectă fără rută produce un timeout, iar starea conectată a tunelului nu spune nimic despre acea rută. Verificarea este o căutare de rută îndreptată spre resolverul însuși, nu spre punctul final al VPN-ului.

Fiecare platformă răspunde la asta într-o singură linie, iar interfața numită în ieșire este întregul răspuns. Dacă indică adaptorul fizic în timp ce resolverul stă în spatele tunelului, profilul nu trimite un prefix care să îl acopere.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Într-un profil cu tunel divizat, resolverul poate sta în afara rutelor trimise, ceea ce este o problemă de profil, nu de server. Comparați adresa resolverului cu prefixele trimise și confirmați că unul dintre ele îl acoperă. Aceeași nepotrivire explică de ce DNS-ul funcționează într-o rețea și eșuează în alta cu un profil identic.

Amintiți-vă că browserele pot ocoli resolverul sistemului

Un browser cu DNS securizat activat poate trimite interogări prin HTTPS către un furnizor ales de el și poate ignora complet resolverul sistemului de operare. Atunci sistemul pare corect în timp ce browserul eșuează, sau invers. Aceasta este o chestiune de politică pentru browser, nu pentru tunel.

Verificați setarea de DNS securizat a browserului și orice politică administrată care o controlează, apoi încercați o a doua aplicație sau un alt browser cu tunelul neschimbat. Dacă doar o aplicație eșuează, corectarea aparține acelei aplicații. O fereastră privată nu este o comparație curată, pentru că poate dezactiva extensiile implicit într-un browser și nu în altul, și nu ocolește niciodată o politică administrată. Folosiți în schimb un al doilea profil de browser sau altă aplicație.

Goliți memoria cache și retestați sarcina reală

După ce corectați o setare, goliți memoria cache locală a resolverului ca un răspuns vechi să nu supraviețuiască corectării. O scurtă revenire urmată de o nouă eșuare înseamnă că cauza este încă acolo, nu că golirea a eșuat. Alegeți linia care corespunde mașinii pe care sunteți, pentru că cele trei cache-uri sunt separate.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Apoi repetați sarcina inițială în locul unei interogări sintetice, pentru că sarcina este ceea ce contează pentru utilizator. Reconectați-vă și o dată, ca retestarea să acopere starea în care utilizatorul va fi de fapt. Referința nslookup a Microsoft este pagina pe care merită să o păstrați pentru argumentele interogării.

Dacă numele eșuează doar după deconectare, clientul nu a restaurat configurația anterioară, ceea ce este o eroare de ciclu de viață de raportat, nu un server DNS de înlocuit. O interogare care funcționează nu este nici un test de scurgere, pentru că țara de ieșire nu vă spune care resolver a răspuns.