Perché il DNS smette di funzionare dopo la connessione di OpenVPN su Windows

Un ping al resolver dell’ufficio risponde ancora dopo che "OpenVPN" si connette, eppure ogni ricerca di nome fallisce. L’indirizzo è raggiungibile mentre la porta non lo è, una combinazione che ha senso quando si sa che Windows può filtrare il DNS per adattatore. Con block-outside-dns nel profilo, quel filtro è il primo sospetto e la tabella di routing è il posto sbagliato dove guardare. I due test qui sotto separano i livelli in pochi secondi.

Indirizzo raggiungibile, porta morta

Un ping riuscito dimostra che l’host è attivo e che esiste un percorso. Non dice nulla sul permesso di raggiungere la porta 53, perché il filtro in questione lavora a un altro livello e dipende dall’adattatore. Per questo la stessa macchina può rispondere a ICMP e rifiutare ogni richiesta inviata allo stesso indirizzo. Eseguite entrambi i test nella stessa sessione prima di modificare qualsiasi configurazione.

ping <resolver-ip>
nslookup <name> <resolver-ip>

La coppia è la diagnosi. Il traffico ordinario verso la sottorete continua a funzionare mentre la risoluzione dei nomi muore, e si conclude che il server è guasto o che il DNS non è mai stato inviato. Entrambe le spiegazioni costano care da inseguire, e le prove indicano qualcosa di più ristretto. Confermate la coppia prima di toccare un’impostazione.

L’opzione è una regola della piattaforma di filtraggio

La documentazione di OpenVPN descrive block-outside-dns come una restrizione di Windows Filtering Platform che impedisce alle applicazioni di raggiungere il DNS sugli adattatori fuori dal tunnel. Copre TCP e UDP sulla porta 53. Poiché il filtro vive in WFP e non nell’elenco abituale delle regole del firewall, aggiungere una regola di autorizzazione altrove non cambia necessariamente il risultato. Per questo il consiglio comune di consentire il DNS continua a fallire.

L’impostazione può arrivare dal profilo importato o dal server, e il file che avete modificato per ultimo "non è prova di ciò che il client ha caricato". Leggete insieme la configurazione effettiva e il registro di connessione. L’opzione è anche specifica di Windows, e trattarla come portabile produce consigli che non si applicano.

Cercate il componente client che possiede la restrizione invece di aggiungere regole. Il proprietario è ciò che può davvero rimuoverla.

Un filtro non è un resolver

Bloccare il traffico fuori dal tunnel non installa un resolver funzionante al suo interno. L’opzione rimuove un percorso e lascia la configurazione DNS del tunnel a chi ha impostato il profilo. Un profilo che non ha mai inviato un resolver ora non ne ha nessuno.

Passate attraverso tre controlli in ordine. Primo, quale resolver usa davvero l’applicazione che fallisce. Secondo, se il client ha applicato le impostazioni DNS della VPN. Terzo, quale interfaccia trasporta il traffico verso quel resolver.

1. Resolver in uso: confrontate Resolve-DnsName -Server <resolver-ip> <name> con i server DNS elencati da ipconfig /all.
2. DNS della VPN applicato: esaminate le voci DNS dell’adattatore del tunnel nella stessa uscita di ipconfig /all.
3. Interfaccia usata: Find-NetRoute -RemoteIPAddress <resolver-ip> indica l’interfaccia di uscita per quella destinazione.

Un resolver di LAN diventa irraggiungibile per progetto con questa politica, anche mentre altro traffico LAN funziona. È l’opzione che fa il suo lavoro. Se il progetto richiede il DNS via VPN, correggete la registrazione del resolver e il percorso del tunnel; se serve uno split DNS con eccezioni locali, il proprietario della configurazione deve esprimere quelle eccezioni in modo supportato.

Cosa l’opzione non copre

La porta 53 non è tutta la risoluzione dei nomi. DNS over HTTPS e DNS over TLS usano trasporti diversi, e alcune applicazioni eseguono una propria logica di resolver indipendentemente dalle impostazioni di sistema. Un browser può quindi risolvere nomi mentre la riga di comando non può.

Trattate questa differenza come una diagnosi e non come una contraddizione. Confrontate le due cose prima di decidere che il resolver di sistema è guasto.

Mantenete la conclusione stretta quando la scrivete. Questa opzione vincola un trasporto su una piattaforma, e il resto del percorso di risoluzione è una questione di progetto separata con il proprio proprietario.

Controllate lo stato prima e dopo la disconnessione

Eseguite la stessa ricerca durante la connessione e di nuovo dopo che il client proprietario si disconnette. La prima dovrebbe fallire per un resolver esterno mentre il tunnel è attivo, e la seconda dovrebbe riuscire quando il filtro è rimosso. Se fallisce ancora dopo la disconnessione, il filtro non è stato ripulito.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Riavviare il servizio client o la macchina di solito ripulisce un filtro obsoleto. Questo conferma la diagnosi senza dimostrare una correzione permanente. Annotate ciò che avete visto, perché un filtro che sopravvive a una disconnessione lo farà di nuovo, e l’annotazione è ciò che giustifica una segnalazione di bug.

Solo dopo questi controlli ha senso sostituire il resolver o ricostruire la politica del firewall. Entrambe sono modifiche più grandi di quanto le prove sostengano.