DNS privat versus VPN: ce acoperă de fapt fiecare nivel

Telefonul tău are DNS-ul privat setat la un nume de gazdă de furnizor și o aplicație VPN care rulează în același timp. Este rezonabil să presupui că unul dintre ele se ocupă acum de căutările de nume. Niciunul nu o face, în sensul pe care îl sugerează acea frază, iar cel mai rapid mod de a vedea de ce este să urmărești o singură cerere din momentul în care atingi un link.

Aceste două funcții se află în puncte diferite ale aceleiași călătorii. DNS-ul privat criptează întrebarea pe care o pui unui resolver. Un VPN schimbă ruta pe care o ia conexiunea răspunsului.

Așadar parcurge-o în ordine, pe un dispozitiv unde ambele sunt activate, și notează ce mai poate vedea fiecare nivel.

Pasul unu: căutarea părăsește aplicația

Atingi un link. Înainte să se conecteze ceva, aplicația are nevoie de o adresă pentru acel nume de gazdă. Pe Android, ecranul relevant este Setări, Rețea și internet, DNS privat. Alegerea Nume gazdă al furnizorului de DNS privat pune dispozitivul în modul strict: efectuează DNS prin TLS către acel nume de gazdă pe portul 853, iar dacă schimbul criptat eșuează, căutarea eșuează în loc să revină în silențiu la text simplu pe portul 53.

Aceasta este o diferență importantă față de Automat, care folosește criptare oportunistă și va folosi fără ezitare un resolver necriptat atunci când rețeaua intervine. Dacă scopul tău este ca căutările să nu aibă loc niciodată în clar, modul strict cu un nume de gazdă de furnizor este setarea care se potrivește.

Iată primul lucru pe care îl dezvăluie parcursul: căutarea este protejată față de rețeaua locală, iar resolverul află totuși numele. Criptarea acoperă saltul. Operatorul acelui resolver vede cererea pentru că a răspunde la ea este treaba lui.

Pasul doi: conexiunea ia o altă rută

Resolverul returnează o adresă, iar aplicația se conectează la ea. Acest pas nu este afectat de modul în care a fost criptată căutarea. Fără un tunel, conexiunea pleacă de la adresa ta publică obișnuită, iar IP-ul de destinație și strângerea de mână TLS fac de obicei numele de gazdă vizibil pentru rețea oricum, cu sau fără DNS criptat.

Activează VPN-ul și acesta este pasul care se schimbă. Traficul care corespunde politicii de rutare a clientului trece prin tunel, rețeaua locală vede o conexiune către punctul final al VPN-ului, iar site-ul vede de obicei adresa de ieșire. Rezolvarea numelor poate călători și ea în interiorul tunelului, în funcție de ce trimite clientul.

Acea separare este întreaga comparație într-o singură frază. Criptarea DNS răspunde la cine poate citi întrebarea. Un VPN răspunde la unde merge conversația.

Pasul trei: în tunel, DNS devine o chestiune de politică

Acum cele două funcții interacționează, iar browserul este sursa obișnuită de surprize. Un browser cu propria setare de DNS securizat poate trimite căutări către resolverul ales prin HTTPS în loc să întrebe sistemul de operare. Setarea de DNS privat a Androidului nu ajunge la acea decizie.

În Firefox, comutatorul se află la Setări, Confidențialitate și securitate, Activează DNS securizat. În Chrome, la Setări, Confidențialitate și securitate, Folosește DNS securizat. Ambele pot fi setate către un furnizor anume sau lăsate oprite, iar când sunt pornite, configurația DNS a tunelului este ocolită pentru acele căutări, chiar dacă traficul paginii folosește în continuare tunelul.

Dacă VPN-ul împinge propriul resolver și browserul insistă pe al lui, obții o divizare: numele se rezolvă, paginile se încarcă, iar căutările care trebuiau să treacă prin tunel au ieșit direct. O adresă de resolver diferită de punctul final al VPN-ului nu este în sine o dovadă a unei scurgeri, dar o cale de căutare care contrazice intenția declarată merită reparată.

Pasul patru: numele interne sunt locul unde se rupe

Conectează-te la un VPN de serviciu și deschide o gazdă de intranet. Dacă DNS-ul securizat al browserului este pornit și indică un resolver public, acel nume nu există pentru browser. Tunelul este activ, tot restul funcționează, iar un nume de gazdă eșuează cu o eroare care pare că site-ul este picat.

Aceeași defecțiune apare invers pe Android. DNS-ul privat strict cu un furnizor public nu va rezolva numele pe care le știe doar resolverul intern, iar modul strict nu are rezervă. Împărțirea DNS-ului unui telefon între un resolver public criptat și un resolver corporativ nu este o setare; este o chestiune de politică de rutare la care trebuie să răspundă cine administrează VPN-ul.

Verifică asta înainte de a da vina pe tunel: interoghează numele intern, apoi același nume cu DNS-ul securizat al browserului dezactivat. Dacă se rezolvă, problema a fost alegerea resolverului, nu conexiunea.

Ce îți spune parcursul să schimbi

Patru ecrane conțin aproape totul. Privește-le în această ordine și notează ce spune fiecare, pentru că răspunsul este de obicei vizibil în combinație:

1. Setări Android, Rețea și internet, DNS privat: Automat sau un nume de gazdă de furnizor, și care nume de gazdă.
2. Setarea de DNS securizat a browserului: oprită sau fixată pe un resolver anume.
3. Politica DNS a clientului VPN: împinge un resolver și tunelul divizat exclude ceva care încă are nevoie de nume?
4. Un test cu un nume de gazdă intern cu tunelul activ, rulat de două ori, o dată cu DNS-ul browserului pornit și o dată oprit.

Apoi potrivește remedierea la cerință, nu invers. Dacă cerința este ca căutările să iasă criptate și să meargă la un resolver pe care l-ai ales, setează DNS privat strict și fă browserul să fie de acord. Dacă cerința este ca traficul să iasă în altă parte, configurează tunelul și nu mai aștepta ca o setare DNS să îți mute adresa.

Și ține limitele în vedere. Niciuna dintre funcții nu face o destinație ostilă sigură și niciuna nu elimină o identitate cu care te-ai autentificat. Criptarea schimbă cine poate citi întrebarea; tunelul schimbă unde merge conexiunea; nimic din toate acestea nu anonimizează contul.