Il DNS di OpenVPN resta dopo SIGKILL: controllate prima il proprietario

Il DNS smette di risolvere dopo che un client OpenVPN viene ucciso, e il primo istinto è riscrivere /etc/resolv.conf. Quella modifica può rompere un resolver funzionante mentre il vero stato obsoleto si trova altrove. La domanda da risolvere per prima è chi possiede le impostazioni DNS installate dal tunnel, e se l’uscita che ha saltato la pulizia abbia davvero contato.

Tre condizioni decidono la riparazione: il segnale che ha terminato il processo, il componente del resolver che ha ricevuto le impostazioni e se il collegamento del tunnel esiste ancora. Rispondete in quest’ordine e la correzione di solito arriva senza toccare un file globale.

Decidete che tipo di uscita è avvenuta

Nell’edizione Community di OpenVPN, sia SIGINT sia SIGTERM sono richieste di uscita ordinata. SIGKILL non è intercettabile: non può essere bloccato né gestito, quindi nessuna routine di spegnimento ha la possibilità di eseguirsi. Un normale Ctrl+C in un terminale in primo piano genera SIGINT, mentre un supervisore che smette di attendere di solito scala a SIGKILL. La differenza conta perché solo il secondo caso garantisce che gli hook siano stati saltati.

Eseguirlo dentro screen o tmux non cambia quale segnale invia Ctrl+C. Controllate cosa ha ricevuto davvero il processo, non cosa fa normalmente il terminale.

Quando un servizio o un gestore di connessioni esegue il tunnel, fermate quella singola connessione tramite il suo proprietario invece di uccidere il pid. Un gestore può rialzare il processo, lasciandovi un tunnel nuovo e uno stato del resolver confuso. Un processo autonomo ha bisogno solo di una richiesta di terminazione ordinaria perché la pulizia venga eseguita.

Decidete chi possiede il resolver

systemd-resolved, uno script in stile resolvconf e una semplice riscrittura di file sono tre proprietari diversi. Il primo tiene le impostazioni per collegamento in memoria e le scarta quando l’interfaccia scompare. Il secondo tiene registrazioni che persistono finché qualcosa non le rimuove. Il terzo scrive un file e lascia il ripristino a chi l’ha scritto.

Identificate il proprietario prima di scegliere un comando di riparazione. Lo stesso sintomo ha tre risposte corrette diverse a seconda di quale sia in uso.

Una VPN gestita da NetworkManager può già possedere le modifiche al resolver. Aggiungere un secondo aiutante sopra ne crea due proprietari in competizione per lo stesso collegamento, e lo stato del perdente riappare alla riconnessione successiva. Se un gestore è al comando, correggete l’impostazione nel gestore invece che in uno script.

Cosa può e cosa non può fare l’hook down

Lo script down viene eseguito una volta che il dispositivo TUN/TAP è stato chiuso. Aggiungere down-pre inverte quest’ordine ed esegue lo script mentre il dispositivo esiste ancora, cosa che richiedono gli aiutanti che necessitano del collegamento attivo.

Nessuna delle due direttive fa eseguire un hook dopo SIGKILL. I privilegi non vengono nemmeno ripristinati da down-pre: se il demone scende a un user o group o entra in una chroot, l’hook viene eseguito con l’accesso che questo gli lascia. Un hook invocato può comunque fallire nell’aggiornare il resolver. Il riferimento di OpenVPN copre i segnali e il ciclo di vita della callback.

Controllate l’errore dell’hook stesso accanto allo stato di uscita del processo. Una pulizia mancante e una pulizia fallita appaiono uguali nel resolver e diverse nei log.

Controllate lo stato che resta davvero

Su un sistema che usa systemd-resolved, resolvectl status mostra quale collegamento porta ancora i server DNS della VPN o i domini di instradamento. Quel collegamento può appartenere a una connessione sparita o a un altro tunnel ancora attivo.

Un’interfaccia che scompare porta con sé la sua configurazione per collegamento, quindi un hook saltato può coesistere con un DNS pulito. Se il collegamento è ancora registrato ed è posseduto in esclusiva dalla connessione fermata, il gestore proprietario dovrebbe rimuoverlo. Se uno script più vecchio ha riscritto un file del resolver globale, cercate invece il passo di ripristino documentato di quello script.

Recuperate senza rubare un altro collegamento

Quando le impostazioni per collegamento sono vostre da gestire, resolvectl revert prende il nome del collegamento e cancella la configurazione DNS di runtime per quell’interfaccia. È un’azione di runtime e non una modifica al profilo, quindi la configurazione persistente della connessione resta intatta. Nominate il collegamento sbagliato e cancellate il DNS di un tunnel funzionante, per questo il nome viene dall’output dello stato.

Confermate che /etc/resolv.conf sia un collegamento simbolico gestito prima di modificarlo, poi fermate il client normalmente ancora una volta e guardate di nuovo il DNS. Se la seconda fermata pulisce, il problema precedente era l’uscita forzata e non la configurazione.