Servidor DNS incorrecto en la VPN de Windows: métrica, orden de enlace o sufijo

Un cliente de Windows puede tener un túnel que funciona, llevar el resolutor corporativo y seguir enviando los nombres internos al router de casa. Tres mecanismos distintos deciden qué servidor responde, y fallan de maneras diferentes. No hace falta arreglar los tres: el síntoma le dice cuál está en juego. El árbol de decisión de abajo tarda unos minutos y evita el desenlace habitual, en el que un cambio de métrica, una reordenación del registro y una regla NRPT llegan juntos y nadie sabe cuál hizo algo.

Tres mecanismos deciden, y normalmente uno está mal

La métrica de la interfaz ordena los adaptadores para una familia de direcciones. El orden de enlace bajo Tcpip\Linkage es una lista de identificadores de interfaz para toda la máquina que las rutas de código antiguas todavía consultan. La tabla de directivas de resolución de nombres (NRPT) vincula un espacio de nombres a servidores concretos, y la lista de sufijos decide si un nombre corto se expande siquiera. Son independientes, y por eso un resolutor correcto en el adaptador VPN pierde frente a una preferencia obsoleta en otro sitio.

Ninguno de estos mecanismos es el otro extremo del túnel. Si el servidor que empuja la VPN no puede resolver el nombre, cualquier ajuste del lado del cliente es decoración, así que la primera decisión es si el propio resolutor puede responder cuando se le pregunta directamente.

Decisión uno: ¿puede responder el resolutor empujado?

Pregúntele al servidor de forma explícita y compare con una consulta normal. La diferencia entre las respuestas separa un problema de selección de un problema de alcance, y es la bifurcación más rápida aquí:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Si la primera funciona y la segunda falla, el resolutor es accesible y Windows elige mal; vaya a las decisiones de espacio de nombres y orden de abajo. Si la primera también falla, nada en el cliente ayudará: compruebe que UDP y TCP 53 llegan al servidor por el túnel, que ningún cortafuegos del host en el servidor descarta el conjunto, y que los reenviadores propios del servidor están sanos.

Deténgase en esta bifurcación. Aplicar una regla NRPT a un resolutor al que no puede llegar produce el mismo fallo con más configuración que deshacer, y esconde la avería real detrás de una regla que parece autorizada.

Decisión dos: ¿un espacio de nombres o cada consulta?

El alcance decide la herramienta. Cuando solo fallan los nombres corporativos, vincule el espacio de nombres en lugar de reordenar la máquina: una regla NRPT envía ese sufijo al resolutor del túnel y deja todo lo demás en paz. Cuando toda consulta está afectada, el problema es la preferencia global de adaptadores, y la métrica es el punto por donde empezar porque no cambia ningún ajuste del servidor.

Fije la métrica por familia de direcciones, en ambas interfaces, y confirme el orden después:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Sustituya 11 por el ifIndex del adaptador del túnel de la línea anterior; si 11 es el adaptador LAN, el mismo comando baja la ruta equivocada. Subir el adaptador LAN en su lugar llega al mismo orden desde el otro lado: netsh int ip set interface interface="Ethernet" metric=15, y netsh int ipv6 set interface interface="Ethernet" metric=15 para la segunda familia, porque int ip solo toca IPv4.

El orden de enlace es el último recurso y no el primer movimiento. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage contiene una lista Bind de identificadores de dispositivo, y mover el identificador del túnel al frente sí cambia qué adaptador se consulta primero, pero es un valor de registro para toda la máquina sin alcance por espacio de nombres. Expórtelo antes de editar y reconecte el túnel después, para que el orden se aplique en el estado que el cliente espera.

Para un solo espacio de nombres, prefiera el instrumento más estrecho:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Decisión tres: ¿sobrevive el arreglo a una reconexión?

Una métrica que funciona hasta la siguiente reconexión por línea conmutada nunca se guardó. L2TP/IPsec y otros perfiles de conexión se recrean cuando arranca la conexión, así que el valor guardado vive en la entrada de la libreta de teléfonos como IpInterfaceMetric, no solo en la interfaz activa. Algunos entornos automatizan ese campo justo por esto; otros empujan la preferencia desde una directiva de gestión y dejan el extremo en paz.

La caché y el registro son una capa aparte. Ejecutar esto después de que suba el túnel corrige entradas obsoletas y vuelve a registrar al cliente, pero ninguno de los dos reordena un adaptador:

ipconfig /registerdns
ipconfig /flushdns

Hay un interruptor en la misma capa. Desactivar el registro dinámico en el adaptador físico impide que el cliente anuncie su dirección del lado VPN con el nombre equivocado, lo que es una reparación distinta de la actualización de arriba.

IPv6 merece su propia línea en la decisión. Si el adaptador físico tiene una dirección IPv6 global mientras el túnel solo lleva IPv4, Windows puede preferir la ruta sin túnel para la resolución de nombres. Compruebe esa familia por separado, porque una métrica fijada para IPv4 no dice nada de ella:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Desactivar IPv6 en el adaptador LAN elimina esa ruta y el protocolo con ella; un cambio de métrica en la interfaz IPv6, o una regla NRPT para el espacio de nombres corporativo, conserva la familia y corrige la preferencia. Elija la más estrecha, salvo que haya decidido que ese enlace no debe tener IPv6.

Verifique con la fuente nombrada y mantenga un solo propietario

Verifique con herramientas que informen de qué fuente está en vigor, no solo de si una página carga:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Luego separe el filtrado de la selección, porque desde una aplicación parecen idénticos. block-outside-dns de OpenVPN bloquea el puerto 53 en los otros adaptadores; no elige resolutor. Si ahora falla toda consulta, un filtro puede estar bloqueando el único servidor accesible; si el resolutor configurado se ignora, el orden o la regla de espacio de nombres está mal. Cambiar ambos a la vez hace indistinguibles una consulta bloqueada y una consulta ignorada.

Mantenga un solo propietario para la política de DNS: el perfil VPN, una directiva de gestión o una regla NRPT, no dos de ellos. Antes de cerrarlo:

• El resolutor empujado responde cuando se le nombra de forma explícita, y una consulta normal lo usa.
• La regla o la métrica que cambió cubre la familia de direcciones que de verdad lleva las consultas.
• El ajuste sobrevive a una desconexión y reconexión, o lo ha movido al perfil guardado.
• Exactamente un mecanismo es autoritativo, y los demás se dejaron como estaban.

Trate el orden como estado del entorno y no como algo que se termina. Revíselo tras una reconexión y tras una actualización de Windows que toque la pila de red, porque cualquiera de las dos puede volver a poner el adaptador físico por delante.