DNS-ul VPN versus DoH din browser: ce nu poate spune un test de scurgere

Pagina testului de scurgere spune că DNS-ul tău este în regulă, insigna browserului spune sigur, iar wiki-ul intern tot nu se încarcă. Toate trei pot fi adevărate simultan, pentru că adresa unui resolver nu este același lucru cu politica ce l-a ales sau cu drumul pe care l-a parcurs interogarea. Ce numesc oamenii scurgere de DNS este de fapt o singură întrebare: care resolver a primit numele și a fost acea alegere intenționată? Clarificarea cere trei verificări, iar doar ultima implică schimbarea unei setări.

Mitul unu: insigna numește resolverul tău

Un test de scurgere rezolvă un nume de sondă și raportează adresa care a răspuns. Nu raportează politica ce a ales acel resolver, iar când interogarea este înfășurată în DNS prin HTTPS, o cutie intermediară de pe drum nu poate vedea deloc numele. Două mașini foarte diferite produc aceeași insignă liniștitoare: una în care VPN-ul a împins 10.8.0.1 și browserul îl folosește, și una în care browserul a ignorat lista sistemului și a trimis numele prin tunel propriului furnizor criptat.

Distincția contează în momentul în care un nume privat eșuează. În prima configurare resolverul VPN răspunde pentru zona corporativă; în a doua browserul nu l-a întrebat niciodată, așa că numele scurt de host nu se rezolvă și eșecul arată ca un VPN stricat. Verificarea nu este un alt test de scurgere, este o căutare a unui nume pe care doar un resolver îl știe.

Mitul doi: browserul părăsește tunelul

DNS-ul alege o adresă, rutarea poartă conexiunea, iar acestea sunt două straturi separate. O interogare trimisă către un furnizor DoH public este în continuare TCP port 443 către o adresă rutabilă. Dacă tabelul tău de rutare trimite ruta implicită în tunel, și acea interogare trece prin tunel. Marca resolverului nu decide drumul.

Ce schimbă DoH-ul browserului este destinatarul numelor. Este o decizie reală de confidențialitate și o decizie reală de politică, dar nu este o ocolire a rutării. Dacă cerința ta este ca numele să rămână la operatorul VPN, o interogare criptată către altcineva nu îndeplinește această cerință, deși folosește în continuare tunelul pentru conexiunea reală.

Mitul trei: fiecare VPN suprascrie fiecare browser

DNS-ul sigur dintr-un browser are moduri, nu un întrerupător: oprit, un furnizor implicit cu rezervă, un șablon personalizat sau o politică impusă de sistemul de operare ori de organizație. Cazul de rezervă este cel care produce rapoarte intermitente. Când punctul final criptat nu este accesibil, browserul poate reveni la resolverul sistemului, așa că același laptop rezolvă corect un nume privat luni și nu marți.

În același timp, majoritatea clienților VPN setează resolverul sistemului când conexiunea urcă și îl restaurează pe cel anterior când cade. Un browser care ține un resolver criptat personalizat nu observă deloc acea restaurare. De aceea același profil se comportă diferit pe două laptopuri și de aceea resolv.conf pare corect în timp ce browserul întreabă în continuare pe altcineva.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Rulează-le cât timp ești conectat, notează ce domenii revendică fiecare resolver și compară cu ce raportează browserul despre propriul mod. Documentația DoH a Mozilla este o descriere rezonabilă a modului în care ar trebui să funcționeze comportamentul implicit și cel de rezervă al unui browser.

Decizia are trei intrări, nu una

Numele private, încrederea în operator și accesibilitatea decid aranjamentul corect. Numele pe care le știe doar resolverul VPN impun DNS divizat: sufixul privat merge la resolverul împins, iar restul urmează politica pe care ai ales-o pentru numele publice. Încrederea în operator decide dacă numele publice trebuie să meargă și ele la acel resolver sau la un serviciu separat. Accesibilitatea decide dacă resolverul criptat ales este măcar utilizabil în această rețea.

Niciunul dintre aceste rânduri nu este o recomandare universală. Un resolver operat de VPN concentrează observațiile la acel operator; un serviciu separat adaugă încă un destinatar al numelor interogate. Niciun aranjament nu dovedește nimic despre păstrare dacă nu citești politica.

Notează decizia pentru fiecare profil, pentru că aceste setări derivează. Un profil care a împins un resolver luna trecută poate să nu împingă nimic astăzi, iar browserul va păstra bucuros un punct final personalizat vechi care încă răspunde. În notă trebuie să fie adresa resolverului, sufixele pe care le deține și modul browserului, nu marca serviciului.

Testează politica pe care crezi că ai configurat-o

Testează după nume, nu după insignă. Rezolvă un nume public și un nume privat prin resolverul sistemului, apoi repetă în browser cu propria sa setare de DNS sigur în modul pe care intenționezi să îl folosești. Dacă numele privat eșuează doar în browser, ai găsit nepotrivirea de destinatar fără să atingi vreo setare VPN.

Apoi reconectează și verifică restaurarea, pentru că acolo locuiesc erorile de predare: deconectează, confirmă că resolverul anterior a revenit, reconectează, confirmă că cel împins a revenit. În final, testează un browser cu politică gestionată dacă ai unul, pentru că acel mod poate refuza complet modificarea ta și păstra în tăcere resolverul anterior.

Începe cu întrebarea spațiului de nume și vei evita cea mai mare parte din asta. Dacă mașina trebuie să ajungă la nume interne, resolverul criptat al browserului este o decizie doar despre jumătatea publică, iar jumătatea privată rămâne la ce a împins VPN-ul.