Fallback-ul DNS al VPN-ului: unde ajunge de fapt interogarea

O setare a resolverului trece de la adresa privată la una publică, iar concluzia vine imediat: tunelul are scurgeri. Uneori chiar așa este. Adesea interogarea de rezervă a călătorit totuși în interiorul tunelului către un resolver ales de administrator, ceea ce o face o decizie de politică și nu un defect. Separarea acestor cazuri cere trei fapte în loc de unul, iar primul este cine a răspuns. Aflați cine a primit interogarea, ce rută a dus-o și ce nume s-au cerut.

Fallback-ul este o politică, nu un singur comportament

Fiecare client trebuie să decidă ce face când resolverul preferat nu mai răspunde. Poate bloca rezolvarea, reîncerca, folosi o alternativă configurată sau lăsa totul pe seama sistemului de operare, iar din punctul de vedere al confidențialității acestea sunt patru produse diferite. Citirea ecranului de setări vă spune ce comportament este configurat; nu vă spune care s-a produs. Un ecran cu un singur comutator nu descrie patru posibilități.

Browserele adaugă propriul strat. Un browser cu DNS securizat activat poate rezolva un nume prin furnizorul ales de el însuși chiar și atunci când sistemul de operare indică în altă parte, ceea ce înseamnă că politica clientului tunelului poate să nu fie niciodată consultată pentru cererile care vă interesează cu adevărat. Verificați aplicația care a făcut cererea, nu doar setarea de sistem.

Identitatea resolverului de înlocuire este primul fapt care merită stabilit. Un resolver public care aparține unui furnizor în care aveți deja încredere este o situație diferită de o adresă oferită de rețeaua în care vă aflați. Adresa în sine arareori spune la care dintre cele două vă uitați.

Cine primește interogarea după comutare

Destinatarul și ruta sunt independente, iar numai combinația lor descrie expunerea. Un resolver public atins prin tunel nu vede niciodată adresa rețelei dvs. de acces, în timp ce același resolver atins direct o vede. Ambele cazuri produc un răspuns, iar un test de scurgere care raportează doar adresa resolverului le va descrie identic. Cereți interfața alături de adresă când citiți rezultatul.

Numele interne fac distincția concretă. Un resolver public de obicei nu poate răspunde unui nume split-horizon, așa că interogarea eșuează în timp ce numele a fost totuși dezvăluit unei părți care nu avea ce să vadă. Disponibilitatea și confidențialitatea merg deci împreună aici, în loc să se schimbe între ele.

Un tunel poate duce interogarea și la un resolver care nu este operat de furnizorul VPN, pentru că tunelul redirecționează în loc să rezolve. Gazda care redirecționează vede interogarea în text clar și apoi își deschide propria conexiune mai departe, ceea ce protejează următorul salt fără a-l proteja pe primul.

Verificați ruta și destinatarul împreună

Observați pachetele, nu configurația. Întrebați sistemul ce resolver ar fi folosit, apoi confirmați că interogarea a plecat într-adevăr din interfața așteptată către adresa așteptată.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Dacă captura arată interogarea părăsind interfața fizică în timp ce tunelul este activ, fallback-ul a ocolit tunelul indiferent ce spune lista de resolvere. Dacă apare pe interfața tunelului, întrebarea devine cine operează capătul îndepărtat și ce reține.

Repetați verificarea pentru un nume intern și un nume public. Interogarea internă este locul unde o configurație de fallback se dezvăluie de obicei, pentru că un resolver care nu poate răspunde primește totuși întrebarea.

Decideți dacă fallback-ul ar trebui permis

Dacă cerința este ca rezolvarea să se oprească atunci când resolverul preferat nu este disponibil, configurați o politică de aplicare care eșuează închis și acceptați consecința: numele nu se vor rezolva în timpul unei întreruperi. Este un schimb deliberat de disponibilitate, nu o defecțiune, iar proiectarea ar trebui să spună asta înainte ca întreruperea să aibă loc.

Dacă cerința este doar ca interogările să nu călătorească în afara tunelului, un resolver public atins prin tunel poate fi acceptabil cu condiția ca operatorul și politica sa de păstrare să fie înțelese. O astfel de acceptare este o judecată despre o terță parte, nu o afirmație despre criptografie, și aparține celui care deține afirmația de confidențialitate. Dacă numele interne trebuie să funcționeze în continuare, fallback-ul trebuie să fie un resolver care deține zonele interne, ceea ce înseamnă de obicei că ținta de fallback este un alt server, nu o altă familie de adrese.

Documentați rezultatul ca o propoziție despre comportament: ce resolver primește interogările în funcționare normală, care le primește după o defecțiune și dacă numele interne se rezolvă în al doilea caz. Un test de scurgere care în final încarcă o pagină dovedește mai puțin decât acea propoziție, pentru că o pagină se poate încărca printr-un resolver care nu ar fi trebuit consultat niciodată.