Cum detectezi o scurgere DNS? 4 pași de verificare a proxy-ului

Concluzia de bază: un test IP reușit înseamnă doar că punctul de ieșire al conexiunii s-a schimbat, nu și că cererile DNS merg pe același traseu. Proxy-ul și DNS-ul gestionează două etape diferite: proxy-ul decide prin ce ieșire de rețea pleacă conexiunea, iar DNS-ul traduce numele de domenii în adrese IP. Dacă cererile de rezolvare urmează un traseu neașteptat, ai de-a face cu o scurgere DNS. Verificarea durează patru pași, iar interpretarea rezultatelor contează mai mult decât rularea testului.

Configurezi proxy-ul, deschizi un site de test IP și pagina afișează IP-ul proxy-ului, așa că tragi concluzia că mediul de rețea este în regulă. Abia după câteva zile, când investighezi probleme cu conturile, descoperi că cererile DNS au mers tot timpul prin rețeaua locală.

Poate problema nu e proxy-ul: DNS-ul n-a trecut niciodată prin el.

De ce să verifici DNS-ul chiar dacă proxy-ul este activ

Proxy-ul și DNS-ul sunt două etape separate; activarea proxy-ului nu înseamnă că DNS-ul este preluat și el. Proxy-ul decide prin ce ieșire de rețea trece conexiunea, iar DNS-ul se ocupă de rezolvarea numelor de domenii. Cele două privesc părți diferite ale rețelei, deci un proxy care funcționează bine nu garantează că cererile DNS merg conform așteptărilor.

La nivelul cererii de rețea: când deschizi un site, clientul fie obține mai întâi, printr-o cerere DNS, adresa IP a domeniului țintă, fie predă domeniul să fie tratat de partea de proxy, în funcție de protocolul proxy, de implementarea clientului și de setările DNS ale browserului. Activarea proxy-ului nu înseamnă automat că toate cererile de rezolvare urmează traseul așteptat; asta se stabilește printr-un test real, nu doar pe baza stării „conectat” afișate de proxy.

Merită lămurită și o graniță: o scurgere DNS nu înseamnă neapărat expunerea adresei IP publice reale. Ceea ce se scurge este traseul cererilor de domenii, care poate arăta furnizorului de rezolvare sau rețelei locale ce domenii ai căutat. Dacă IP-ul real rămâne ascuns, o confirmi printr-un test IP separat. În recomandările sale privind securitatea VPN, Agenția de Cybersecuritate a Singaporei tratează testul scurgerilor DNS și testul expunerii adresei IP ca două verificări independente, tocmai pentru că validează lucruri diferite (vezi ghidul CSA privind securitatea VPN).

Cum apare de obicei o scurgere DNS

Cele mai frecvente sunt trei cauze, și toate țin de configurație, nu de un proxy defect. Pe rând.

Proxy-ul prelucrează doar o parte din trafic

Unele configurații proxy preiau doar cererile web ale browserului, iar rezolvarea rămâne în sarcina sistemului local, în funcție de protocolul proxy și de modul în care acționează clientul. Când cererile web trec prin proxy, dar cererile de rezolvare merg local, în rezultatele testului apare resolverul rețelei locale.

Browserul are activat propriul DNS securizat

Chrome și Firefox suportă DNS over HTTPS (DoH). Când funcția este activă, cererile de rezolvare ajung la serviciul de rezolvare desemnat printr-o conexiune HTTPS criptată, ceea ce reduce șansa rețelei locale de a observa direct interogările. Criptarea nu înseamnă însă că cererile trec prin proxy, nici că serviciul ales corespunde mediului curent. Funcția din Firefox poate fi comutată separat; vezi documentația oficială Mozilla.

Sistemul, browserul și clientul proxy au fiecare al lor

Cea mai greu de observat variantă. Sistemul folosește un resolver, browserul trece prin DoH la altul, iar clientul proxy configurează încă unul; suprapuse, ele fac din traseul de rezolvare o cutie neagră. Din simpla stare „conectat” afișată de programul proxy nu deduci nimic; trebuie să vezi pe ce traseu merge, de fapt, browserul aflat în funcțiune.

