Servidor DNS incorrecto na VPN de Windows: métrica, orde de enlace ou sufixo

Un cliente de Windows pode ter un túnel que funciona, levar o resolutor corporativo e seguir enviando os nomes internos ao router da casa. Tres mecanismos distintos deciden que servidor responde, e fallan de maneiras diferentes. Non fai falta arranxar os tres: o síntoma dille cal está en xogo. A árbore de decisión de abaixo leva uns minutos e evita o desenlace habitual, no que un cambio de métrica, unha reordenación do rexistro e unha regra NRPT chegan xuntos e ninguén sabe cal fixo algo.

Tres mecanismos deciden, e normalmente un está mal

A métrica da interface ordena os adaptadores para unha familia de enderezos. A orde de enlace baixo Tcpip\Linkage é unha lista de identificadores de interface para toda a máquina que as rutas de código antigas aínda consultan. A táboa de políticas de resolución de nomes (NRPT) vincula un espazo de nomes a servidores concretos, e a lista de sufixos decide se un nome curto se expande sequera. Son independentes, e por iso un resolutor correcto no adaptador VPN perde fronte a unha preferencia obsoleta noutro sitio.

Ningún destes mecanismos é o outro extremo do túnel. Se o servidor que empurra a VPN non pode resolver o nome, calquera axuste do lado do cliente é decoración, así que a primeira decisión é se o propio resolutor pode responder cando se lle pregunta directamente.

Decisión unha: pode responder o resolutor empurrado?

Pregúntelle ao servidor de forma explícita e compare cunha consulta normal. A diferenza entre as respostas separa un problema de selección dun problema de alcance, e é a bifurcación máis rápida aquí:

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

Se a primeira funciona e a segunda falla, o resolutor é accesible e Windows escolle mal; vaia ás decisións de espazo de nomes e orde de abaixo. Se a primeira tamén falla, nada no cliente axudará: comprobe que UDP e TCP 53 chegan ao servidor polo túnel, que ningún cortafogos do hóspede no servidor descarta o conxunto, e que os reenviadores propios do servidor están sans.

Déitese nesta bifurcación. Aplicar unha regra NRPT a un resolutor ao que non pode chegar produce o mesmo fallo con máis configuración que desfacer, e esconde a avaría real detrás dunha regra que parece autorizada.

Decisión dúas: un espazo de nomes ou cada consulta?

O alcance decide a ferramenta. Cando só fallan os nomes corporativos, vincule o espazo de nomes en lugar de reordenar a máquina: unha regra NRPT envía ese sufixo ao resolutor do túnel e deixa todo o demais en paz. Cando toda consulta está afectada, o problema é a preferencia global de adaptadores, e a métrica é o punto por onde comezar porque non cambia ningún axuste do servidor.

Fixe a métrica por familia de enderezos, en ambas as interfaces, e confirme a orde despois:

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

Substitúa 11 polo ifIndex do adaptador do túnel da liña anterior; se 11 é o adaptador LAN, o mesmo comando baixa a ruta equivocada. Subir o adaptador LAN no seu lugar chega á mesma orde desde o outro lado: netsh int ip set interface interface="Ethernet" metric=15, e netsh int ipv6 set interface interface="Ethernet" metric=15 para a segunda familia, porque int ip só toca IPv4.

A orde de enlace é o último recurso e non o primeiro movemento. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage contén unha lista Bind de identificadores de dispositivo, e mover o identificador do túnel á fronte si cambia que adaptador se consulta primeiro, pero é un valor de rexistro para toda a máquina sen alcance por espazo de nomes. Expórteo antes de editar e reconecte o túnel despois, para que a orde se aplique no estado que o cliente espera.

Para un só espazo de nomes, prefira o instrumento máis estreito:

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

Decisión tres: sobrevive o arranxo a unha reconexión?

Unha métrica que funciona ata a seguinte reconexión por liña conmutada nunca se gardou. L2TP/IPsec e outros perfís de conexión recréanse cando arranca a conexión, así que o valor gardado vive na entrada da librería de teléfonos como IpInterfaceMetric, non só na interface activa. Algúns contornos automatizan ese campo xusto por isto; outros empurran a preferencia desde unha directiva de xestión e deixan o extremo en paz.

A caché e o rexistro son unha capa aparte. Executar isto despois de que suba o túnel corrixe entradas obsoletas e volve rexistrar o cliente, pero ningún dos dous reordena un adaptador:

ipconfig /registerdns
ipconfig /flushdns

Hai un interruptor na mesma capa. Desactivar o rexistro dinámico no adaptador físico impide que o cliente anuncie o seu enderezo do lado VPN co nome equivocado, o que é unha reparación distinta da actualización de arriba.

IPv6 merece a súa propia liña na decisión. Se o adaptador físico ten un enderezo IPv6 global mentres o túnel só leva IPv4, Windows pode preferir a ruta sen túnel para a resolución de nomes. Comprobe esa familia por separado, porque unha métrica fixada para IPv4 non di nada dela:

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

Desactivar IPv6 no adaptador LAN elimina esa ruta e o protocolo con ela; un cambio de métrica na interface IPv6, ou unha regra NRPT para o espazo de nomes corporativo, conserva a familia e corrixe a preferencia. Escolla a máis estreita, salvo que decidise que esa ligazón non debe ter IPv6.

Verifique coa fonte nomeada e manteña un só propietario

Verifique con ferramentas que informen de que fonte está vixente, non só de se unha páxina carga:

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

Logo separe o filtrado da selección, porque desde unha aplicación parecen idénticos. block-outside-dns de OpenVPN bloquea o porto 53 nos outros adaptadores; non escolle resolutor. Se agora falla toda consulta, un filtro pode estar bloqueando o único servidor accesible; se o resolutor configurado se ignora, a orde ou a regra de espazo de nomes está mal. Cambiar ambos á vez fai indistinguibles unha consulta bloqueada e unha consulta ignorada.

Manteña un só propietario para a política de DNS: o perfil VPN, unha directiva de xestión ou unha regra NRPT, non dúas delas. Antes de pechalo:

• O resolutor empurrado responde cando se lle nomea de forma explícita, e unha consulta normal úsao.
• A regra ou a métrica que cambiou cobre a familia de enderezos que de verdade leva as consultas.
• O axuste sobrevive a unha desconexión e reconexión, ou moveuno ao perfil gardado.
• Exactamente un mecanismo é autoritativo, e os demais deixáronse como estaban.

Trate a orde como estado do contorno e non como algo que se termina. Revísea tras unha reconexión e tras unha actualización de Windows que toque a pila de rede, porque calquera das dúas pode volver pór o adaptador físico por diante.