VPN-ul tău criptează DNS-ul sau doar următorul salt?

Activarea DNS criptat pe serverul VPN este adesea descrisă ca închiderea unei scurgeri, iar acea descriere ascunde care conexiune s-a schimbat. Saltul de la client la resolver și saltul de la resolver la nivelul superior sunt conexiuni separate cu proprietari separați. Criptarea uneia o lasă pe cealaltă exact cum era.

Notează cine primește interogarea la fiecare etapă înainte de a atinge un fișier de configurare.

Două aranjamente arată la fel pe o pagină de setări

În primul aranjament dispozitivul rulează singur DNS over TLS, iar tunelul doar transportă acea conexiune către un resolver pe care l-ai ales. Sesiunea TLS se termină la resolver, ceea ce înseamnă că resolverul vede interogarea, iar ieșirea VPN vede text criptat pe care nu îl poate citi. În al doilea aranjament dispozitivul trimite DNS obișnuit prin tunel către un redirector de pe gazda VPN, iar acel redirector deschide propria conexiune criptată către un resolver superior. Într-o listă de funcții ambele arată ca "DNS criptat cu un VPN", dar plasează interogarea lizibilă în clădiri diferite.

Diferența este măsurabilă, nu filozofică. Caută sesiunea TLS pe client sau pe server și afli ce aranjament ai de fapt.

Cartografiază lanțul de resolveri înainte de a-l schimba

Numără resolverii de pe traseu și numește rolul fiecăruia. O componentă de redirecționare predă o cerere altui resolver, în timp ce un resolver recursiv face munca de a găsi un răspuns și poate vorbi direct cu servere autoritare. Aceste roluri sunt definite separat exact din acest motiv, iar definițiile de resolver din RFC 9076 merită citite înainte de a presupune că există o singură destinație superioară. O gazdă care rulează propriul resolver recursiv nu are un singur "nivel superior" de criptat, ceea ce invalidează întregul plan.

Apoi întreabă ce componentă este configurat clientul să folosească. O adresă DNS furnizată de profilul VPN îți spune unde merg interogările, nu ce proces le răspunde.

Observă și comportamentul la eșec. Dacă nivelul superior criptat devine inaccesibil, redirectorul eșuează închis, revine la text simplu sau trece la alt resolver? Acea decizie trebuie să fie în registru, pentru că schimbă garanția de confidențialitate în momentul în care tunelul este cel mai puțin sănătos.

Verifică ce salt este criptat

Începe pe client și confirmă dacă acesta are o sesiune TLS către portul 853. O interogare care se rezolvă corect prin portul 53 nu dovedește nimic despre criptare.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Apoi treci pe gazda VPN și caută conexiunea criptată de ieșire pe care a deschis-o redirectorul. Tabelul de socketuri îți spune dacă există o sesiune TLS superioară și ce proces o deține:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Dacă clientul arată o sesiune TLS, iar serverul niciuna, ești în primul aranjament și serverul nu poate citi interogările pe care le redirecționează la nivel IP. Dacă serverul arată sesiunea TLS, iar clientul trafic obișnuit pe portul 53 în interiorul tunelului, ești în al doilea aranjament: saltul următor este protejat, iar redirectorul citește în continuare fiecare nume cerut de dispozitiv. Al doilea rezultat nu este o defecțiune, dar a-l numi criptare cap-la-cap este greșit.

Înregistrează proprietarul și comportamentul la eșec

Proprietatea decide ce ai voie să promiți. Proprietarul dispozitivului controlează o conexiune criptată pe partea clientului, în timp ce administratorul VPN controlează conexiunea următoare pe care o creează redirectorul său. Cine nu operează niciuna dintre ele poate doar să descrie traseul.

Înainte de a activa ceva, verifică denumirile interne. Trimiterea numelor organizației către un resolver public nu este un design echivalent, iar o zonă split-horizon care există doar în interiorul rețelei nu va fi rezolvată deloc la nivel superior. Testează un nume intern și unul public după schimbare și păstrează rezultatul împreună cu modificarea de configurare. Dacă traseul criptat rupe rezolvarea pentru gazdele interne, soluția este o regulă de resolver cu scop limitat, nu un tunel mai larg.

Încheie scriind o propoziție pentru fiecare salt: ce componentă a primit interogarea, dacă acel salt a fost criptat și cine poate citi numele. Când propoziția despre gazda VPN spune încă că poate citi interogările, documentația ar trebui să spună același lucru, pentru că o diagramă care susține contrariul va fi crezută de cineva care nu a rulat niciodată comenzile.