Când traseul de rezolvare ajunge la ISP-ul local, cererile trec prin serviciul său de rezolvare; ca termen de comparație poate servi principiul și scenariile de folosire a proxy-ului ISP.

Cum detectezi o scurgere DNS? Patru pași

Testul în sine nu e complicat; esențial este să ai o așteptare înainte de test și o referință de comparație după. Doar după cei patru pași concluzia stă în picioare.

Pasul 1: Notează mai întâi rezultatul așteptat. Înainte de test, scrie clar trei lucruri: în ce regiune se află ieșirea proxy-ului curent, cine ar trebui să preia rezolvarea numelor de domenii și dacă browserul are DoH activat. Fără o așteptare, nici rezultatele nu se pot judeca.

Pasul 2: Rulează testul cu proxy-ul activ. Folosește un site care oferă detectarea scurgerilor DNS, de exemplu dnsleaktest.com, și apasă testul extins (Extended test) pentru ca pagina să afișeze mai mulți resolveri; poți folosi și pagina de test DNS de la BrowserLeaks ca să vezi organizația din spatele resolverilor. Notează numele resolverilor, organizația și regiunea.

Pasul 3: Compară rezultatele cu așteptările. Verifică dacă resolverii din rezultate corespund configurației curente a sistemului, a browserului și a proxy-ului. Dacă resolverii aparțin serviciului DNS așteptat și nu există trasee locale de rezolvare neașteptate, poți considera, în linii mari, că testul este conform așteptărilor. Apare un ISP local sau un serviciu de rezolvare necunoscut? Stabilește mai întâi dacă ține cu adevărat de o configurație neprevăzută, apoi verifică pe rând tratarea DNS în clientul proxy, DNS-ul securizat al browserului și setările de rețea ale sistemului; nu trage imediat concluzia că proxy-ul a căzut. Un test izolat reflectă doar condițiile din momentul respectiv și nu garantează că toate cererile sunt în regulă.

Pasul 4: Schimbă o singură setare și reia testul. Când ajustezi, modifică un singur element pe rând: tratarea DNS din clientul proxy, comutatorul DoH al browserului sau setările de rețea ale sistemului, apoi reia testul și compară. Dacă schimbi mai multe deodată, nu mai afli ce anume a avut efect.

Cum interpretezi rezultatele testului

Aceleași rezultate sunt un indiciu citite corect și un diagnostic greșit citite pe dos. Pentru cele cinci rezultate frecvente, iată cum procedezi:

Capcană Anycast: locația resolverului afișată nu e mereu ieșirea reală.

Ce diferență este între scurgerea DNS, scurgerea WebRTC și amprenta browserului

Cele patru verificări privesc patru tipuri diferite de informații; trecerea uneia nu înseamnă că trec și celelalte. Cel mai clar vezi granițele când le așezi alături:

DNS și WebRTC sunt cele mai ușor de confundat, pentru că ambele poartă cuvântul „scurgere”. Principiul de testare și modul de abordare diferă complet; detectarea și setările scurgerii WebRTC au fost tratate separat, deci nu le reluăm aici. În plus, scurgerea IPv6 este un alt membru al aceleiași familii: verifică dacă adresele IPv6 ocolesc proxy-ul; metoda se află în ghidul de detectare a scurgerilor IPv6.

Cele patru verificări arată lucruri diferite și nu se înlocuiesc între ele. La depanarea unui mediu proxy, recomandăm să confirmi mai întâi IP-ul public, apoi să verifici DNS și WebRTC și, la sfârșit, amprenta și configurația mediului; ce verifici exact depinde de scenariu.

Cum încadrezi aceste verificări în fluxul de lucru cu MostMate

