Fuga de DNS con VPN en Windows: por qué la métrica gana a la ruta

Una consulta sale del equipo y llega al router de casa mientras cada paquete va por el túnel. La conclusión natural es que falta una ruta, y la ruta suele estar bien. Windows puede elegir qué resolver de interfaz consultar según la métrica, y un adaptador de túnel a menudo pierde esa comparación con el inalámbrico.

Dos explicaciones para una fuga

La explicación por rutas dice que parte del tráfico se escapa del túnel, así que la ruta por defecto o la lista del túnel dividido deben estar mal. Esa explicación se prueba con un solo comando, y cuando la ruta por defecto apunta al túnel ya está resuelta. Compruébela primero porque es barata, y luego déjela de lado cuando vuelva limpia.

La explicación por clasificación dice que el tráfico va del todo por el túnel y que la consulta se sigue enviando a otro resolver. Windows trata la elección de resolver como una propiedad por interfaz con un orden, así que un adaptador físico con mejor métrica puede aportar DNS para un nombre aunque los paquetes de la dirección resuelta viajen por el túnel. Ambas explicaciones producen el mismo síntoma en una página de prueba de fugas, por eso la prueba no es el diagnóstico. Solo una de ellas se repara editando rutas.

Compare métricas y resolvers juntos

Anote las interfaces, sus métricas y sus servidores configurados mientras el túnel está activo. Léalo como una tabla y no como dos listas separadas, porque la pregunta es qué resolver va primero, no qué resolvers existen.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Si el adaptador de túnel lleva un número mayor que el físico, su resolver no es preferente, y un nombre interno irá a lo que ofrezca el lado físico. Ese router puede responder desde la caché, reenviar la consulta o rechazarla, y ninguno de esos desenlaces es el diseño que usted pretendía. La clasificación es una preferencia, así que pierde en silencio en lugar de generar un error.

Un adaptador de túnel sin ningún resolver configurado es una variante igual de habitual. El cliente levanta la interfaz sin empujar DNS, así que la pregunta de la clasificación ni siquiera se plantea.

Suba el túnel en la lista y vuelva a comprobar

Dé a la interfaz del túnel la métrica más baja, o suba el valor del adaptador físico, en un shell elevado. Ambas son ajustes por interfaz y ambas son reversibles, lo que importa cuando cambia un equipo delante del cual quizá no esté.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

El cambio se ve de inmediato, y el cliente DNS y otros consumidores guardan en caché la elección que ya hicieron. Reconecte el túnel, o reinicie, antes de sacar conclusiones de un resultado de consulta. Una prueba hecha demasiado pronto reproducirá el comportamiento antiguo y parecerá una reparación fallida.

Luego consulte un nombre interno y uno público y compruebe qué servidor respondió. La referencia sobre las métricas automáticas de Microsoft explica por qué se prefiere el valor más bajo y cómo se deriva la asignación automática.

Haga que sobreviva a una reconexión

Una métrica manual en un adaptador que se recrea en cada conexión es un ajuste que desaparece. Si el cliente reconstruye la interfaz, la sustitución necesita un script posterior a la conexión, una directiva o una configuración de cliente que posea el DNS mientras dura la conexión.

Los servidores configurados de forma estática en el adaptador físico tienen el mismo problema de durabilidad a la inversa. Siguen respondiendo por esa interfaz hasta que se eliminan, y DHCP los repoblará con el siguiente arrendamiento, así que eliminarlos es una medición y no un diseño. El diseño duradero es una directiva de resolución de nombres para el espacio de nombres interno, o un cliente que asuma el DNS durante la conexión. En cualquier caso, anote la lista de resolvers antes y después de una reconexión, restaure la métrica original cuando termine las pruebas y confirme que ha vuelto el comportamiento anterior.