OpenVPN ha inviato un server DNS, ma Linux lo ignora

Il server DNS inviato è nel registro, il tunnel è attivo e i nomi interni continuano a fallire. Nulla è rotto nell’invio stesso; l’impostazione è arrivata e si è fermata lì. Un’opzione DNS inviata è un messaggio al client, non un’istruzione al resolver del sistema operativo, e la consegna tra i due è dove termina la maggior parte di questi casi. Cinque controlli, in ordine, trovano la consegna che non è avvenuta.

Controllo uno: come inizia la connessione

Il proprietario della connessione determina chi può applicare le impostazioni del resolver. Un comando openvpn diretto da una shell non possiede nulla oltre al proprio processo, mentre un’unità systemd, NetworkManager o un client del fornitore hanno ciascuno il proprio modo di pubblicare il DNS. Leggete l’elenco dei processi e il nome dell’unità prima di darne per scontato uno.

Un processo da riga di comando non è automaticamente una connessione NetworkManager, e una connessione NetworkManager non è automaticamente ciò che ha scritto resolv.conf. Queste due supposizioni spiegano la maggior parte delle ore perse in questa indagine. Chiedetevi quale componente pubblicherebbe il DNS per l’interfaccia che vedete davvero.

Annotate il proprietario prima di continuare. Ogni controllo successivo dipende da lui.

Controllo due: cosa contiene davvero il collegamento del resolver

Su un host con systemd-resolved, resolvectl status elenca ogni collegamento con i suoi server DNS e i suoi domini. Trovate il collegamento del tunnel e leggete le sue voci, e non date per scontato che l’interfaccia si chiami tun0, perché la numerazione segue l’ordine di creazione. Se l’indirizzo inviato manca dal collegamento, è fallita la consegna, non la query.

Se l’indirizzo è presente, la domanda successiva è quali domini rivendichi quel collegamento. Un collegamento senza elenco di domini risponde solo ai nomi interrogati direttamente, e raramente è ciò che vuole un dispiegamento split-DNS. L’indirizzo da solo è necessario ma non sufficiente.

Confrontate il nome del collegamento nell’output del resolver con il nome dell’interfaccia nel registro del VPN prima di trarre qualsiasi conclusione. Una discrepanza lì di solito significa che la riga del registro è arrivata da un altro processo.

Controllo tre: se lo spazio dei nomi sceglie quel collegamento

Un resolver può avere il server giusto e comunque non essere consultato. Il dominio per collegamento decide quali query vanno a quale collegamento, e senza un dominio di instradamento lo spazio dei nomi privato ricade su ciò che dice il collegamento predefinito. Per questo resolvectl query può riuscire per il nome interno mentre un’applicazione continua a fallire. L’applicazione potrebbe usare un percorso del resolver del tutto diverso.

Controllate l’assegnazione del dominio, non solo l’indirizzo del server. Un dominio scritto come ~corp.example è un dominio di instradamento, e la tilde cambia il modo in cui il nome viene abbinato.

Se l’applicazione ha il proprio resolver, provate con lo stesso meccanismo che usa lei invece che con lo strumento di sistema. Uno strumento di interrogazione che aggira il resolver di sistema riuscirà indipendentemente dallo stato del collegamento.

Controllo quattro: un proprietario, non due

Se NetworkManager gestisce già il VPN e lo stato del resolver, aggiungere uno script hook non correlato crea scrittori concorrenti. L’hook fornito dal pacchetto per systemd-resolved è un’integrazione supportata e si aspetta un ciclo di vita preciso: script-security 2, un percorso up, up-restart, un percorso down e down-pre. Queste opzioni fanno sì che registrazione e rimozione avvengano nei momenti giusti e non solo alla prima connessione.

Usate il percorso installato dal pacchetto invece di uno illustrativo copiato da una guida. Anche i permessi contano, perché l’hook viene eseguito dopo la riduzione dei privilegi.

Modificare uno script del resolver della distribuzione per cambiare la sua destinazione di output registra un aggiramento valido per un solo host. Non è una riparazione generale.

Controllo cinque: lo stesso risultato dopo una riconnessione

Riconnettetevi e rileggete il collegamento. Una registrazione che appare una volta e scompare alla transizione successiva è il guasto per cui esiste tutta questa lista di controllo. Provate dopo una sospensione, dopo una riconnessione forzata e dopo un riavvio del servizio del resolver. Ogni transizione mette alla prova una diversa ipotesi sull’ordine.

Solo quando tutti e cinque i controlli passano a una riconnessione potete dire che le impostazioni inviate sono in uso. Qualunque cosa precedente è un’istantanea di un momento fortunato.