Tu túnel dividido llega a la aplicación pero no a su servidor DNS

Enrutar la subred de la aplicación es la parte obvia de un túnel dividido, y no es todo el trabajo. El resolutor suele estar en una dirección distinta de la aplicación a la que sirve, así que un túnel que funciona puede dejar la consulta fuera de él. Un perfil que transporta 10.80.0.0/16 y nada más envía la consulta de 10.90.0.53 por la interfaz local, donde no existe ninguna zona privada. Añade la ruta del resolutor y luego mira la otra mitad del problema: qué servidor elige realmente el cliente.

El mito: una ruta cubre todo el servicio

Un túnel dividido es una lista de destinos que pasan por la conexión, no una descripción de un servicio. La subred de la aplicación y la dirección del resolutor son dos destinos, y un perfil puede llevar uno sin el otro. Cuando eso ocurre, la aplicación es accesible por dirección mientras su nombre falla, lo que parece un fallo de DNS más que un hueco de enrutamiento.

La subred que rodea al resolutor tampoco queda cubierta automáticamente. Una ruta de host a una sola dirección basta para ese resolutor y no abre sus vecinos. Ese es el sentido de una ruta de host: estrecha por diseño y fácil de olvidar cuando el siguiente servicio aparece en la misma subred.

Tres cosas deben cumplirse para que la consulta funcione: el cliente enruta la dirección del resolutor por el túnel, la puerta de enlace admite y reenvía esa petición, y el resolutor acepta la fuente que recibe. La respuesta también tiene que volver por la ruta acordada. Si falta cualquiera de ellas, el síntoma es idéntico, por eso conviene escribir la tabla de direcciones antes de tocar una configuración.

Determina qué direcciones debe transportar el perfil

Enumera los destinos en orden: la red de la aplicación, la dirección del resolutor y el punto final público que termina el propio túnel. El tercero nunca debe enrutarse dentro del túnel, porque la conexión exterior necesita una ruta que exista antes que el túnel.

Incluye tanto UDP como TCP para DNS, ya que se espera que las implementaciones admitan TCP además de UDP, y una ruta TCP bloqueada produce fallos lentos y parciales en lugar de limpios. Si la zona privada también se sirve por IPv6, la excepción de host equivalente usa una dirección y un prefijo IPv6 y es una entrada aparte.

Anota qué cubre ya el perfil antes de añadir nada. Una ruta duplicada es inofensiva, pero una ruta existente inesperada te dice que el perfil se diseñó para un plan de direcciones distinto del que te dieron.

Añade la ruta de host a través del propietario de la conexión

En un perfil nativo de Windows administrado localmente, la ruta pertenece a la conexión y no a la tabla de enrutamiento global de la máquina. Previsualiza primero la adición y luego aplícala con el mismo ámbito que usa el perfil.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

El primer comando previsualiza el cambio sin instalar nada, y el segundo enumera las rutas que el perfil lleva ahora. La referencia de Add-VpnConnectionRoute de Microsoft documenta los ámbitos por usuario y para todos los usuarios; un perfil para todos los usuarios necesita su propio parámetro de ámbito, y un comando por usuario contra un perfil para todos los usuarios falla o acaba en el lugar equivocado.

Cuando el perfil se administra o procede de un cliente de proveedor, el cambio pertenece a ese propietario. Apilar una ruta de sistema permanente sobre una directiva de conexión funciona hasta que la directiva se vuelve a aplicar y la ruta desaparece, lo que suele ocurrir durante una llamada de soporte y no durante las pruebas. Ese fallo es silencioso: la ruta desaparece, el nombre deja de resolverse y nadie relaciona los dos hechos. Pon el cambio en el registro propio del propietario para que la siguiente reaplicación lo lleve en lugar de borrarlo.

Después de aplicarlo, vuelve a conectar el perfil en lugar de suponer que la ruta ha surtido efecto. Los cambios de ruta en una conexión activa no siempre se recogen, y volver a conectar también reproduce el estado que tus usuarios tendrán realmente.

Comprueba qué resolutor ha usado realmente el cliente

Una ruta controla los paquetes dirigidos al resolutor. No decide qué nombres deben enviarse allí, y esa selección es un mecanismo aparte. En Windows, las reglas efectivas de espacio de nombres pueden elegir un resolutor por dominio, mientras que la configuración DNS del perfil aporta un valor predeterminado. Esas dos capas pueden discrepar sin producir ningún error, por eso una consulta directa es solo la mitad de la prueba.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

El primer comando imprime la directiva de espacio de nombres vigente, y el segundo pregunta directamente al resolutor privado por el nombre de la aplicación. Una respuesta directa demuestra que la ruta y el resolutor funcionan; no demuestra que la consulta propia de la aplicación haya elegido ese servidor. Compárala con una consulta normal del mismo nombre y con la respuesta que recibe la aplicación.

Ten en cuenta las cachés y el DNS seguro del navegador, que puede saltarse por completo el resolutor del sistema para los nombres que ha escrito un usuario. Un sufijo de búsqueda es otra pista falsa: amplía un nombre corto a uno totalmente cualificado y no tiene nada que ver con qué servidor responde.

Termina volviendo a conectar y repitiendo la consulta normal, y luego confirma que la navegación ordinaria sigue su directiva aprobada. Sustituir el resolutor privado por uno público para que resuelva un nombre no relacionado no es una solución, y traslada en silencio las consultas privadas adonde nunca debieron ir.