Los nombres internos fallan en la VPN mientras los sitios públicos resuelven

Un usuario informa de que el nombre de host de la intranet no resuelve por la VPN. Un segundo informe, del mismo portátil, dice que una prueba de fugas sigue mostrando consultas respondidas por el resolutor local. Suenan como un solo problema y son dos, con pruebas distintas, y la reparación habitual del primero empeora el segundo. Sepárelos antes de tocar cualquier ajuste.

Dos síntomas que no son un solo fallo

No poder resolver un nombre interno significa que la pregunta fue a un lugar que no tiene respuesta para ella. Que las consultas salgan del túnel significa que la pregunta fue al lugar equivocado incluso cuando la respuesta estaba disponible. Son fallos opuestos: uno es una respuesta que falta, el otro es un destino de más.

La trampa es que añadir el resolutor de la oficina en todas partes arregla el primero y garantiza el segundo. Añadir un resolutor público en todas partes hace lo contrario.

Anote ambas observaciones con marca de tiempo y después recorra las cuatro comprobaciones de abajo en orden.

Qué resolutor del adaptador recibe la pregunta

En Windows el cliente DNS elige servidores según el orden de enlace de los adaptadores, y el adaptador del túnel no es automáticamente el primero. Abra la configuración avanzada del adaptador y mueva la conexión de acceso remoto por encima del adaptador físico, y vuelva a conectar para que el cambio valga en una sesión nueva.

El orden de enlace es solo la primera mitad. El cliente también tiene que saber qué nombres pertenecen a ese adaptador, y eso es una cuestión de sufijo, no de orden.

Ponga la salida de ipconfig /all de la máquina que funciona junto a la del portátil, ambas tomadas con el túnel levantado. La máquina que funciona mostrará un sufijo DNS específico de la conexión en su adaptador de oficina, y el portátil quizá no muestre ninguno en el túnel. Esa diferencia explica toda una clase de informes del tipo el servidor está justo ahí y el nombre sigue fallando, porque sin sufijo el nombre corto nunca se completa dentro de la zona que sirve el resolutor de la oficina.

Un nombre corto necesita un sufijo antes que una ruta

Escribir un nombre de host no cualificado pide al resolutor que adivine un dominio. La adivinanza viene de la lista de sufijos asociada a la conexión, y si esa lista está vacía la consulta sale como una sola etiqueta que ninguna zona privada encajará.

Copie el sufijo de la máquina que funciona en las propiedades IPv4 del adaptador de la VPN, en la pestaña DNS, y vuelva a conectar. En Linux el equivalente es el dominio de búsqueda del enlace del túnel, que systemd-resolved expone por enlace y no globalmente.

Mantenga los dos ajustes separados en sus notas. El sufijo cambia qué se pregunta; la dirección del resolutor cambia a quién se pregunta. Arreglar uno mientras el otro está mal produce un resultado que parece aleatorio.

Pregunte al resolutor directamente, luego al nombre

Una consulta directa al resolutor de la oficina separa un problema de nombre de un problema de camino, porque salta por completo la elección de resolutor del cliente.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

La primera orden pide un nombre totalmente cualificado a un servidor concreto. Si responde, el resolutor y la ruta hacia él están bien y el fallo está en la elección o en el sufijo. Si se agota el tiempo, la dirección es incorrecta o inalcanzable y el problema es de encaminamiento, no de DNS. La segunda orden muestra qué pasa con el nombre corto, y la tercera imprime la configuración de resolutor por enlace en un host con systemd.

Vigile las respuestas comodín que algunas redes devuelven para nombres desconocidos. Una respuesta verosímil no prueba que haya contestado el servidor buscado, así que compare la dirección devuelta con la que el servicio interno usa de verdad. Si la dirección pertenece a una página de aparcamiento o a un proxy, el resolutor contestó pero la respuesta nunca fue suya. Esa distinción ahorra una hora persiguiendo un túnel que funcionaba todo el tiempo.

En Linux, un cliente de VPN que reescribe /etc/resolv.conf sustituye los resolutores locales por completo. vpnc expone DNSUpdate no para evitarlo, y systemd-resolved puede encaminar solo los dominios listados al enlace del túnel. Ambos enfoques mantienen los nombres públicos en el resolutor local y envían los nombres internos a la oficina.

Las fugas son una regla, no una casilla

La resolución de nombres es un intercambio UDP al puerto 53, así que un túnel que lleva tráfico web pero no UDP deja la consulta en el camino físico. Demuéstrelo capturando en la tarjeta de red física mientras se resuelve un nombre público. Una consulta visible en esa interfaz en forma legible significa que el túnel no la lleva.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Si la consulta aparece en esa interfaz en forma legible, el túnel no la lleva. La reparación es una regla que permite el puerto 53 solo al resolutor que empujó la VPN y descarta otros destinos, más una configuración de cliente que no descarte en silencio la opción empujada.

Esa última parte importa más de lo que parece. Arranque OpenVPN con route-nopull y la opción DNS empujada desaparece junto con las rutas, salvo que el filtro de extracción se amplíe para retenerla. Y un cliente que ignore dhcp-option DNS seguirá usando lo que tenía antes. Cualquier cambio en el lado del servidor necesita una sesión nueva para valer, porque la lista de resolutores se entrega cuando el túnel sube y una sesión vieja sigue mostrando el estado antiguo.

Anote qué fallo observó realmente antes de cerrar el tiquete. Una respuesta interna que falta y una consulta que se escapa del túnel piden reparaciones distintas, y un cambio de sufijo que arregla la primera puede empeorar en silencio la segunda. Quien recoja el tiquete después se fiará de la etiqueta, así que haga la etiqueta exacta.