VPN conectada pero los nombres fallan: dónde se rompe realmente el DNS

Túnel activo, icono verde y cada pestaña del navegador informa de un fallo de resolución de nombres. Tres mecanismos distintos producen esa imagen: el resolutor puede ser inalcanzable, el cliente puede estar preguntando a un resolutor que usted no esperaba, o solo pueden fallar los nombres privados. Sepárelos antes de cambiar nada del protocolo del túnel, porque cada uno se repara en un lugar distinto. El orden siguiente empieza por las observaciones que separan los tres casos.

Qué necesita realmente una consulta

Una consulta necesita tres cosas: una dirección de resolutor, una ruta hasta esa dirección y una respuesta que coincida con la pregunta. Cada una puede fallar por separado, y el síntoma visible es la misma página que no carga. Por eso la página de error no le dice casi nada hasta que sabe cuál de las tres se rompió.

El cliente aprende su resolutor del perfil VPN, del DHCP del túnel o de su propia configuración, y qué fuente gana depende de la plataforma. En Windows, ipconfig /all enumera los servidores DNS por adaptador, así que puede ver si el valor enviado llegó realmente. Un valor enviado que nunca llegó al sistema operativo es un fallo silencioso y habitual. Lea el valor configurado antes de tocar el perfil.

Linux y macOS responden a la misma pregunta con comandos distintos, y la respuesta merece la misma lectura: resolvectl status y scutil --dns ambos enumeran los servidores por interfaz. Compare esa lista con la dirección que el perfil dice enviar. Una discrepancia aquí explica todo lo demás, así que resuélvala antes de probar nombres.

Pruebe un nombre público y uno privado

Consulte un nombre de host público corriente y el nombre de host privado documentado desde la misma máquina, y anote qué servidor respondió a cada uno. Si fallan ambos, el resolutor o su ruta están rotos. Si solo falla el nombre privado, el resolutor respondió y la pregunta pasa a ser la zona o el enrutamiento. Ejecute las dos consultas con menos de un minuto de diferencia para que un cambio de ruta no pueda explicar la diferencia.

Mantenga los nombres internos fuera de las capturas públicas y de los resolutores públicos. Un tiempo de espera y una respuesta de dominio inexistente son observaciones distintas: la primera dice que no volvió nada, la segunda que una autoridad respondió que el nombre no existe. Tratarlos como un solo error le lleva a la capa equivocada, y un aviso de certificado es otra tercera cosa, no un fallo de DNS.

nslookup muestra tanto el servidor al que preguntó como la respuesta recibida, y ese es exactamente el par que necesita. Ejecútelo dos veces en el mismo intérprete de órdenes y escriba la dirección que responde junto a cada respuesta.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Confirme que el cliente puede llegar realmente a ese servidor

Un resolutor privado enviado por el perfil solo es útil si el cliente puede alcanzarlo con el túnel activo. Una dirección que parece correcta sin ruta produce un tiempo de espera, y el estado conectado del túnel no dice nada sobre esa ruta. La comprobación es una consulta de ruta dirigida al propio resolutor, no al extremo del VPN.

Cada plataforma responde eso en una línea, y la interfaz indicada en la salida es toda la respuesta. Si apunta al adaptador físico mientras el resolutor está detrás del túnel, el perfil no envía un prefijo que lo cubra.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

En un perfil de túnel dividido, el resolutor puede quedar fuera de las rutas enviadas, lo que es un problema del perfil y no del servidor. Compare la dirección del resolutor con los prefijos enviados y confirme que uno de ellos lo cubre. La misma discrepancia explica por qué el DNS funciona en una red y falla en otra con un perfil idéntico.

Recuerde que los navegadores pueden saltarse el resolutor del sistema

Un navegador con DNS seguro activado puede enviar consultas por HTTPS a un proveedor de su elección e ignorar por completo el resolutor del sistema operativo. Entonces el sistema parece correcto mientras el navegador falla, o al revés. Eso es una cuestión de política del navegador, no del túnel.

Revise el ajuste de DNS seguro del navegador y cualquier política administrada que lo controle, y luego pruebe una segunda aplicación o navegador con el túnel sin cambios. Si solo falla una aplicación, la corrección pertenece a esa aplicación. Una ventana privada no es una comparación limpia, porque puede desactivar extensiones de forma predeterminada en un navegador y no en otro, y nunca elude una política administrada. Use en su lugar un segundo perfil de navegador u otra aplicación.

Vacíe la caché y vuelva a probar la tarea real

Después de corregir un ajuste, vacíe la caché local del resolutor para que una respuesta antigua no sobreviva a la corrección. Una recuperación breve seguida de otro fallo significa que la causa sigue ahí, no que el vaciado haya fallado. Elija la línea que corresponda a la máquina en la que está, porque las tres cachés son independientes.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Luego repita la tarea original en lugar de una consulta sintética, porque la tarea es lo que le importa al usuario. Vuelva a conectarse una vez, para que la repetición cubra el estado en el que el usuario estará realmente. La referencia de nslookup de Microsoft es la página que conviene guardar para los argumentos de la consulta.

Si los nombres fallan solo tras desconectar, el cliente no restauró la configuración anterior, lo que es un error de ciclo de vida que hay que reportar, no un servidor DNS que haya que sustituir. Una consulta que funciona tampoco es una prueba de fuga, porque el país de salida no le dice qué resolutor respondió.