Controlli il tunnel, esegui systemctl status openvpn e ottieni active (exited) senza Main PID e con un elenco di processi vuoto. La lettura naturale è che il servizio sia partito e morto, quindi apri l’unità, trovi /bin/true e concludi che il pacchetto è rotto. Nel pacchetto Debian quello stato è il wrapper che lavora come previsto, e il tunnel vive in una delle unità di istanza che avvia. L’unità aggregata non ti dirà mai quale istanza l’ha costruita.

Che cosa significa davvero active (exited) su questa unità

L’unità impacchettata è una tantum: il suo ExecStart è /bin/true, e RemainAfterExit=yes è ciò che mantiene un’unità terminata segnalata come active (exited). Togli quella direttiva e la stessa attività /bin/true riuscita finisce in inactive (dead), esattamente lo stato che le persone si aspettano e leggono male nella direzione opposta. Il comando è un segnaposto, e l’unità riferisce su lavoro che altre unità svolgono. Nulla in questa disposizione è rotto, e sostituire /bin/true cambia il contratto di impacchettamento, non il tunnel.

Il wrapper delega. Avvia le unità di istanza fornite dalla configurazione del pacchetto o dal suo generatore systemd, ed è per questo che un elenco di processi vuoto non dimostra nulla sul tunnel. Quando nessuna istanza è selezionata, il wrapper riesce comunque e non avvia comunque nulla. Lo stato risponde se il wrapper è stato eseguito, non se esiste un tunnel.

Leggi le tre righe dell’output di status invece della parola tra parentesi. Loaded nomina il file di unità che systemd ha letto, Active porta il timestamp dell’ultima esecuzione riuscita, e l’assenza di Main PID si adatta a un’attività una tantum terminata. Quelle tre righe sono anche il modo per distinguere questo wrapper da un servizio caduto un secondo dopo l’avvio.

Elenca le unità prima di rileggere lo status

Chiedi a systemd che cosa esiste prima di chiedere che cosa è in esecuzione. Un modello può essere installato mentre nessuna istanza è creata, e solo un’unità creata porta un tunnel. Inizia dall’insieme caricato:

systemctl list-units 'openvpn*'

Quell’elenco è ciò che systemd ha caricato in questo momento, ed è la cosa più vicina a un inventario dei tunnel. I file di unità installati rispondono a un’altra domanda, e quell’elenco mostra ancora un modello quando non è stato creato nulla:

systemctl list-unit-files 'openvpn*'

Leggi i due elenchi insieme, perché un modello nel secondo e un’istanza nel primo sono risposte diverse. Un modello che esiste e un’istanza che gira non sono lo stesso fatto, e solo il secondo significa un tunnel. Anche le disposizioni dei pacchetti variano tra distribuzioni e versioni di OpenVPN. Un modello openvpn@ più vecchio, una coppia client e server separata e un wrapper di distribuzione possono essere tutti legittimi nel proprio impacchettamento.

Adattati alla tua macchina invece che al tutorial che hai trovato. Il nome dell’istanza nell’output di qualcun altro può essere office mentre il tuo è home o work. Ciò che si trasferisce è il metodo, non la stringa.

Segui il nome dell’istanza fino al file che legge

Nel modello client upstream la directory di lavoro dell’unità è /etc/openvpn/client e il suo comando prende %i.conf da lì, quindi openvpn-client@office legge /etc/openvpn/client/office.conf. Conferma quella mappatura sull’unità installata invece di fidarti dell’esempio, perché il modello che hai può essere più vecchio o una riscrittura della distribuzione:

systemctl cat [email protected]

Leggi i drop-in che compaiono in fondo a quell’output, perché un file sotto .d/ può cambiare ExecStart, la directory di lavoro o il percorso di configurazione. Un profilo che hai scaricato come office.ovpn non è il file che l’istanza apre. Quella lacuna è la ragione abituale per cui un errore nomina un percorso che non hai mai modificato.

I percorsi relativi dentro il profilo sono la trappola successiva. Spostare il file principale lasciando relative le referenze ca, cert e key scambia un errore di file mancante con un altro errore di file mancante. Il secondo punta a un file che eri sicuro esistesse, ed è per questo che la directory del profilo conta più del nome del file.

Avviala, poi leggi il journal di quell’istanza

Avvia l’istanza che hai appena ispezionato, perché il log dell’unità aggregata non conterrà gli errori del tunnel. Poi leggi il journal di questo avvio e cerca in quell’ordine un errore di configurazione, un errore di accesso al file e un errore di connessione, perché ognuno fallisce in una fase diversa dell’avvio.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Avviare e abilitare sono decisioni separate: start esegue l’unità ora, enable prepara il prossimo avvio, e enable --now fa entrambe in un passo. daemon-reload rilegge le definizioni di unità e non riavvia un processo in esecuzione né applica un profilo modificato. Dopo aver cambiato il profilo, riavvia l’istanza, perché è ciò che rilegge il file.

Non mettere un secondo gestore sullo stesso tunnel

NetworkManager e i gestori di sessione di OpenVPN 3 possiedono il proprio stato di connessione, e un’istanza systemd accanto a uno di loro mette due proprietari sullo stesso tunnel. Il sintomo è un tunnel che sale e viene sostituito pochi secondi dopo, o uno che si rifiuta di restare fermo. Scegli il gestore che la tua distribuzione documenta per il desktop, e usa systemd deliberatamente su un server.

Controlla se esiste già un proprietario prima di avviare un’istanza. Quando un’applet del desktop mostra la connessione, l’istanza che avvii la ostacola invece di completarla. Disabilita il gestore che non usi invece di eseguire entrambi e sperare che l’ordine regga. Quel conflitto spiega anche journal in cui un tunnel viene stabilito e poi smontato da un processo che non hai mai avviato.

Rispondi alla domanda originale con il nome dell’istanza, il file che ha letto e la riga di journal che ha fallito. Le note di OpenVPN sull’integrazione con systemd descrivono la disposizione del modello e la mappatura dei file attraverso cui si risolve il nome dell’istanza.

Articoli correlati