S’utilitza realment el DNS de la vostra VPN? Captureu el port 53 i comproveu-ho

Pregunteu a la majoria de la gent què fa un client de VPN amb el DNS i diran que configura el resolutor, de manera que les consultes viatgen dins del túnel. L’empenta és real; la suposició que es converteix en una consulta, no. Entre una opció empenyuda i un paquet al fil hi ha tres etapes, i cadascuna falla de manera independent en formes que semblen un servidor DNS espatllat. Per això una pàgina de prova de fuites i un navegador que funciona poden discrepar sobre la mateixa màquina en el mateix moment.

Una opció empenyuda no és una consulta

La primera etapa és que el servidor ofereix paràmetres, per exemple una opció DNS empenyuda que anomena un resolutor dins del túnel. La segona etapa és que el client aplica aquests paràmetres a una interfície. La tercera etapa és que una aplicació enviï realment una consulta a aquesta adreça. Una fallada a la segona etapa deixa l’opció visible al registre de connexió mentre la llista de resolutors no canvia, i una fallada a la tercera etapa deixa una llista de resolutors perfectament correcta sense usar.

La majoria de la diagnosi ajunta aquestes tres en una i culpa el servidor VPN, que normalment és l’única part que pot demostrar que va fer la seva feina. Llegiu en canvi l’estat real del resolutor del client i després observeu com surt una consulta. Aquestes dues observacions separen la configuració de l’encaminament i de la política, i costen uns cinc minuts. Guardeu les captures, perquè el següent enginyer vol la situació d’abans i la de després, no una descripció.

Comproveu què té realment la interfície

A Linux el resolutor del sistema pot ser el fitxer simple, NetworkManager o systemd-resolved, i quin d’ells en té la propietat decideix on acaba un servidor empenyut. Un procés OpenVPN de línia d’ordres no actualitza el resolutor del sistema per si sol, així que la integració documentada és un script up/down o un gestor de connexions que ja sap com aplicar els paràmetres. Executar tots dos és una manera eficient de crear una cursa.

resolvectl status
cat /etc/resolv.conf

A Windows la llista és per adaptador, així que l’adaptador del túnel pot tenir els servidors interns mentre l’adaptador físic es queda amb els locals i guanya per a alguns noms. Compareu els dos adaptadors en lloc del que suposeu actiu.

Seguiu una consulta fora de la màquina

Captureu les dues interfícies alhora i després resoleu un nom que hauria d’usar el resolutor intern. Aquest parell de captures respon el que cap sortida de configuració pot respondre.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Una consulta que apareix a la interfície física i mai al túnel vol dir que el client va triar el resolutor equivocat. Una consulta a cap de les dues vol dir que l’aplicació va respondre de la memòria cau, va preguntar a un stub que escolta a loopback o va usar un resolutor xifrat el trànsit del qual no apareix mai com a port 53. Captureu també les respostes, no només les consultes, perquè una consulta que surt pel túnel amb una resposta d’una adreça pública és una fallada diferent que no arribi cap resposta.

El tallafoc que només accepta el seu propi DNS

Els clients comercials de vegades instal·len cadenes de filtratge pròpies. Un patró documentat permet DNS cap al resolutor propi del client i descarta tota la resta de trànsit UDP del port 53 que intenta sortir d’una interfície que no és loopback, inclòs el trànsit que l’usuari va encaminar deliberadament a un altre lloc. Les consultes del dimoni desapareixen sense rastre, cosa que es llegeix com una fallada del resolutor i no com un filtre.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Si una regla de descart s’avalua abans de la vostra excepció, una regla afegida al final no s’assoleix mai, així que inseriu-la a la primera posició i limiteu la destinació al resolutor que realment voleu.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Aquesta excepció és de diagnosi i no de política. Si la regla del proveïdor és deliberada, la reparació suportada és configurar el client per permetre aquest resolutor i enregistrar la decisió, perquè una regla inserida no sobreviurà a la propera actualització del client.

Per què una pàgina de fuites demostra menys del que sembla

El que mostra una pàgina de prova de fuites és el resolutor que va parlar amb l’operador de la prova, no el que va consultar la vostra màquina. Un reenviador local que fa recursió cap a fora posa la seva pròpia adreça de sortida en aquesta pàgina, i les consultes xifrades poden deixar la pàgina completament en blanc. Tots dos resultats es llegeixen malament, un com a fuita i l’altre com a garantia, i cap de les dues lectures es desprèn de l’observació.

L’evidència defensable és la captura: interfície, adreça de destinació, resposta i marca de temps. Feu-ne una abans que pugi el túnel i una després, i compareu-les el proper cop que falli un nom. Aquest parell també diu a la propera persona si la fallada era de resolució, d’encaminament o de la política d’accés del propi resolutor.