Úsase de verdade o DNS da túa VPN? Captura o porto 53 e compróbao

Pregunta á maioría que fai un cliente de VPN co DNS e dirán que configura o resolutor, así que as consultas viaxan dentro do túnel. O empurrón é real; a suposición de que se converte nunha consulta, non. Entre unha opción empurrada e un paquete no cable hai tres etapas, e cada unha falla de forma independente en maneiras que todas parecen un servidor DNS roto. Por iso unha páxina de proba de fugas e un navegador que funciona poden discrepar sobre a mesma máquina no mesmo momento.

Unha opción empurrada non é unha consulta

A primeira etapa é que o servidor ofrece axustes, por exemplo unha opción DNS empurrada que nomea un resolutor dentro do túnel. A segunda etapa é que o cliente aplica eses axustes a unha interface. A terceira etapa é que unha aplicación envíe realmente unha consulta a ese enderezo. Un fallo na segunda etapa deixa a opción visible no rexistro de conexión mentres a lista de resolutores segue sen cambios, e un fallo na terceira etapa deixa unha lista de resolutores perfectamente correcta sen usar.

A maioría do diagnóstico funde esas tres nunha e culpa o servidor VPN, que adoita ser a única parte que pode demostrar que fixo o seu. Le en cambio o estado real do resolutor do cliente e despois observa saír unha consulta. Esas dúas observacións separan a configuración do encamiñamento e da política, e custan uns cinco minutos. Garda as capturas, porque o seguinte enxeñeiro quere o antes e o despois, non unha descrición.

Comproba que garda realmente a interface

En Linux o resolutor do sistema pode ser o ficheiro simple, NetworkManager ou systemd-resolved, e cal deles o posúe decide onde aterra un servidor empurrado. Un proceso OpenVPN de liña de ordes non actualiza o resolutor do sistema por si só, así que a integración documentada é un script up/down ou un xestor de conexións que xa sabe aplicar os axustes. Executar ambos é unha forma eficaz de crear unha carreira.

resolvectl status
cat /etc/resolv.conf

En Windows a lista é por adaptador, así que o adaptador do túnel pode ter os servidores internos mentres o adaptador físico conserva os locais e gaña para algúns nomes. Compara ambos adaptadores en lugar do que supoñas activo.

Segue unha consulta fóra da máquina

Captura ambas interfaces á vez e despois resolve un nome que debería usar o resolutor interno. Ese par de capturas responde o que ningunha saída de configuración pode.

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

Unha consulta que aparece na interface física e nunca no túnel significa que o cliente escolleu o resolutor equivocado. Unha consulta en ningunha das dúas significa que a aplicación respondeu da caché, preguntou a un stub que escoita en loopback ou usou un resolutor cifrado cuxo tráfico nunca aparece como porto 53. Captura tamén as respostas, non só as consultas, porque unha consulta que sae polo túnel cunha resposta dun enderezo público é un fallo distinto a que non chegue ningunha resposta.

O cortafogos que só acepta o seu propio DNS

Os clientes comerciais ás veces instalan as súas propias cadeas de filtrado. Un patrón documentado permite DNS cara ao resolutor propio do cliente e descarta todo o tráfico UDP restante do porto 53 que tenta saír dunha interface que non é loopback, incluído o tráfico que o usuario encamiñou deliberadamente a outro sitio. As consultas do demonio desaparecen sen rastro, o que se le como un fallo do resolutor en vez de como un filtro.

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

Se unha regra de descarte se avalía antes da túa excepción, unha regra engadida ao final nunca se alcanza, así que insírea na primeira posición e limita o destino ao resolutor que realmente pretendes.

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

Esa excepción é de diagnóstico e non de política. Se a regra do provedor é deliberada, a reparación admitida é configurar o cliente para permitir ese resolutor e rexistrar a decisión, porque unha regra inserida non sobrevivirá á próxima actualización do cliente.

Por que unha páxina de fugas demostra menos do que parece

O que mostra unha páxina de proba de fugas é o resolutor que falou co operador da proba, non o que consultou a túa máquina. Un reenviador local que fai recursión cara a fóra pon o seu propio enderezo de saída nesa páxina, e as consultas cifradas poden deixar a páxina completamente en branco. Ambos resultados len mal, un como fuga e o outro como garantía, e ningunha das dúas lecturas se segue da observación.

A evidencia defendible é a captura: interface, enderezo de destino, resposta e marca de tempo. Toma unha antes de que suba o túnel e outra despois, e compáraas a próxima vez que falle un nome. Ese par tamén lle di á seguinte persoa se o fallo era de resolución, de encamiñamento ou da política de acceso do propio resolutor.