Quale binario di openvpn è in esecuzione? Controlla il percorso di avvio

Un vecchio espediente spostò l’eseguibile di OpenVPN altrove e lasciò un involucro shell nel percorso originale. Mesi dopo arriva un aggiornamento, e annullare l’espediente diventa un gioco di indovinelli su quale file sia davvero il client. Il nome del comando, l’eseguibile configurato nel servizio e l’elenco dei file del pacchetto possono tutti puntare a oggetti diversi, e ripararne uno senza gli altri produce un host che sembra sistemato e si comporta peggio.

Parti dal percorso che il servizio avvia

Un terminale e un’unità systemd non risolvono gli eseguibili allo stesso modo. La shell cerca in un PATH; l’unità nomina un percorso, e le sovrascritture drop-in possono sostituirlo senza toccare il file che stai leggendo. Questa differenza spiega gran parte della confusione in questa attività. Decide anche quale file deve essere l’obiettivo della tua riparazione.

Chiedi all’unità cosa esegue, comprese le sovrascritture drop-in che la modificano, e leggi la riga ExecStart risultante invece del frammento che presumi autorevole. Poi segui quel percorso attraverso qualsiasi collegamento simbolico fino al file finale. Un involucro che termina con exec in una directory nascosta è una disposizione comune di queste vecchie correzioni.

Annota il percorso risolto prima di cambiare qualsiasi cosa.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Confronta il nome del comando con il percorso del servizio

Le due risposte sono spesso diverse, e questa differenza non è automaticamente un guasto. Un plugin di NetworkManager può avviare un proprio percorso, e un container può montarne un altro.

Ciò che conta è sapere quale proprietario avvia il processo che serve il traffico. Se l’unità esegue /usr/local/sbin/openvpn-wrapper mentre la tua shell risolve /usr/sbin/openvpn, riparare il secondo file non cambia nulla nel servizio.

Chiedi quale pacchetto possiede ogni candidato, poi decidi se il file è gestito dal pacchetto o collocato localmente. Un file senza pacchetto proprietario è un file che qualcuno ha messo lì di proposito, e merita un nome, un proprietario e un motivo prima di essere cancellato. Anche l’errore inverso è comune: sovrascrivere un file di pacchetto con un vecchio binario salvato perché un post del forum usava la stessa directory.

Lascia che il database dei pacchetti parli dei file del pacchetto

Quando il software proviene da un pacchetto Debian, il database dei pacchetti può dirti se i suoi file corrispondono ancora a ciò che è stato installato. È una questione ristretta di integrità, non un verdetto di sicurezza, e la differenza conta quando decidi cosa riparare. Una discrepanza significa che il file è cambiato dopo l’installazione, il che potrebbe essere il tuo vecchio espediente o una modifica locale legittima. L’output non stabilisce quale, quindi leggilo come un indizio e non come una conclusione.

Esegui la verifica e leggi l’output invece di trattare un risultato vuoto come prova di qualcosa.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

Il manuale di dpkg documenta che la verifica confronta i file installati con i metadati registrati localmente, usando i checksum memorizzati dove esistono. Nota un file di pacchetto modificato, e non può dirti se al suo posto venga avviato un altro binario.

Registra lo stato prima di riparare

Raccogli il percorso di avvio risolto, la relazione del file con il pacchetto, la posizione dell’involucro e il record di modifica che lo ha introdotto. Copia l’involucro in un luogo protetto se contiene lavoro di integrazione che servirà più avanti.

Non incollare il contenuto dell’involucro in un thread di supporto prima di averlo letto, perché questi script a volte portano credenziali o dettagli del gateway.

Annota quali profili usa il servizio e chi è connesso mentre lavori, perché riavviare il tunnel può interrompere la sessione con cui amministri l’host.

Verifica l’avvio, poi ritira l’involucro

Dopo la riparazione, avvia il servizio e conferma che il processo esegue il percorso previsto. Una query di versione eseguita a mano dimostra che il file funziona; non dimostra che l’unità lo usi.

Poi riconnetti un client e controlla che il profilo si autentichi ancora, perché una sostituzione di binario che ignora le opzioni originali fallirà in un modo che sembra un problema di certificato.

Ritira l’involucro spostato tramite lo stesso record di modifica che lo ha introdotto. La riparazione completata indica quale eseguibile è in esecuzione, perché e quale file è stato rimosso; ripristinare un nome di file e sperare non è la stessa cosa.