OpenVPN spinge DNS, ma il tuo resolver potrebbe non vederlo mai

Il log del client mostra il server DNS spinto, il tunnel è connesso e un nome interno continua a non risolversi. Nulla è rotto nell’invio stesso. L’opzione è arrivata e il resolver del sistema operativo non l’ha mai usata, perché sulla maggior parte dei client Unix OpenVPN consegna il valore e lascia l’applicazione alla piattaforma.

Il sintomo: il log mostra DNS e i nomi continuano a fallire

OpenVPN dhcp-option trasporta informazioni DNS e di dominio, e il client registra ciò che ha ricevuto. In alcune implementazioni il client applica quelle impostazioni internamente; in altre le esporta perché uno script di integrazione o un servizio di rete le consumi. La riga del log descrive solo la prima metà della storia. La seconda metà avviene in un punto che il client non controlla. È lì che di solito vive il guasto.

Per questo un tunnel connesso e un nome interno che fallisce convivono così spesso. Il valore c’è, il consumatore manca o è configurato male, e il resolver continua silenziosamente a usare il server pubblico che usava prima della connessione.

Ricevuto non è applicato

Un client può registrare un valore DNS spinto mentre il resolver di sistema resta di proprietà di un altro servizio. Un browser può anche avere una propria politica di DNS cifrato che aggira del tutto il resolver di sistema, il che produce la memorabile situazione in cui un’applicazione risolve nomi interni e un’altra no.

Controlla l’integrazione supportata dall’implementazione invece di dare per scontato che ogni client Unix riscriva lo stesso file. È questo presupposto il motivo per cui le persone modificano una configurazione del resolver che nessuno legge.

Trova il proprietario del resolver per piattaforma

Su Windows, la tabella dei criteri di risoluzione dei nomi può indirizzare suffissi specifici verso server specifici, e il client VPN può installarvi regole. Controlla il criterio, non solo l’elenco DNS dell’adattatore. Su Linux, NetworkManager o systemd-resolved possono possedere la configurazione, e quale dei due la possiede determina cosa conserverà una riconnessione.

Leggi lo stato effettivo con lo strumento che risponde davvero alle query: resolvectl query internal.example.net su un host con systemd-resolved, o l’equivalente della piattaforma. Poi confronta quella risposta con il server DNS che il log del client dichiara di aver spinto.

Evita di eseguire più servizi che sovrascrivono le impostazioni del resolver senza coordinamento. Due proprietari producono un risultato che sembra intermittente, e ogni riconnessione sembra ripararlo o romperlo a caso.

Script e foreign_option

OpenVPN esporta le opzioni spinte verso gli script tramite variabili chiamate foreign_option_N, e uno script può tradurle in comandi del resolver. Questa disposizione è un’integrazione supportata, non un comportamento automatico, e deve essere installata e richiamata sul client.

Se dipendi da uno script, registra la sua esecuzione e il suo stato di uscita. Uno script che viene eseguito ma fallisce silenziosamente lascia lo stesso sintomo di nessuno script, ed è più difficile da notare perché la configurazione sembra completa. Controlla l’output dello script, non il file dello script. Un file che esiste non è uno script che ha girato.

Prova il nome, non il log

Interroga un nome host solo interno dal client dopo la connessione, poi interroga un nome pubblico, poi controlla quale server ha risposto. In una configurazione funzionante le due risposte arrivano da luoghi diversi, e entrambe dovrebbero corrispondere al progetto.

Se il nome si risolve ma il servizio fallisce, passa a instradamento e accesso alle applicazioni invece di cambiare di nuovo il DNS. Il manuale di OpenVPN documenta dhcp-option e l’ambiente degli script; usalo per confermare cosa ci si aspetta che applichi il tuo client prima di modificare un altro file del resolver.