Por qué nslookup resuelve por la VPN pero el navegador no

nslookup envía una consulta al servidor que usted indica e imprime la respuesta, por eso puede tener éxito mientras todas las pestañas del navegador fallan. El navegador pide al sistema operativo que resuelva, y el sistema sopesa los resolutores de cada interfaz, las reglas de política de resolución de nombres y la ubicación de red del adaptador. Después el navegador puede añadir su propio DNS cifrado por encima. Tres rutas distintas, un síntoma, y el túnel normalmente no es la parte averiada.

Las comprobaciones siguientes recorren esas rutas desde el sistema hacia fuera. No edite el perfil de la VPN hasta saber qué ruta respondió y cuál falló.

Tres políticas deciden la respuesta

Cada interfaz lleva su propia lista de resolutores y sus sufijos de búsqueda. Un adaptador de VPN añade servidores mientras el adaptador físico conserva los suyos, y el sistema puede tomar el que responda primero, así que una consulta puede servirse fuera del túnel sin que nadie lo haya elegido. Las reglas de la tabla de política de resolución de nombres pueden enviar dominios seleccionados a servidores seleccionados, que es como normalmente se expresa el DNS dividido en Windows. Y el cliente o la puerta de enlace de la VPN pueden empujar una dirección de resolutor que solo existe dentro de la red privada.

Esos tres interactúan de maneras que desde un navegador parecen arbitrarias. Un resolutor empujado en una dirección privada sin ruta por el túnel dividido hace que cada consulta se atasque y luego falle. Una regla de política que cubre el sufijo interno y apunta a un servidor caído produce el mismo error visible que una ruta ausente. Un sufijo de búsqueda que falta en el adaptador de la VPN convierte un nombre corto en una consulta pública por el dominio equivocado. Cada uno necesita una reparación distinta.

Por qué el navegador hace otra pregunta

nslookup emite su propia consulta al servidor que elige y no sigue ni la política de espacio de nombres ni el ajuste de DNS cifrado del navegador. Por eso una consulta manual contra un resolutor público responde mientras el navegador informa de que el sitio no existe. Usted compara dos programas, no dos estados de un programa.

La preferencia de familia de direcciones explica un retraso, no un fallo. Un navegador que pide primero registros IPv6 en un túnel que solo transporta IPv4 espera a que venza el tiempo de espera antes de retroceder. Firefox ha llevado una preferencia precisamente para esto, y desactivarla es un paso de diagnóstico, no una reparación.

Lea la lista de resolutores y las reglas

En Windows, vuelque lo que el sistema guarda antes de teorizar. Get-DnsClientServerAddress muestra los servidores por interfaz, Get-DnsClientNrptRule enumera las reglas de espacio de nombres y Resolve-DnsName responde el nombre exacto por la ruta del sistema. Compare esa respuesta con una consulta directa al servidor de la VPN por dirección. Cuando Resolve-DnsName falla y la consulta directa tiene éxito, el sospechoso es la lista de resolutores o una regla de espacio de nombres.

Compruebe también el nombre en sí. Un nombre corto interno puede necesitar el sufijo privado que solo proporciona el adaptador de la VPN, mientras que el nombre totalmente cualificado se resuelve bien. Un aviso de certificado tras una consulta correcta pertenece a otro problema.

El resolutor empujado inalcanzable

La puerta de enlace o el cliente pueden empujar una dirección de resolutor, y esa dirección debe ser alcanzable por el túnel. En un túnel dividido, el rango privado que contiene el resolutor puede no estar entre las rutas incluidas, lo que produce una consulta que nunca recibe respuesta. Confirme que la ruta existe y luego consulte esa dirección en concreto, por el túnel. Este es el fallo detrás de un error de dominio en el navegador mientras un resolutor público todavía responde.

Si el resolutor es inalcanzable, la reparación es una ruta o una subred incluida, no otro servidor DNS.

El DNS cifrado evita toda la ruta

Los navegadores con DNS-over-HTTPS resuelven los nombres ellos mismos mediante una conexión HTTPS a un proveedor elegido. Con eso activado, el resolutor del sistema y las reglas de DNS dividido se evitan por completo para esas consultas, así que los nombres internos fallan en el navegador mientras el sistema operativo los resuelve correctamente. También ocurre lo contrario: nombres internos tienen éxito en el navegador a través de un proveedor que nunca debería verlos, y eso es un problema de política, no de conectividad.

Decida deliberadamente si se permite el DNS cifrado en dispositivos gestionados y luego configúrelo mediante la superficie de gestión del navegador para que la elección sea visible. Dejarlo a la preferencia individual produce un parque donde la misma VPN se comporta distinto en cada portátil.

Reparaciones que encajan con el fallo

Si la VPN empuja su resolutor, haga que el túnel lleve tráfico hacia él y que el mismo ajuste sea visible en los adaptadores que participan en la resolución. Si los sitios locales dejan de resolverse mientras está conectado, añada excepciones explícitas de espacio de nombres o un reenviador condicional en lugar de sustituir el resolutor por completo. Si el DNS cifrado del navegador evita la política, ese es el ajuste que hay que cambiar. Nunca añada un resolutor público para arreglar un nombre interno: filtra consultas privadas y no resuelve el nombre.

Luego separe la consulta de la conexión. Un nombre que se resuelve a la dirección correcta pero rechaza una conexión es un problema de servicio, cortafuegos o certificado, y los cambios de DNS no lo arreglarán.

Registre qué ruta respondió, cuál falló y qué cambió. El siguiente informe del mismo síntoma costará entonces un comando en lugar de una tarde.