De ce nslookup rezolvă prin VPN, dar browserul nu

nslookup trimite o interogare serverului pe care îl numiți și tipărește răspunsul, de aceea poate reuși în timp ce fiecare filă a browserului eșuează. Browserul cere sistemului de operare să rezolve, iar sistemul cântărește resolverele fiecărei interfețe, regulile de politică de rezolvare a numelor și locația de rețea a adaptorului. Apoi browserul poate adăuga propriul DNS criptat deasupra. Trei căi diferite, un simptom, iar tunelul nu este de obicei partea defectă.

Verificările de mai jos urmează aceste căi de la sistem spre exterior. Nu editați profilul VPN până nu știți ce cale a răspuns și care a eșuat.

Trei politici decid răspunsul

Fiecare interfață are propria listă de resolveri și propriile sufixe de căutare. Un adaptor VPN adaugă servere în timp ce adaptorul fizic le păstrează pe ale sale, iar sistemul poate lua pe cel care răspunde primul, așa că o căutare poate fi servită în afara tunelului fără ca cineva să fi ales asta. Regulile tabelului de politică de rezolvare a numelor pot trimite domenii selectate către servere selectate, așa se exprimă de obicei split DNS pe Windows. Iar clientul sau gateway-ul VPN pot împinge o adresă de resolver care există doar în rețeaua privată.

Aceste trei interacționează în moduri care din browser par arbitrare. Un resolver împins la o adresă privată fără rută prin tunelul divizat face fiecare căutare să se blocheze și apoi să eșueze. O regulă de politică ce acoperă sufixul intern și indică un server oprit produce aceeași eroare vizibilă ca o rută lipsă. Un sufix de căutare lipsă de pe adaptorul VPN transformă un nume scurt într-o interogare publică pentru domeniul greșit. Fiecare necesită o reparație diferită.

De ce browserul pune o altă întrebare

nslookup emite propria interogare către serverul pe care îl alege și nu urmează nici politica spațiului de nume, nici setarea de DNS criptat a browserului. De aceea o interogare manuală către un resolver public răspunde în timp ce browserul raportează că site-ul nu există. Comparați două programe, nu două stări ale unui program.

Preferința pentru familia de adrese explică întârzierea, nu eșecul. Un browser care cere mai întâi înregistrări IPv6 pe un tunel ce transportă doar IPv4 așteaptă expirarea timpului limită înainte de a reveni. Firefox a avut o preferință exact pentru asta, iar dezactivarea ei este un pas de diagnostic, nu o reparație.

Citiți lista de resolveri și regulile

Pe Windows, afișați ce deține sistemul înainte de a teoretiza. Get-DnsClientServerAddress arată serverele pe interfață, Get-DnsClientNrptRule enumeră regulile spațiului de nume, iar Resolve-DnsName răspunde numelui exact prin calea sistemului. Comparați acel răspuns cu o interogare directă către serverul VPN după adresă. Când Resolve-DnsName eșuează și interogarea directă reușește, suspectul este lista de resolveri sau o regulă a spațiului de nume.

Verificați și numele în sine. Un nume scurt intern poate avea nevoie de sufixul privat pe care îl oferă doar adaptorul VPN, în timp ce numele complet calificat se rezolvă bine. Un avertisment de certificat după o căutare reușită aparține altei probleme.

Resolverul împins inaccesibil

Gateway-ul sau clientul pot împinge o adresă de resolver, iar acea adresă trebuie să fie accesibilă prin tunel. Pe un tunel divizat, intervalul privat care conține resolverul poate să nu fie între rutele incluse, ceea ce produce o căutare care nu primește niciodată răspuns. Confirmați că ruta există, apoi interogați exact acea adresă, prin tunel. Aceasta este defecțiunea din spatele unei erori de domeniu în browser în timp ce un resolver public încă răspunde.

Dacă resolverul este inaccesibil, reparația este o rută sau o subrețea inclusă, nu alt server DNS.

DNS-ul criptat ocolește întreaga cale

Browserele cu DNS-over-HTTPS rezolvă numele singure printr-o conexiune HTTPS către un furnizor ales. Când aceasta este activă, resolverul sistemului și regulile split DNS sunt ocolite complet pentru acele căutări, așa că numele interne eșuează în browser în timp ce sistemul de operare le rezolvă corect. Se întâmplă și invers: nume interne reușesc în browser printr-un furnizor care nu ar fi trebuit să le vadă niciodată, iar aceasta este o problemă de politică, nu de conectivitate.

Decideți deliberat dacă DNS-ul criptat este permis pe dispozitivele administrate, apoi configurați-l prin suprafața de administrare a browserului ca alegerea să fie vizibilă. Lăsarea la preferința individuală produce o flotă în care același VPN se comportă diferit pe fiecare laptop.

Reparații potrivite defecțiunii

Dacă VPN-ul își împinge resolverul, faceți ca tunelul să transporte trafic către el și ca aceeași setare să fie vizibilă pe adaptoarele care participă la rezolvare. Dacă site-urile locale nu se mai rezolvă în timp ce sunteți conectat, adăugați excepții explicite de spațiu de nume sau un forwarder condiționat în loc să înlocuiți resolverul în întregime. Dacă DNS-ul criptat al browserului ocolește politica, aceea este setarea de schimbat. Nu adăugați niciodată un resolver public pentru a repara un nume intern: scurge interogări private și nu rezolvă numele.

Apoi separați căutarea de conexiune. Un nume care se rezolvă la adresa corectă dar refuză o conexiune este o problemă de serviciu, firewall sau certificat, iar modificările DNS nu o vor repara.

Notați ce cale a răspuns, care a eșuat și ce ați schimbat. Următorul raport despre același simptom va costa atunci o comandă în loc de o după-amiază.