DNS inviato da OpenVPN ignorato: quale componente lo applica

Il registro mostra l’opzione inviata dal server, il tunnel è attivo e i nomi interni continuano a fallire. Una query diretta al resolver risponde, quindi il server è a posto, ma ogni applicazione continua a chiedere al router locale. Quello che è arrivato al client è un’offerta, non una modifica al resolver, e il componente che possiede la risoluzione dei nomi cambia su Linux, Windows e macOS. Appena separate l’opzione dal suo proprietario, quattro guasti coprono quasi ogni segnalazione: nessun hook, due hook in competizione, DNS diviso che funziona come previsto, o un nome breve che richiede un suffisso e non un server.

Un’opzione inviata è un’offerta, non un’installazione

Sul server, due direttive descrivono l’intento, non l’effetto:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Il client non riceve un resolver configurato. Riceve variabili d’ambiente, foreign_option_1 e successive, una per ogni riga inviata, e qualcosa di locale deve leggerle e riscrivere lo stato del resolver del sistema operativo. Su Linux nulla lo fa per impostazione predefinita, perciò un server corretto e un client connesso possono ancora risolvere tramite la LAN.

Tre fasi stanno tra i due estremi: il push deve viaggiare, il client deve esporlo e un hook deve applicarlo. Leggete la fase intermedia nel registro del client e l’ultima nello stato del resolver, mai il contrario, perché una riga di registro prova solo le prime due.

Confermate che il push è arrivato e trovate il proprietario

Iniziate nominando l’avviatore: un comando openvpn nudo, un’istanza systemd, NetworkManager o un client del fornitore. Questo decide dove può vivere un hook. Su un host con systemd-resolved, resolvectl status elenca ogni collegamento con i server DNS e i domini di ricerca che usa davvero, e il collegamento del tunnel non sempre si chiama tun0.

Se l’indirizzo inviato compare nel registro ma su nessun collegamento, manca l’integrazione. Se compare sul collegamento e le query escono ancora altrove, il problema è quali query selezionano quel collegamento. NetworkManager dns=dnsmasq nel file /etc/NetworkManager/NetworkManager.conf esegue un inoltro locale che implementa il DNS diviso di proposito: i nomi nel dominio VPN vanno al resolver VPN, tutto il resto mantiene il percorso precedente. Questo comportamento sembra un guasto quando vi aspettavate che si spostasse tutto il traffico; controllate le impostazioni per connessione con nmcli connection show "My VPN", dove ipv4.dns e ipv4.dns-search conservano i valori dietro ciò che il dispositivo riporta, prima di definirlo rotto. Se ogni query deve davvero raggiungere il resolver VPN, rimuovete dns=dnsmasq da NetworkManager.conf e riavviate NetworkManager, che restituisce la risoluzione alle impostazioni della connessione; altrimenti mantenete il DNS diviso e correggete l’elenco dei domini inviati.

Linux: consegnate le opzioni al resolver

I pacchetti delle distribuzioni includono un hook per questo, e al client deve essere permesso eseguirlo. Una disposizione tipica su un host senza systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Con systemd-resolved lo script resolv.conf più vecchio può non cambiare nulla di importante, perché il resolver stub mantiene lo stato per collegamento. update-systemd-resolved l’helper documenta una forma di hook che usa up-restart e down-pre, cosa che conta quando un’interfaccia sopravvive a un solo tentativo di connessione. Qualunque cosa scegliate, un componente deve possedere lo stato. Aggiungere un hook estraneo accanto a NetworkManager dà due scrittori allo stesso collegamento, e il risultato dipende allora dall’ordine e non dalla vostra configurazione.

Esiste anche il caso in cui NetworkManager ha ignorato del tutto l’opzione inviata finché l’indirizzo del server non è stato inserito nelle impostazioni IPv4 della connessione, dopodiché lo stato del resolver l’ha mostrata in uso. Vale la pena provarlo prima di riscrivere script, perché sposta il problema da un hook di shell al profilo di connessione che già porta il tunnel.

Windows e macOS applicano parti diverse

