OpenVPN non parte senza errori? Guardate il journal

Il comando ritorna, il servizio appare in errore e nulla che somigli a una spiegazione raggiunge il terminale. Quel silenzio è il sintomo che le persone descrivono come «OpenVPN non parte», e quasi mai significa che il programma è morto senza dire nulla. Significa che il messaggio è finito in un canale che non stavate leggendo, o che ciò che avete avviato non era ciò che avevate configurato. Entrambi i casi si diagnosticano in meno di un minuto quando smettete di trattare il profilo come il sospetto.

Quattro luoghi assorbono l’uscita: il journal dell’unità, il plugin che possiede la connessione, l’altro capo del tunnel e un binario diverso da quello che pensate stia girando. Ognuno ha il proprio controllo.

Il silenzio significa che non stavate guardando il canale giusto

Una chiamata in primo piano stampa sul vostro terminale. Un’unità stampa nel journal, e un’unità in errore può uscire prima di scrivere qualcosa se il guasto sta in come è stata avviata e non in ciò che le è stato detto. La distinzione conta: nessuna voce nel journal significa che il processo non è mai davvero girato, mentre una voce seguita da un’uscita significa che è girato e ha rifiutato qualcosa.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Aggiungete systemctl show -p Result -p ExecMainStatus openvpn-client@office per separare un’uscita pulita da un segnale. Uno stato 1 con un Result=exit-code è una decisione del programma; Result=signal o un timeout indicano invece l’ambiente, e nessuna modifica al profilo lo cambierà. Annotate entrambi i valori prima di riavviare qualsiasi cosa, perché un riavvio cancella lo stato transitorio che li ha prodotti.

Il nome dell’istanza fa parte del percorso

L’unità modello pacchettizzata non accetta un percorso di file. Accetta un nome di istanza, e quel nome viene aggiunto a una directory per trovare il profilo: office si risolve in /etc/openvpn/client/office.conf nel pacchetto Debian e Ubuntu. Un file chiamato office-v2.conf avviato come @office non viene mai letto, e l’unità esce in silenzio perché dal suo punto di vista non c’era nulla da fare. La directory di ricerca è diversa tra modalità client e server, quindi lo stesso errore punta altrove quando cambiate modello.

Quella discrepanza è la causa più comune del guasto silenzioso, ed è invisibile nel profilo perché il profilo va bene. Elencate ciò che esiste davvero e confrontate i due nomi carattere per carattere, inclusa qualsiasi estensione che il pacchetto si aspetta.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Se l’unità è abilitata ma nessuna istanza è elencata, l’abilitazione stessa può riferirsi a un nome che è stato rinominato in seguito. Riabilitare l’istanza corretta di solito basta, e vale la pena cancellare il vecchio file di unità rimasto per non confondere la persona successiva. Un file di unità dimenticato è una piccola cosa che costa un’ora a qualcuno più tardi.

Quando il plugin possiede il tunnel, il terminale non vede nulla

Una connessione avviata dall’applet del desktop appartiene a NetworkManager, e la sua uscita OpenVPN va nel journal di quel servizio invece che in una shell che avete aperta. Eseguire il client a mano e non vedere nulla è previsto in quella disposizione, perché il processo eseguito a mano non è quello che porta la connessione.

Cercate nel journal il servizio che lo possiede, poi riproducete l’analisi con una verbosità che potete leggere. I due comandi sotto guardano proprietari diversi dello stesso guasto.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

L’esecuzione autonoma serve a leggere i messaggi, non a sostituire la connessione gestita, e le due differiscono dopo: integrazione DNS, rotte e durata appartengono al plugin. Correggere un errore di analisi nell’esecuzione autonoma non corregge automaticamente la risoluzione dei nomi quando l’applet prende il controllo, quindi tenete separate le due osservazioni.

Due binari, un PATH

Una build manuale installata sotto /usr/local vince in una chiamata shell, perché /usr/local/sbin precede /usr/sbin nel PATH predefinito di Ubuntu. Un’unità non usa il vostro PATH; esegue il percorso assoluto scritto in ExecStart. Quindi la versione che funziona nel terminale e quella che fallisce come servizio possono essere programmi davvero diversi.

Confrontate i due prima di ricostruire qualsiasi cosa. Il terzo comando è quello che decide l’argomento.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Un’altra differenza d’ambiente si nasconde nello stesso punto. Un’unità pacchettizzata si affida a una directory di runtime sotto /run che systemd crea per lei; un’unità sostitutiva scritta a mano che ometta quell’impostazione può fallire prima di aprire un solo file, e il guasto sembra un rifiuto generico senza alcun messaggio OpenVPN.

Guasti che il client non può segnalare

Alcuni esiti si decidono all’altro capo. Un gateway che risponde con uno stato HTTP e chiude la connessione vi ha detto del proprio stato, e il passo successivo utile è il suo log o l’account dietro la credenziale invece dei vostri file locali. Nulla di locale è rotto in quello scenario, e modificare il profilo per compensare rende più difficile la diagnosi successiva. Leggete quel log prima di toccare la configurazione del client.

Un altro caso silenzioso è un client che funziona correttamente. Un tunnel in modalità client non ascolta mai su una porta, quindi un controllo che si aspetta un listener aperto non segnalerà nulla e sembrerà un guasto. Confermate quale modalità avete avviato prima di trarre conclusioni da un elenco di porte vuoto.

Lavorate i livelli in ordine: l’unità esiste e il nome dell’istanza è corretto, qualcosa è arrivato al journal o al file --log, quale binario e quale profilo sono girati davvero, e il guasto è locale o remoto. Ogni risposta rimuove un livello. Partire dal profilo significa riscrivere un file che forse non è mai stato aperto.