El DNS no resol quan el kill switch de la VPN bloqueja el port 53
El kill switch pot bloquejar el DNS a propòsit. Compareu la resolució només dins del túnel amb una excepció per a un resolutor local i després esbrineu quina capa ha fallat.
Quan el kill switch deixa caure el túnel, s'emporta el camí del DNS, i el resolutor que queda darrere rares vegades és el que espereu. Dos dissenys afronten aquell moment de maneres molt diferents: bloquejar tots els paquets DNS que no vagin dins del túnel, odeixar un resolutor dret com a excepció. Tots dos són defensables. Des d'una pestanya del navegador els símptomes semblen gairebé idèntics, així que la primera feina és esbrinar quin disseny heu desplegat realment.
Tinc aquesta distinció al davant perquè la correcció és oposada en cada cas. Un disseny necessita una excepció més àmplia; l'altre, una de més estreta. Endevinar et costa o la privadesa o una tarda.
Dos dissenys de DNS per a la mateixa avaria
El disseny A tracta el resolutor com un servei més darrere del túnel. Les regles del tallafoc permeten UDP i TCP 53 només a la interfície del túnel, i l'adreça que es lliura al client és un resolutor dins del túnel. Quan el túnel cau, les consultes s'aturen, i aquest és el resultat previst, no una fallada.
El disseny B manté un resolutor accessible a la xarxa local, normalment l'encaminador a 192.168.1.1 o l'stub del sistema operatiu a 127.0.0.53, amb el raonament que la resolució de noms no hauria de morir amb el túnel. És convenient en una LAN domèstica on l'encaminador resol per a tota la casa. En el Wi-Fi d'un hotel o aeroport la mateixa excepció apunta al servidor d'una altra persona, i cada nom que escriviu queda revelat encara que el vostre trànsit web segueixi bloquejat.
La frontera és qui posseeix el resolutor. Si confieu en el local, una excepció és un forat petit i honest. Si no, el disseny només-túnel és l'únic que aguanta, i el preu és que un túnel caigut s'emporta tots els noms.
Per què la consulta del propi client VPN encara funciona
El client ha de resoldre el nom d'amfitrió de la passarel·la abans que existeixi un túnel, així que un bloqueig estricte no ha de cobrir el camí d'arrencada del client. La majoria de clients o bé fan memòria cau de l'adreça del punt final o bé inclouen una excepció d'arrencada documentada per a aquest únic amfitrió. Si el vostre conjunt de regles bloqueja aquesta consulta, el túnel no torna mai i els registres mostren un client que no pot arribar al seu propi servidor, cosa que és un defecte de política i no de DNS.
El DNS dividit és l'altre lloc on això apareix. El client envia una zona interna a un resolutor privat i deixa la resta al resolutor del sistema. Després d'una caiguda, els noms públics poden resoldre's mentre els interns esgoten el temps, perquè la zona privada no té cap ruta. Per a l'usuari això és "la VPN ha trencat internet"; per al registre del resolutor és una consulta que mai va arribar.
Amb systemd-resolved podeu veure la divisió directament.resolvectl statusllista els servidors DNS per enllaç i els dominis d'encaminament, i després que el túnel caigui el domini intern continua apuntant a un servidor en un enllaç que ja no existeix. L'stub a 127.0.0.53 encara accepta la consulta, després espera un servidor superior que no respondrà, i per això la fallada triga segons en lloc de tornar de seguida.
El DNS xifrat no esquiva un filtre de paquets
DNS sobre HTTPS i DNS sobre TLS viatgen pels ports 443 i 853, així que una regla que bloqueja el port 53 no ha dit res sobre ells. Bloquejar "DNS" per port és una política sobre un port, no sobre la resolució de noms. Si el vostre kill switch bloqueja tot el trànsit fora del túnel, el DoH queda cobert per accident. Si heu fet una excepció per a un portal captiu o un resolutor públic, no.
Els controls del costat del client són la palanca més barata. Firefox abandona el seu resolutor DoH quan el nom canariuse-application-dns.netno es resol, i per això les xarxes gestionades publiquen aquest domini com a NXDOMAIN; la política empresarial també el pot fixar desactivat. L'Android Private DNS i el DNS segur de Chrome tenen els seus propis interruptors i els seus propis valors per defecte. Desactivar-los és més fiable que perseguir adreces de resolutors, perquè la llista d'adreces canvia i el vostre conjunt de regles no.
Hi ha una versió d'això que no va de fuites en absolut. Una aplicació amb un resolutor fixat encara necessita un camí de xarxa per arribar-hi. El xifratge canvia qui pot llegir la consulta, no si el paquet pot sortir de la màquina, així que un bloqueig de tot el dispositiu derrota el paràmetre sense tocar-lo.
Caseu el símptoma amb la capa
La majoria d'informes us arriben com una frase, i aquesta frase normalment ja anomena la capa. La taula de sota és el que repasso abans de tocar cap regla; el punt és decidir si la consulta es va bloquejar, es va adreçar malament o no es va enviar mai.
| 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 |
Les dues primeres files són les que la gent diagnostica malament. Una caiguda silenciosa i un refús s'assemblen a "el DNS està trencat" al navegador, però només un dels dos significa que el vostre kill switch fa la seva feina. Un refús vol dir que alguna cosa ha respost, així que el bloqueig no és on penseu.
Restaureu la política del resolutor i després demostreu-la
Arregleu el disseny, no el símptoma. Per a la resolució només per túnel, permeteu 53 a la interfície del túnel, empenyeu el resolutor intern amb la configuració del túnel i deixeu l'enllaç físic sense cap permís de DNS. Amb wg-quick, la líniaDNS =és la que escriu el resolutor a la configuració de la interfície, així que un túnel que l'omet deixa el resolutor antic al seu lloc i cada consulta pel camí equivocat.El manual de wg-quickdocumenta aquest comportament per plataforma.
Després verifiqueu en aquest ordre. A Linux,resolvectl statusmostra l'enllaç actiu,dig +short example.comprova un nom públic,dig @10.8.0.1 internal.example.comprova el privat, isudo tcpdump -ni any port 53mostra quina interfície fan servir els paquets mentre executeu tots dos. A Windows,Get-DnsClientServerAddress -AddressFamily IPv4iResolve-DnsName example.comdonen els mateixos dos fets: qui està configurat i qui respon.
Acabeu amb la prova negativa. Desconnecteu el túnel, confirmeu que un nom públic nou falla, confirmeu que el nom privat falla, iconfirmeu que cap paquet del port 53 ha sortit de l'adaptador físic. Un bloqueig que només aguanta per a respostes en memòria cau no aguanta gens.
Llista de comprovació abans de tancar el tiquet:
- El resolutor utilitzat durant l'avaria és el que la política pretén.
- La consulta del propi punt final del client encara es permet, per memòria cau o per excepció.
- DoH i DoT o bé queden coberts pel bloqueig o bé desactivats per política.
- Les zones privades fallen tancades, no obertes, un cop el túnel ha desaparegut.