Por qué fallan los nombres DNS privados en los clientes VPN y dónde revisar

Abres un portátil en una habitación de hotel, arrancas el cliente, escribes el nombre del servidor de archivos interno y no recibes nada. El túnel dice conectado, y un ping a una dirección dentro de la misma subred sigue respondiendo, así que el transporte está bien. Solo falla el nombre, y ese hueco reduce el problema a dos sitios: a qué resolutor preguntó el cliente y si la respuesta que obtuvo puede volver por el túnel. Acierta uno y omite el otro, y el fallo simplemente se desplaza.

Antes de editar cualquier perfil, confirma qué hace el cliente con el nombre. En Linux, resolvectl query files.corp.example muestra qué enlace y qué resolutor produjeron la respuesta. En Windows, Resolve-DnsName files.corp.example muestra el servidor que respondió y la dirección que devolvió.

Lee la respuesta antes de cambiar nada

Si el nombre vuelve como NXDOMAIN en unos milisegundos, la consulta nunca llegó a tu zona y respondió algún resolutor público o del hotel. Si vuelve tras una pausa larga, algo está descartando el puerto UDP 53 por el camino y el cliente acabó recurriendo a otro. Si responde con la dirección correcta pero la conexión sigue atascada, la consulta está bien y tu problema es el enrutamiento o el propio servicio.

Esa división en tres ahorra una hora de conjeturas. También te dice si debes tocar la VPN: un nombre que resuelve a la dirección privada correcta ya ha demostrado la ruta del resolutor, así que el trabajo que queda está en la ruta de datos.

Reparte el resolutor desde dentro del túnel

Los clientes se dividen en dos grupos. A uno se le puede indicar un resolutor desde el servidor durante el establecimiento de la conexión; el otro guarda el ajuste en un archivo local que ningún gateway puede cambiar en remoto.

OpenVPN está en el primer grupo. En el servidor, push "dhcp-option DNS 10.8.0.53" y push "dhcp-option DOMAIN corp.example" viajan por el canal de control, pero solo si la configuración del cliente todavía tiene pull activado. Un cliente editado a mano que lleve pull-filter ignore "dhcp-option" no los verá nunca, y esa sola línea explica un número sorprendente de casos de «el servidor lo empuja pero mi portátil opina otra cosa».

WireGuard está en el segundo grupo, porque el protocolo no tiene ninguna negociación de opciones. El resolutor y el dominio de búsqueda van en el bloque [Interface] del propio cliente como DNS = 10.8.0.53, corp.example. wg-quick lo aplica mediante resolvconf o systemd-resolved, y en Windows el cliente oficial instala reglas NRPT que solo existen mientras el túnel está levantado: Get-DnsClientNrptPolicy las enumera, lo que lo convierte en una forma rápida de ver si el cliente llegó a aplicar tu archivo.

IPsec/IKEv2 queda en medio. El complemento attr de strongSwan puede devolver un servidor DNS sacado de un grupo, y un cliente Windows normalmente lo acepta, pero un perfil que fija su propio servidor de nombres gana a lo que ofrezca la pasarela. En un cliente Linux el paso manual equivalente es resolvectl dns wg0 10.8.0.53 seguido de resolvectl domain wg0 '~corp.example'; ambos desaparecen cuando lo hace la interfaz, que es justo lo que quieres para un ajuste acotado al túnel.

Acota el sufijo en vez de tragarte cada consulta

Apuntar toda la lista de resolutores del cliente a tu servidor interno es fácil y casi siempre erróneo. Entonces cada nombre público resuelve desde la salida de tu centro de datos, las CDN devuelven direcciones lejanas y una caída del resolutor se lleva por delante la navegación del usuario.

Envía hacia dentro solo el sufijo privado. En systemd-resolved, un dominio que empieza por ~ es solo de enrutamiento, así que ~corp.example significa que las consultas bajo ese sufijo van a los servidores de ese enlace mientras todo lo demás sigue usando la red física. Windows hace lo mismo con reglas NRPT acotadas a un espacio de nombres, y macOS con un archivo de resolutor suplementario bajo /etc/resolver/.

Los nombres de multidifusión merecen su propia respuesta. Los nombres .local son locales al enlace por diseño (RFC 6762) y una interfaz tun punto a punto no transporta ese grupo de multidifusión, así que añadir un resolutor público no los publica y preguntar por ellos a un resolutor interno de unidifusión devuelve NXDOMAIN. Un reflector como avahi en modo reflector puede unir dos segmentos, pero eso es una decisión del lado del servidor que ningún cliente puede pedir. Si una impresora o un NAS tiene que ser accesible por nombre, dale un registro A en tu zona.

Demuestra que la respuesta puede volver

Una respuesta correcta que apunta a una dirección inalcanzable parece exactamente un problema de resolutor hasta que compruebas la ruta. Pregunta al núcleo adónde iría la respuesta: ip route get 10.20.5.20 nombra la interfaz y, más útil, la dirección de origen que usaría.

Vigila la dirección del resolutor. Un cliente con DNS = 10.8.0.53 junto a AllowedIPs = 10.20.0.0/16 envía sus consultas por la NIC física, donde mueren en silencio, porque el resolutor no está dentro de ningún prefijo que el túnel reivindique. Esa discordancia es el fallo de causa única más común en toda esta área, y resulta invisible salvo que compares el ajuste de DNS con los prefijos permitidos línea por línea.

Los rangos solapados causan el fallo contrario. La respuesta es correcta, la ruta existe y apunta al host equivocado, porque 192.168.0.0/24 en casa es más específica que la ruta del túnel al mismo rango. Renumera un lado o empuja una ruta más estrecha, y luego confirma el cortafuegos y la ruta de vuelta del host del servicio; las notas de strongSwan sobre reenvío cubren la parte sysctl de esa ruta.

Los certificados son una comprobación de identidad aparte que la gente le achaca al DNS. Si el navegador informa de un desajuste de nombre en vez de un error de resolución, la consulta ya funcionó y lo que hay que arreglar es el SAN del certificado. Prueba HTTPS contra el nombre, nunca contra la IP desnuda.

Reprueba desde el cliente, no desde la pasarela

Prueba dentro de la aplicación de la que se queja el usuario, porque una consulta en la línea de comandos no demuestra que el navegador siga el mismo camino. El DNS seguro de Chrome y network.trr.mode de Firefox pueden saltarse el resolutor del sistema por completo, y cuando lo hacen, un nombre privado falla o se filtra a un resolutor público. Comparar resolvectl query con un dig @10.8.0.53 files.corp.example ejecutado a mano te dice cuál de las dos cosas ocurrió.

Luego desconecta y vuelve a conectar antes de darlo por arreglado. Los ajustes aplicados a mano a una interfaz desaparecen con la interfaz, y un perfil que solo parecía correcto por una edición local olvidada fallará en el siguiente arranque.

Una lista breve para la siguiente máquina: el nombre resuelve por el resolutor del túnel, el sufijo está acotado en vez de ser global, la dirección del resolutor cae dentro de los prefijos permitidos, el host de la respuesta responde en el puerto del servicio y el certificado cubre el nombre que escribió el usuario.