Perché Windows invia i nomi della VPN a un server DNS che non hai mai configurato

Imposti il server DNS sull'adattatore VPN, ti riconnetti e il nome privato continua ad arrivare dal resolver dell'ufficio che nessuno ha configurato su questo portatile. Il risultato sembra che l'impostazione sia stata ignorata, e in un certo senso lo è stata, perché l'elenco degli adattatori è un insieme di candidati, non una decisione. Windows risolve i nomi tramite un criterio di spazio dei nomi che può indicare un altro server per un suffisso specifico, e quel criterio viene applicato prima che si consideri l'impostazione dell'adattatore. Trovare la regola che ha vinto è un lavoro di cinque minuti quando sai quale tabella leggere.

Cosa hai cambiato e cosa decide davvero

L'indirizzo DNS di un adattatore dice al client dove quell'interfaccia potrebbe inviare le query. La tabella dei criteri di risoluzione dei nomi dice al client dove deve inviare le query per un dato spazio dei nomi, ed è valutata per nome, non per adattatore. Quando una regola corrisponde al suffisso digitato, vengono usati i server della regola e l'elenco degli adattatori smette di contare per quella ricerca.

Per questo due nomi sullo stesso portatile possono seguire percorsi diversi nello stesso momento. Un host sotto il suffisso aziendale segue la sua regola; un nome pubblico segue il percorso predefinito, che di solito significa l'adattatore che risponde per primo.

Come la tabella abbina un nome

Le regole sono indicizzate per spazio dei nomi e vince la corrispondenza più specifica. Una regola per corp.example vale per vpn.corp.example e non vale per example.net. Una regola con lo spazio dei nomi . copre tutto ciò che le altre regole non coprono, il che la rende la voce più pericolosa dell'elenco e quella che vale la pena controllare quando un sito non correlato si risolve attraverso il tunnel.

Una regola può anche portare un commento, un criterio che disabilita la voce e impostazioni di sicurezza che non hanno nulla a che fare con gli indirizzi DNS. Una regola disabilitata resta visibile nella configurazione senza alcun effetto, quindi una voce che sulla carta sembra corretta può restare inerte dopo un cambio di profilo.

Leggi la tabella effettiva, non la lista dei desideri

Regole configurate e regole effettive sono due domande diverse. Get-DnsClientNrptRule elenca ciò che esiste sulla macchina. Get-DnsClientNrptPolicy -Effective mostra ciò che il client applicherà davvero, con i valori uniti da criterio e impostazioni locali.

Confronta il suffisso di quell'output con il nome che stai provando, carattere per carattere. Una regola per corp.example non intercetta un nome che termina con corp.example.com, e un punto finale in un punto e non nell'altro basta a cambiare la corrispondenza.

Senza regole, Windows interroga più di un adattatore

Quando nulla nella tabella rivendica il nome, il client può inviare la query attraverso diverse interfacce e prendere la prima risposta che arriva. Il risultato dipende dal momento: lo stesso nome può risolversi dall'adattatore cablato il lunedì e dal tunnel il martedì, e nulla nella configurazione di nessuno dei due adattatori spiega la differenza.

Esistono due vie d'uscita. Aggiungi una regola per lo spazio dei nomi così la decisione smette di essere una corsa, oppure disattiva il comportamento parallelo tramite il criterio del client DNS e accetta la risoluzione più lenta e deterministica. La prima di solito si adatta meglio a una VPN con tunnel diviso, perché documenta l'intenzione invece di affidarsi all'ordine.

Percorsi che saltano del tutto il resolver

Un browser con DNS sicuro attivo risolve da solo e consegna a Windows solo l'indirizzo, così la tabella delle regole non vede mai il nome. I client costruiti su ambienti con un proprio resolver possono comportarsi allo stesso modo. Quando un nome si risolve in un'applicazione e fallisce in un'altra sulla stessa macchina, confronta i due percorsi di risoluzione prima di toccare il criterio.

Controlla anche se l'app si collega a un indirizzo in cache di una sessione precedente. Clear-DnsClientCache e poi la stessa ricerca dà una risposta più pulita che dedurla da un risultato vecchio.

Prova con il nome che ha fallito

Risolvi il nome host esatto del report, non un dominio pubblico di test di velocità, e annota quale server ha risposto. Poi cambia una cosa: la regola, l'elenco degli adattatori o l'assegnazione del criterio, e ripeti la stessa ricerca dopo una riconnessione, così lo stato applicato viene ricostruito.

Se il nome si risolve e il servizio rifiuta ancora, smetti di modificare il DNS. Il passo utile successivo è l'indirizzo e la rotta verso di esso, perché la risoluzione dei nomi ha già fatto il suo lavoro.