OpenVPN non si avvia: leggete la prima riga, non la configurazione

Una VPN che muore al primo secondo è un animale diverso da una che si connette e poi fallisce, e l’errore abituale è trattarle come la stessa cosa. Qui non c’è handshake, non c’è scambio di certificati e non c’è rotta da esaminare. Una riga del journal decide quale di diverse riparazioni non correlate si applica, e saltarla costa un pomeriggio a modificare una configurazione che non è mai stata letta. Leggete quella riga per prima.

Tre comandi di sola lettura vi portano lì: prima journalctl -u openvpn@server -b --no-pager, poi systemctl status openvpn@server, e ss -lunp per i listener UDP e i loro proprietari.

La prima riga sceglie il ramo

Un conflitto di porte e un binario assente uccidono entrambi l’avvio nel giro di un secondo, e lasciano prime righe diverse. Un messaggio che l’indirizzo è già in uso nomina la porta; un eseguibile assente nomina un percorso che non esiste più; una condizione fallita o un file di configurazione assente nomina il file. Quei tre portano a riparazioni diverse, e nessuna migliora reinstallando il client. Copiate il primo errore nelle vostre note prima di eseguire qualcos’altro.

Osservate il ciclo di tentativi che nasconde la riga originale. Un’unità con una politica di riavvio può seppellire il primo errore sotto una dozzina di identici, quindi journalctl -b filtrato per l’unità e letto dall’alto batte la coda.

Chi altro tiene la porta 1194

Il colpevole di solito non è un secondo server che qualcuno ha configurato di proposito. Aspettatevi un client avviato a mano ancora vivo in un altro terminale, un secondo profilo che ha scelto la stessa porta, o un pacchetto del fornitore il cui tunnel tiene la 1194. Il proprietario del socket compare in ss -lunp; passate quel PID a systemctl status per sapere se un’unità è responsabile. Abbassatelo tramite il suo percorso di controllo invece che con un segnale.

Un segnale a un processo gestito da un’unità di solito provoca un riavvio, e lo stesso errore riappare poco dopo come un problema nuovo. Usate systemctl stop per un’unità, il comando di servizio del pacchetto stesso per un’installazione del fornitore, e un segnale solo per qualcosa che avete avviato a mano in quella shell.

Unità rimaste dopo una rimozione

Una rimozione cancella i binari; i file di unità scritti a mano, di solito sotto /etc/systemd/system, sopravvivono. Systemd ritenta allora un’unità che punta a un percorso che non esiste più, e il messaggio riguarda quel file mancante e non la rimozione di ieri. systemctl status mostra il percorso del frammento dell’unità vicino all’inizio, quindi controllatelo con dpkg -S prima di cancellare qualsiasi cosa. Una volta sparito l’orfano, systemctl daemon-reload e systemctl reset-failed ripuliscono lo stato; altrimenti ogni successivo controllo di stato lo eredita.

Quando which openvpn risponde con qualcosa sotto /usr/local, il binario in gioco viene da un installer del fornitore e non da apt. Un installer del genere porta di solito il proprio listener, la propria voce di avvio e la propria directory di configurazione, quindi rimuovere il comando visibile lascia il socket occupato.

Disinstallatelo come documenta il fornitore, verificate che la porta sia libera con ss -lunp, e aggiungete il client della distribuzione solo se vi serve.

Mettete in ordine lo stato prima di riprovare

Pulite lo stato di errore prima di trarne conclusioni: systemctl reset-failed rimuove i contatori, e systemctl status riporta poi lo stato attuale dell’unità e non la sua storia. Avviatela una volta e leggete il journal di quella specifica esecuzione invece dello stato aggregato della macchina. Un’unità che riporta di essere attiva mentre il tunnel non trasporta nulla è un problema separato, e molto più comune. I due si fondono nei bug report perché entrambi finiscono con l’utente che dice che la VPN non funziona.

Annotate il ramo scelto: conflitto di porte, binario assente, configurazione assente. La prossima volta il riconoscimento sarà più rapido.