¿El VPN cambió mi DNS? Compare el antes y el después

Conecta el túnel, abre un panel privado y el nombre se resuelve en una dirección que nunca había visto. O ocurre lo contrario: el navegador sigue funcionando mientras una herramienta de línea de comandos de pronto no resuelve nada. Ambos resultados vienen del mismo cambio, y la gente suele explicarlo con una sola frase sobre el VPN que "usa su propio DNS", que no es lo bastante precisa para depurar ni para verificar. En esa frase se esconden dos preguntas: qué consultas debe asumir este perfil y si su máquina realmente las envió al resolutor que se le entregó. Mantenerlas separadas es todo el método, porque una prueba que las mezcla produce una respuesta equivocada y segura de sí misma en ambas direcciones.

Por qué un perfil proporciona un resolutor

Dentro de un túnel, los nombres detrás del extremo remoto suelen resolverse en direcciones que solo existen en esa red. Una zona privada como corp.internal no tiene delegación pública, así que el resolutor que la responde debe ser alcanzable desde dentro del túnel. El mismo mecanismo sirve a un segundo propósito: cuando las consultas saldrían por su proveedor, un resolutor del lado remoto mantiene la consulta dentro de la ruta cifrada. Por eso la dirección del servidor DNS llega como parte de la política de la conexión y no como un ajuste global que usted eligió una vez para la máquina.

La dirección por sí sola no decide nada. Un resolutor solo puede responder si hay una ruta hacia él, y el fallo más común es un resolutor alcanzable solo mientras el túnel está activo. Cuando el túnel cae y la política permanece, las consultas van a una dirección sin ruta, y el síntoma es un tiempo de espera agotado y no un error limpio. Esa diferencia importa cuando lee el siguiente resultado de prueba, porque un tiempo agotado envía a la gente a ajustes de transporte que nunca estuvieron implicados.

Compare los dos diseños antes de comparar respuestas

El túnel completo y el DNS dividido producen expectativas opuestas, y ninguno de los dos es un mal funcionamiento. Bajo un túnel completo, cada consulta puede pasar al proveedor o al resolutor corporativo, así que es esperable que los nombres públicos respondan distinto tras conectar. Bajo DNS dividido, solo los dominios listados van al resolutor privado mientras todo lo demás permanece local; en Windows la lista de dominios vive en la Name Resolution Policy Table, en macOS en los dominios de coincidencia de los ajustes de DNS, y en un equipo con systemd-resolved en los dominios de enrutamiento por enlace.

Esa es la comparación que hay que hacer primero, porque decide qué cuenta como fallo. Con DNS dividido, un nombre público que responde desde un resolutor nuevo es lo que merece investigarse, mientras que un nombre interno que responde correctamente es el sistema haciendo su trabajo. Con un túnel completo, la anomalía es un nombre público que sigue respondiendo desde el resolutor de su proveedor. La documentación de Microsoft sobre la resolución de nombres de VPN describe el orden de Windows de estas reglas, incluido cómo se consulta una entrada de política coincidente antes que los servidores propios del adaptador.

Hay un tercer resolutor en la sala que es fácil de olvidar. El DNS seguro del navegador resuelve nombres por su cuenta y puede seguir respondiendo después de que el túnel cambiara la política del sistema operativo, así que una página que carga demuestra que funcionó el resolutor del navegador, no que se aplicó el perfil. Si solo compara lo que muestra el navegador, la mitad de las veces está probando la capa equivocada.

Registre una línea base con una sola variable

Cambie el túnel. No cambie también el nombre, la herramienta o el sufijo de búsqueda en el mismo paso. Elija un nombre que tenga permitido consultar, anote qué aplicación usó y escriba o bien la dirección que volvió o bien el error exacto. En Windows, Get-DnsClientServerAddress -AddressFamily IPv4 imprime los servidores por adaptador y Get-DnsClientNrptPolicy imprime las entradas de política; en Linux con systemd-resolved, resolvectl status muestra los servidores DNS y los dominios de enrutamiento por enlace; en macOS, scutil --dns imprime el orden de resolutores que el sistema seguirá realmente.

Después conéctese con los controles habituales del cliente y repita exactamente los mismos comandos. Guarde la primera salida en lugar de recordarla, porque la comparación es todo el asunto y una segunda lectura tomada después de vaciar la caché ya es otra medición. Si la línea base se tomó con el navegador delante y la ejecución posterior a la conexión ocurre en un terminal, está comparando dos resolutores, no dos estados de un mismo resolutor.

Una consulta explícita y una búsqueda de aplicación son pruebas distintas

Preguntar a un servidor concreto, con nslookup name 10.20.0.1 o dig @10.20.0.1 name, demuestra una sola cosa: que el servidor que nombró responde cuando puede alcanzarlo. Se salta por completo la lógica de selección, así que no puede decirle si el sistema habría elegido ese servidor para este nombre. Úselo para comprobar si el resolutor asignado es alcanzable, y no lo use para comprobar la política.

Una búsqueda a través del resolutor local sí ejercita la selección. resolvectl query name recorre las mismas reglas de dominios de enrutamiento e informa qué protocolo respondió, Resolve-DnsName en Windows pasa por la tabla de política y la caché del cliente, y scutil --dns muestra el orden que seguiría una búsqueda. Ejecute ambos tipos y manténgalos en columnas separadas de sus notas. Una consulta explícita correcta junto a una búsqueda de aplicación fallida es un problema de enrutamiento o de selección, no un resolutor que se niega a funcionar.

La caché se interpone entre usted y la respuesta. El sistema operativo, el resolutor stub local, el navegador y la caché negativa guardan resultados, así que una búsqueda puede tener éxito sin que un solo paquete salga de la máquina. Registre el resultado antes de vaciar nada: ipconfig /flushdns, resolvectl flush-caches o sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder en macOS. Omita el reinicio amplio de red en esta etapa, porque destruye la evidencia que aún está recogiendo.

Qué significa la diferencia

Compare las dos filas que registró y clasifique el cambio antes de tocar un solo ajuste.

Una fila merece énfasis. Un nombre que se resuelve no es un servicio que funciona, y el éxito del DNS solo dice que se encontró una dirección. No dice nada sobre el reenvío, las reglas del cortafuegos ni si su cuenta puede usar el servicio, así que termine probando la aplicación real en lugar de suponer que el fallo se retiró solo.

Restaure la línea base y verifíquela

Desconecte con los controles propios del cliente en lugar de matar el proceso, y luego vuelva a leer los mismos tres comandos. Los servidores por enlace, las entradas de política y la respuesta para su nombre de prueba deberían volver a la línea base que escribió antes. Una entrada de política que queda tras una desconexión limpia es un defecto real que vale la pena registrar, y también es la razón de que las ediciones manuales de un archivo de resolutor generado sean un mal hábito: el archivo se reescribe y la edición desaparece, o la edición sobrevive y fija un resolutor que ya no tiene ruta.

Recorra esta lista una vez, en orden. Decida qué diseño implementa el perfil antes de juzgar cualquier resultado. Mantenga el nombre, la herramienta y el sufijo fijos en las dos ejecuciones. Separe la consulta explícita de la búsqueda de aplicación. Lea la política efectiva, no solo la respuesta. Vacíe las cachés al final, después de escribir la comparación. Verifique con la aplicación real, luego reinicie una vez y confirme que el estado desconectado sigue limpio.