Tunelul divizat exclude browserul, nu interogările lui DNS

O cale directă a datelor nu mută rezolvarea numelor. Verificați ce resolver primește interogarea și dacă aceasta era intenția, înainte de a o numi scurgere.

Browserul exclus din tunel, pagina de IP public confirmă că traficul său iese prin conexiunea de acasă, iar wiki-ul intern tot nu se deschide. Rezolvarea numelor a mers în altă parte, iar acea altă parte este de obicei resolverul configurat de VPN. Calea datelor și calea resolverului sunt decizii separate în majoritatea proiectelor de tunel divizat. Verificați pe care a folosit-o browserul efectiv înainte de a numi excluderea defectă.

Calea datelor și calea resolverului se despart

O excludere scoate pachetele unei aplicații din tunel, ceea ce este o decizie de rutare și firewall pe calea datelor. Rezolvarea numelor este o altă căutare: un proces întreabă resolverul sistemului, iar acel resolver decide ce server primește întrebarea.

Ambele pot fi intenționate și diferite. Un deployment de lucru poate păstra spațiile de nume interne la resolverul corporativ trimițând navigarea publică selectată în afara tunelului, exact pentru că numele interne nu se rezolvă în altă parte. Cazul confuz este invers: un site public eșuează pentru că browserul nu a întrebat niciodată resolverul pe care deploymentul îl aștepta. Notați ruta și resolverul separat, și jumătate din discuții dispar.

Aflați ce proces pune întrebarea

Un browser poate folosi resolverul sistemului, propriul serviciu DNS criptat sau un resolver pe care sistemul de operare îl atribuie pentru fiecare rețea. Primul urmează politica platformei, al doilea ocolește complet acea politică, iar al treilea depinde de legătura către care este rutată interogarea.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Citiți configurația efectivă înainte de testare: ce legături transportă servere DNS, ce spații de nume revendică și dacă o politică pe nume suprascrie valoarea implicită. În Linux, DNS-ul divizat folosește domenii de rutare; în Windows, tabelul de politici de rezolvare a numelor face același lucru pentru spațiile de nume. Niciunul nu este vizibil de pe o pagină de testare a scurgerilor.

Decideți ce resolver vede ce nume

Scrieți maparea dorită înainte de a schimba ceva: nume interne către resolverul corporativ, nume publice către serviciul pe care politica îl permite, și excepții cu un responsabil. Fără acea listă, fiecare etichetă a testului de scurgere devine o dezbatere de politică pe care nimeni nu o poate închide.

Apoi verificați setarea browserului însuși, pentru că DNS-ul criptat din browser se aplică înainte ca sistemul de operare să primească interogarea. Un utilizator care l-a activat pentru a ocoli un portal captiv a suprascris în liniște resolverul ales de deployment. Este o decizie de configurare, nu o scurgere, și merită o decizie, nu o listă de blocare.

Nu rescrieți fiecare câmp DNS pentru ca o etichetă de test să devină verde. Eticheta descrie o interogare a unui proces într-un moment.

Verificați interogarea și conexiunea separat

Testați cele două căi independent. Testul de conexiune arată ruta datelor, iar testul resolverului arată cine a primit numele.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Întrebați resolverul și explicit, astfel încât o eșuare să fie atribuită serverului, nu căii. Apoi reporniți browserul și repetați, pentru că aplicațiile memorează în cache răspunsurile negative și o eșuare veche pare persistentă.

După o modificare aprobată, notați ruta datelor și destinatarul resolverului ca două linii separate cu data. Dacă comportamentul revine la următoarea reconectare, profilul care îl furnizează este cel de corectat, nu browserul.

Articole similare