Il client Windows imposta davvero i server DNS dell’adattatore VPN, ma Windows sceglie ancora l’interfaccia per metrica e ha ancora bisogno di un suffisso per espandere un nome breve. Verificate lo stato dell’adattatore e non il profilo:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Se l’indirizzo manca, impostatelo con Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, poi aggiungete il suffisso alle proprietà IPv4 dell’adattatore perché fileserver diventi fileserver.corp.example. Un valore SearchList a livello di macchina sotto Tcpip\Parameters fa lo stesso. Dove il nome lungo si risolve e quello nudo no, il resolver è già corretto e la colpa è dell’elenco di ricerca. Le correzioni, in ordine: inviate un DOMAIN perché il client impari il suffisso, aggiungete quel suffisso all’elenco di ricerca dell’adattatore o della connessione, e come misura temporanea fissate il nome in hosts, o in LMHOSTS su Windows; la navigazione NetBIOS non attraversa un router, quindi il broadcast che trova un nome breve sulla LAN dell’ufficio non raggiunge mai un client del tunnel.

block-outside-dns block-outside-dns è un comportamento del client Windows, non una riga di profilo portabile, e copiarlo in un profilo Linux o macOS non lo riproduce lì. Se i nomi pubblici funzionano e gli interni falliscono su Windows, confrontate l’ordine degli adattatori in Impostazioni avanzate con ipconfig /all. Su macOS l’ordine dei resolver per servizio appartiene al sistema, quindi usate scutil --dns per vedere quale resolver viene interrogato per quale dominio, e trattate ogni singola correzione di profilo segnalata come dipendente dal client e non generale.

Una macchina virtuale sullo stesso portatile non eredita nulla di questo. Date all’ospite la sua voce di resolver per il dominio interno, oppure lasciate che il NAT dell’hypervisor inoltri le sue query attraverso l’host, cosa corretta solo finché il tunnel dell’host è attivo.

La cronologia è la terza causa. Server DNS o impostazioni del suffisso di un profilo precedente possono sopravvivere alle riconnessioni, quindi quando l’adattatore sembra corretto e le ricerche falliscono ancora, confrontate l’adattatore attivo con Get-VpnConnection e cancellate o sovrascrivete la voce obsoleta prima di toccare il server.

Dimostrate dove è andata la query

Una cattura durante una ricerca chiude la discussione: tcpdump -ni eth0 port 53 mostra query sull’interfaccia fisica, il che significa che escono fuori dal tunnel e che il resolver non è mai stato cambiato. dig @10.8.0.1 name.corp.example poi separa i due casi rimanenti. Se la query diretta risponde, il resolver funziona e il client non lo usa; se scade, il resolver è irraggiungibile attraverso il tunnel e nessun cambiamento locale aiuterà.

Se il resolver ancora in uso è quello distribuito dal fornitore, il tunnel cifra il traffico mentre i nomi restano visibili a quel fornitore. È una questione di fuga e non di funzionamento, e la stessa cattura la risolve: una query sull’interfaccia fisica va a qualcuno fuori dal tunnel.

La raggiungibilità include il firewall dell’host VPN, che deve consentire UDP e TCP 53 dal pool. Una porta bloccata sembra esattamente un push rotto, e così pure un resolver che risponde solo dall’interno della rete del tunnel. Ripetete la cattura dopo una disconnessione e riconnessione, perché impostazioni che compaiono alla prima connessione e svaniscono alla seconda sono un guasto del ciclo di vita nell’hook, non un’opzione assente.

Mantenete un solo proprietario e verificate in ordine

Uno script che riscrive il DNS dell’adattatore in base a uno stato del tunnel supposto duplica una configurazione che il profilo già porta, e fallisce in silenzio la prima volta che la supposizione è sbagliata. Preferite le impostazioni DNS della connessione stessa o un solo hook documentato, e annotate quale avete scelto perché la persona successiva non ne aggiunga un secondo.

Chiudete il ciclo con quattro controlli: l’indirizzo inviato presente sul collegamento del tunnel, il nome interno risolto come nome pienamente qualificato, lo stesso nome risolto senza suffisso, ed entrambi ancora veri dopo una riconnessione. Una cattura vi dice quale dei quattro ha fallito. Il manuale di OpenVPN 2.6 elenca dhcp-option e le direttive di script con le loro note di piattaforma.