Server DNS sbagliato nella VPN di Windows: metrica, ordine di binding o suffisso

Un client Windows può avere un tunnel funzionante, portare il resolver aziendale e comunque inviare i nomi interni al router di casa. Tre meccanismi diversi decidono quale server risponde, e falliscono in modi diversi. Non è necessario correggerli tutti e tre: il sintomo ti dice quale è in gioco. L’albero decisionale qui sotto richiede qualche minuto e impedisce l’esito abituale, in cui una modifica della metrica, un riordino del registro e una regola NRPT arrivano insieme e nessuno sa quale abbia fatto qualcosa.

Tre meccanismi decidono, e di solito uno è sbagliato

La metrica dell’interfaccia ordina gli adattatori per una determinata famiglia di indirizzi. L’ordine di binding sotto Tcpip\Linkage è un elenco di identificatori di interfaccia valido per l’intera macchina che i percorsi di codice più vecchi consultano ancora. La tabella dei criteri di risoluzione dei nomi (NRPT) lega uno spazio dei nomi a server specifici, e l’elenco dei suffissi decide se un nome breve viene espanso. Sono indipendenti, ed è per questo che un resolver corretto sull’adattatore VPN perde contro una preferenza obsoleta altrove.

Nessuno di questi meccanismi è l’altro capo del tunnel. Se il server che la VPN spinge non riesce a risolvere il nome, ogni impostazione lato client è solo decorazione, quindi la prima decisione è se il resolver stesso può rispondere quando lo si interroga direttamente.

Decisione uno: il resolver spinto può rispondere?

Interroga il server in modo esplicito e confronta con una ricerca ordinaria. Il divario tra le risposte separa un problema di scelta da un problema di raggiungibilità, ed è la biforcazione più rapida qui:

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

Se la prima riesce e la seconda fallisce, il resolver è raggiungibile e Windows sceglie male; passa alle decisioni su spazio dei nomi e ordine qui sotto. Se fallisce anche la prima, nulla sul client aiuterà: verifica che UDP e TCP 53 raggiungano il server attraverso il tunnel, che nessun firewall dell’host sul server scarti il pool e che i forwarder del server stesso siano sani.

Fermati a questa biforcazione. Applicare una regola NRPT a un resolver che non puoi raggiungere produce lo stesso guasto con più configurazione da disfare, e nasconde il guasto reale dietro una regola che sembra autorevole.

Decisione due: uno spazio dei nomi o ogni query?

L’ambito decide lo strumento. Quando falliscono solo i nomi aziendali, lega lo spazio dei nomi invece di riordinare la macchina: una regola NRPT invia quel suffisso al resolver del tunnel e lascia tutto il resto in pace. Quando ogni ricerca è coinvolta, il problema è la preferenza globale degli adattatori, e la metrica è il punto da cui partire perché non cambia alcuna impostazione del server.

Imposta la metrica per famiglia di indirizzi, su entrambe le interfacce, e conferma poi l’ordine:

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

Sostituisci 11 con l’ifIndex dell’adattatore del tunnel dalla riga sopra; se 11 è l’adattatore LAN, lo stesso comando abbassa il percorso sbagliato. Alzare invece l’adattatore LAN raggiunge lo stesso ordine dall’altro lato: netsh int ip set interface interface="Ethernet" metric=15, e netsh int ipv6 set interface interface="Ethernet" metric=15 per la seconda famiglia, perché int ip tocca solo IPv4.

L’ordine di binding è l’ultima risorsa e non il primo passo. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage contiene un elenco Bind di identificatori di dispositivo, e spostare l’identificatore del tunnel in testa cambia davvero quale adattatore viene interrogato per primo, ma è un valore di registro valido per l’intera macchina senza ambito per spazio dei nomi. Esportalo prima di modificare e riconnetti il tunnel dopo, così l’ordine vale nello stato che il client si aspetta.

Per un solo spazio dei nomi, preferisci lo strumento più stretto:

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

Decisione tre: la correzione sopravvive a una riconnessione?

Una metrica che regge fino alla prossima riconnessione su linea commutata non è mai stata salvata. L2TP/IPsec e gli altri profili di connessione vengono ricreati all’avvio della connessione, quindi il valore salvato vive nella voce della rubrica telefonica come IpInterfaceMetric, non solo sull’interfaccia attiva. Alcuni ambienti mettono in script quel campo proprio per questo; altri spingono la preferenza da un criterio di gestione e lasciano in pace l’endpoint.

Cache e registrazione sono uno strato separato. Eseguirle dopo che il tunnel è salito corregge le voci obsolete e registra di nuovo il client, ma nessuna delle due riordina un adattatore:

ipconfig /registerdns
ipconfig /flushdns

C’è un interruttore nello stesso strato. Disattivare la registrazione dinamica sull’adattatore fisico impedisce al client di annunciare il proprio indirizzo lato VPN con il nome sbagliato, ed è una riparazione diversa dall’aggiornamento qui sopra.

IPv6 merita una riga propria nella decisione. Se l’adattatore fisico ha un indirizzo IPv6 globale mentre il tunnel trasporta solo IPv4, Windows può preferire il percorso non incapsulato per la risoluzione dei nomi. Controlla quella famiglia separatamente, perché una metrica impostata per IPv4 non dice nulla su di essa:

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

Disattivare IPv6 sull’adattatore LAN elimina quel percorso e il protocollo con esso; una modifica della metrica sull’interfaccia IPv6, o una regola NRPT per lo spazio dei nomi aziendale, conserva la famiglia e corregge la preferenza. Scegli la più stretta, a meno che tu non abbia deciso che quel collegamento non debba avere IPv6.

Verifica con la fonte nominata e mantieni un solo proprietario

Verifica con strumenti che riportino quale fonte è in vigore, non solo se una pagina si carica:

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

Poi separa il filtraggio dalla selezione, perché da un’applicazione sembrano identici. block-outside-dns di OpenVPN blocca la porta 53 sugli altri adattatori; non sceglie un resolver. Se ora ogni query fallisce, un filtro potrebbe bloccare l’unico server raggiungibile; se il resolver configurato viene ignorato, l’ordine o la regola dello spazio dei nomi è sbagliato. Cambiare entrambi insieme rende indistinguibili una query bloccata e una query ignorata.

Mantieni un solo proprietario per i criteri DNS: il profilo VPN, un criterio di gestione o una regola NRPT, non due di essi. Prima di chiudere:

• Il resolver spinto risponde quando viene nominato esplicitamente, e una ricerca ordinaria lo usa.
• La regola o la metrica che hai cambiato copre la famiglia di indirizzi che porta davvero le query.
• L’impostazione sopravvive a una disconnessione e riconnessione, oppure l’hai spostata nel profilo salvato.
• Esattamente un meccanismo fa fede, e gli altri sono stati lasciati come stavano.

Tratta l’ordine come stato dell’ambiente e non come una cosa che si conclude. Ricontrollalo dopo una riconnessione e dopo un aggiornamento di Windows che tocca lo stack di rete, perché l’uno o l’altro può rimettere l’adattatore fisico davanti.