DNS-ul nu se rezolvă când kill switch-ul VPN blochează portul 53
Un kill switch poate bloca DNS-ul intenționat. Comparați rezolvarea doar în tunel cu o excepție pentru un resolver local și apoi stabiliți care strat a eșuat de fapt.
Când kill switch-ul dărâmă tunelul, ia cu el și calea DNS, iar resolverul rămas este rareori cel la care vă așteptați. Două proiecte tratează acel moment foarte diferit: să blocheze fiecare pachet DNS care nu se află în tunel, sau să lase un resolver în picioare ca excepție. Ambele sunt de apărat. Dintr-o filă de browser simptomele arată aproape identic, așa că prima sarcină este să aflați ce proiect ați implementat de fapt.
Țin distincția aceasta în fața ochilor pentru că remedierea este opusă în fiecare caz. Un proiect are nevoie de o excepție mai largă, celălalt de una mai îngustă. Ghicitul vă costă fie confidențialitatea, fie o după-amiază.
Două proiecte DNS pentru aceeași cădere
Proiectul A tratează resolverul ca pe încă un serviciu din spatele tunelului. Regulile de firewall permit UDP și TCP 53 doar pe interfața tunelului, iar adresa dată clientului este un resolver din interiorul tunelului. Când tunelul cade, căutările se opresc, și acesta este rezultatul dorit, nu o defecțiune.
Proiectul B menține un resolver accesibil în rețeaua locală, de obicei routerul la 192.168.1.1 sau stub-ul sistemului de operare la 127.0.0.53, pe raționamentul că rezolvarea numelor nu ar trebui să moară odată cu tunelul. Este comod într-o rețea LAN de acasă, unde routerul rezolvă pentru toată casa. În Wi-Fi-ul unui hotel sau aeroport aceeași excepție indică serverul altcuiva, și fiecare nume pe care îl tastați este dezvăluit, chiar dacă traficul web rămâne blocat.
Limita este cine deține resolverul. Dacă aveți încredere în cel local, o excepție este o gaură mică și onestă. Dacă nu, proiectul doar-prin-tunel este singurul care rezistă, iar prețul este că un tunel căzut ia toate numele cu el.
De ce căutarea clientului VPN însuși încă funcționează
Clientul trebuie să rezolve numele de gazdă al gateway-ului înainte să existe un tunel, așa că o blocare strictă nu trebuie să acopere calea de pornire a clientului. Majoritatea clienților fie memorează în cache adresa punctului final, fie oferă o excepție de pornire documentată pentru acel singur host. Dacă setul de reguli blochează acea căutare, tunelul nu mai revine niciodată și jurnalele arată un client care nu își atinge propriul server, ceea ce este un defect de politică, nu de DNS.
DNS-ul divizat este celălalt loc unde apare acest lucru. Clientul împinge o zonă internă către un resolver privat și lasă tot restul la resolverul de sistem. După o cădere, numele publice se pot rezolva în continuare, în timp ce cele interne expiră, pentru că zona privată nu mai are rută. Pentru utilizator asta este „VPN-ul a stricat internetul”; pentru jurnalul resolverului este o interogare care nu a ajuns niciodată.
Sub systemd-resolved vedeți divizarea direct. resolvectl status listează serverele DNS pe legătură și domeniile de rutare, iar după ce tunelul cade domeniul intern continuă să indice un server pe o legătură care nu mai există. Stub-ul de la 127.0.0.53 acceptă în continuare interogarea, apoi așteaptă un upstream care nu va răspunde, și de aceea eșecul durează secunde în loc să revină imediat.
DNS criptat nu ocolește un filtru de pachete
DNS over HTTPS și DNS over TLS călătoresc pe 443 și 853, deci o regulă care blochează portul 53 nu a spus nimic despre ele. A bloca „DNS” după port este o politică despre un port, nu despre rezolvarea numelor. Dacă kill switch-ul blochează tot traficul din afara tunelului, DoH este acoperit din întâmplare. Dacă ați făcut o excepție pentru un portal captiv sau un resolver public, nu este.
Controalele din partea clientului sunt pârghia mai ieftină. Firefox renunță la resolverul său DoH când numele canar use-application-dns.net nu se rezolvă, și de aceea rețelele administrate publică acel domeniu ca NXDOMAIN; politica de întreprindere îl poate fixa și dezactivat. Android Private DNS și DNS-ul securizat al Chrome au propriile comutatoare și propriile valori implicite. Dezactivarea lor este mai sigură decât să alergi după adrese de resolveri, pentru că lista de adrese se schimbă, iar setul de reguli nu.
Există o versiune a acestui lucru care nu vorbește deloc despre scurgeri. O aplicație cu resolver fixat are totuși nevoie de o cale de rețea ca să ajungă la el. Criptarea schimbă cine poate citi interogarea, nu dacă pachetul poate părăsi mașina, așa că o blocare pentru întregul dispozitiv învinge setarea fără să o atingă.
Potriviți simptomul cu stratul
Majoritatea rapoartelor ajung ca o singură propoziție, iar acea propoziție numește de obicei deja stratul. Tabelul de mai jos este ce parcurg înainte să ating o regulă; scopul este să decid dacă interogarea a fost blocată, direcționată greșit sau niciodată trimisă.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Primele două rânduri sunt cele pe care oamenii le diagnostichează greșit. O cădere silențioasă și un refuz arată amândouă ca „DNS-ul s-a stricat” în browser, dar doar unul dintre ele înseamnă că kill switch-ul își face treaba. Un refuz înseamnă că ceva a răspuns, deci blocarea nu este unde credeți.
Restabiliți politica resolverului, apoi demonstrați-o
Reparați proiectul, nu simptomul. Pentru rezolvarea doar prin tunel, permiteți 53 pe interfața tunelului, împingeți resolverul intern odată cu configurația tunelului și lăsați legătura fizică fără nicio permisiune DNS. La wg-quick, linia DNS = este cea care scrie resolverul în configurația interfeței, așa că un tunel care o omite lasă resolverul vechi pe loc și fiecare interogare pe calea greșită. manualul wg-quick documentează acest comportament pentru fiecare platformă.
Apoi verificați în această ordine. Pe Linux, resolvectl status arată legătura activă, dig +short example.com testează un nume public, dig @10.8.0.1 internal.example.com testează numele privat, și sudo tcpdump -ni any port 53 arată ce interfață folosesc pachetele în timp ce rulați ambele. Pe Windows, Get-DnsClientServerAddress -AddressFamily IPv4 și Resolve-DnsName example.com dau aceleași două fapte: cine este configurat și cine răspunde.
Încheiați cu testul negativ. Deconectați tunelul, confirmați că un nume public nou eșuează, confirmați că numele privat eșuează, și confirmați că niciun pachet pe portul 53 nu a părăsit adaptorul fizic. O blocare care rezistă doar pentru răspunsuri din cache nu rezistă deloc.
Listă de verificare înainte de a închide tichetul:
- Resolverul folosit în timpul căderii este cel pe care îl prevede politica.
- Căutarea propriului punct final de către client este încă permisă, prin cache sau excepție.
- DoH și DoT sunt fie acoperite de blocare, fie dezactivate prin politică.
- Zonele private eșuează închis, nu deschis, de îndată ce tunelul dispare.