Ordinea recomandată: mai întâi ieșirea, apoi rezolvarea, apoi WebRTC și, la urmă, configurația mediului. Când administrezi mai multe medii de browser cu MostMate, este bine să faci testul de conectivitate proxy și testul scurgerilor DNS separat.

Primul punct este configurația proxy. După legarea proxy-ului la mediu, folosește testul de proxy din produs ca să confirmi starea conexiunii și verifică totodată tipul de protocol (HTTP, HTTPS, SOCKS5, SSH) și datele de autentificare. Atenție: un test de proxy reușit nu înlocuiește testul scurgerilor DNS, pentru că traseul real al cererilor DNS depinde în continuare de configurația clientului proxy, a browserului și a sistemului.

Apoi deschide pagina de test DNS în mediile legate la acel proxy, parcurge din nou cei patru pași de mai sus și vezi dacă apartenența resolverilor corespunde așteptărilor.

Al doilea punct este izolarea mediului în sine. În scenariile cu mai multe conturi, proxy-ul, cookie-urile și parametrii amprentei fiecărui mediu ar trebui să fie independente, fără împrumuturi între ele; amploarea exactă a izolării este descrisă în sfera și configurația izolării mediului de browser. Dacă un mediu are proxy greșit sau împarte configurația, rezultatele testului își pierd valoarea de comparație. Izolarea ajută la gestionarea sesiunilor și configurațiilor, dar nu face traseul DNS automat corect și nu înlocuiește un test extern.

Al treilea punct: nu uita granița. Browserul cu amprentă se ocupă ca mediul să fie bine organizat, dar dacă proxy-ul funcționează și dacă DNS-ul merge pe traseul așteptat se verifică în continuare printr-un test extern. Nici un test reușit nu este valabil pentru totdeauna; după schimbări de configurație sau actualizări de sistem, merită reluat.

Întrebări frecvente

Am proxy activ, dar testul DNS arată un resolver local. Înseamnă că proxy-ul a căzut?

Nu neapărat. E posibil ca proxy-ul să preia doar cererile web, iar rezolvarea să fie tratată separat de sistem sau de browser. Verifică pe rând tratarea DNS din clientul proxy și setările DoH ale browserului, modificând câte un element și testând de fiecare dată.

O scurgere DNS îmi dezvăluie IP-ul real?

Nu se pot echivala direct. O scurgere DNS arată traseul cererilor de rezolvare a numelor de domenii, iar ce se dezvăluie efectiv depinde de configurația rețelei și de scenariul de test. Dacă IP-ul public real rămâne ascuns se confirmă printr-un test IP separat, iar traseul de rezolvare se verifică independent.

Poate apărea o scurgere DNS și când folosesc un browser cu amprentă?

Da, poate. Browserul cu amprentă administrează izolarea mediilor și parametrii amprentei, în timp ce comportamentul DNS depinde de protocolul proxy și de configurația sistemului și a browserului — testul nu poate fi omis.

Ce mai trebuie verificat după un test DNS reușit?

Rămân scurgerea WebRTC și amprenta browserului, fiecare de verificat cu instrumentul potrivit. Doar când trec toate, stratul de rețea al mediului este complet controlat.

Concluzie

Valoarea testului scurgerilor DNS nu constă în obținerea unui verdict „reușit” sau „eșuat”, ci în confirmarea că cererile de rețea ale mediului curent decurg conform așteptărilor. IP-ul public, DNS, WebRTC și amprenta browserului au fiecare metoda lor de verificare, iar rezultatul uneia nu poate înlocui validarea celorlalte. Indiferent de browserul cu amprentă folosit, recomandăm reluarea testului după orice schimbare de proxy sau de configurație de rețea.

Dacă trebuie să administrezi mai multe medii de browser, începe prin a cunoaște configurația mediilor și modul de administrare a proxy-ului din MostMate, apoi validează totul pas cu pas conform articolului; dacă vrei un strat de proxy mai stabil, poți descărca MostMate — versiunea gratuită oferă două medii, deci parcurge mai întâi întregul flux de testare în primul mediu.