Servidor DNS equivocat a la VPN de Windows: mètrica, ordre d’enllaç o sufix

Un client de Windows pot tenir un túnel que funciona, portar el resolutor corporatiu i, tot i així, enviar els noms interns al router de casa. Tres mecanismes diferents decideixen quin servidor respon, i fallen de maneres diferents. No cal arreglar-los tots tres: el símptoma et diu quin està en joc. L’arbre de decisió de sota triga uns minuts i evita el desenllaç habitual, en què un canvi de mètrica, una reordenació del registre i una regla NRPT arriben alhora i ningú no sap quin ha fet res.

Tres mecanismes decideixen, i normalment un està malament

La mètrica de la interfície ordena els adaptadors per a una família d’adreces. L’ordre d’enllaç sota Tcpip\Linkage és una llista d’identificadors d’interfície per a tot l’equip que els camins de codi antics encara consulten. La taula de polítiques de resolució de noms (NRPT) lliga un espai de noms a servidors concrets, i la llista de sufixos decideix si un nom curt s’amplia o no. Són independents, i per això un resolutor correcte a l’adaptador VPN perd contra una preferència antiquada en un altre lloc.

Cap d’aquests mecanismes no és l’altre costat del túnel. Si el servidor que empeny la VPN no pot resoldre el nom, qualsevol ajust del costat del client és decoració, així que la primera decisió és si el resolutor mateix pot respondre quan se li pregunta directament.

Decisió primera: pot respondre, el resolutor empès?

Pregunta-ho explícitament al servidor i compara-ho amb una consulta normal. La diferència entre les respostes separa un problema de selecció d’un problema d’abast, i és la bifurcació 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 i la segona falla, el resolutor és abastable i Windows tria malament; ves a les decisions d’espai de noms i d’ordre de sota. Si la primera també falla, res del client no ajudarà: comprova que UDP i TCP 53 arribin al servidor a través del túnel, que cap tallafoc de l’amfitrió al servidor no descarti el conjunt, i que els reenviadors propis del servidor estiguin sans.

Atura’t en aquesta bifurcació. Aplicar una regla NRPT a un resolutor que no pots abastar produeix la mateixa fallada amb més configuració per desfer, i amaga la fallada real darrere d’una regla que sembla autoritativa.

Decisió segona: un espai de noms o cada consulta?

L’abast decideix l’eina. Quan només fallen els noms corporatius, lliga l’espai de noms en lloc de reordenar l’equip: una regla NRPT envia aquest sufix al resolutor del túnel i deixa la resta tranquil·la. Quan cada consulta queda afectada, el problema és la preferència global d’adaptadors, i la mètrica és el lloc per començar perquè no canvia cap ajust del servidor.

Defineix la mètrica per família d’adreces, a les dues interfícies, i confirma l’ordre despré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

Substitueix 11 per l’ifIndex de l’adaptador del túnel de la línia de dalt; si 11 és l’adaptador LAN, la mateixa ordre baixa el camí equivocat. Pujar l’adaptador LAN arriba al mateix ordre des de l’altre costat: netsh int ip set interface interface="Ethernet" metric=15, i netsh int ipv6 set interface interface="Ethernet" metric=15 per a la segona família, perquè int ip només toca IPv4.

L’ordre d’enllaç és l’últim recurs i no el primer moviment. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage conté una llista Bind d’identificadors de dispositiu, i moure l’identificador del túnel al davant sí que canvia quin adaptador es pregunta primer, però és un valor de registre per a tot l’equip sense abast per espai de noms. Exporta’l abans d’editar-lo i torna a connectar el túnel després, perquè l’ordre s’apliqui en l’estat que el client espera.

Per a un sol espai de noms, prefereix l’instrument més estret:

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

Decisió tercera: sobreviu l’arranjament a una reconnexió?

Una mètrica que funciona fins a la propera reconnexió per línia commutada no s’havia desat mai. L2TP/IPsec i altres perfils de connexió es tornen a crear quan arrenca la connexió, així que el valor desat viu a l’entrada de la llibreta de telèfons com a IpInterfaceMetric, no només a la interfície viva. Alguns entorns posen aquell camp en scripts exactament per aquest motiu; d’altres empenyen la preferència des d’una política de gestió i deixen l’extrem tranquil.

La memòria cau i el registre són una capa a part. Executar-ho després que el túnel pugi arregla entrades antiquades i torna a registrar el client, però cap de les dues coses reordena un adaptador:

ipconfig /registerdns
ipconfig /flushdns

Hi ha un interruptor a la mateixa capa. Desactivar el registre dinàmic a l’adaptador físic evita que el client anunciï la seva adreça del costat VPN amb el nom equivocat, cosa que és una reparació diferent de l’actualització de dalt.

IPv6 mereix la seva pròpia línia a la decisió. Si l’adaptador físic té una adreça IPv6 global mentre el túnel només porta IPv4, Windows pot preferir el camí sense túnel per a la resolució de noms. Comprova aquella família per separat, perquè una mètrica posada per a IPv4 no en diu res:

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

Desactivar IPv6 a l’adaptador LAN elimina aquell camí i el protocol amb ell; un canvi de mètrica a la interfície IPv6, o una regla NRPT per a l’espai de noms corporatiu, manté la família i arregla la preferència. Tria la més estreta, tret que hagis decidit que aquell enllaç no ha de tenir IPv6.

Verifica amb la font anomenada, i mantingues un sol propietari

Verifica amb eines que informin de quina font està en vigor, no només si una pàgina carrega:

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

Després separa el filtratge de la selecció, perquè des d’una aplicació semblen idèntics. block-outside-dns d’OpenVPN bloqueja el port 53 als altres adaptadors; no tria cap resolutor. Si ara tota consulta falla, un filtre pot estar bloquejant l’únic servidor abastable; si el resolutor configurat s’ignora, l’ordre o la regla d’espai de noms està malament. Canviar les dues coses alhora fa que una consulta bloquejada i una consulta ignorada siguin indistingibles.

Mantingues un sol propietari per a la política de DNS: el perfil VPN, una política de gestió o una regla NRPT, no dues coses. Abans de tancar-ho:

• El resolutor empès respon quan se l’anomena explícitament, i una consulta normal l’utilitza.
• La regla o la mètrica que has canviat cobreix la família d’adreces que de fet porta les consultes.
• L’ajust sobreviu a una desconnexió i reconnexió, o l’has mogut al perfil desat.
• Exactament un mecanisme és autoritatiu, i els altres s’han deixat com estaven.

Tracta l’ordre com a estat de l’entorn i no com una cosa que s’acaba. Torna’l a comprovar després d’una reconnexió i després d’una actualització de Windows que toqui la pila de xarxa, perquè qualsevol de les dues pot tornar a posar l’adaptador físic al davant.