Quale istanza di OpenVPN sta davvero usando il tuo profilo PiVPN?

PiVPN scrive una configurazione server e un profilo client, poi esce; non diventa mai il processo che trasporta il tuo traffico. Perciò un handshake fallito, un client che chiama l’endpoint sbagliato o un servizio che torna storto dopo un riavvio non si spiegano dai menu dell’installer. Quei sintomi appartengono al demone OpenVPN in esecuzione ora, alla configurazione che quel demone ha realmente caricato e al log a cui è stato puntato. Quattro comandi in sola lettura di solito risolvono, e nessuno di essi cambia i tuoi certificati o le tue chiavi.

L’helper e il demone sono oggetti diversi

La confusione è facile da spiegare: una directory contiene il file generato dall’helper, il file che il demone legge e talvolta una copia obsoleta di entrambi. Un helper è uno script di provisioning. Installa pacchetti, scrive file di unità e stampa un profilo client, poi il suo lavoro finisce. Ciò che resta è una voce nel gestore dei servizi e una riga di comando.

Su un host systemd, parti dall’unità attiva invece che dall’elenco della directory. Il nome dipende dal pacchetto: le immagini Debian e Raspberry Pi OS espongono di solito un’istanza modello come openvpn-server@server, mentre le installazioni più vecchie usano openvpn@server. Chiedi al gestore quale è in esecuzione invece di indovinare da un nome di file.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Leggi ExecStart= in quell’output. Nomina l’eseguibile e le opzioni che il gestore lancia davvero, incluso qualsiasi --config percorso; un file di configurazione lì vicino a cui nessun comando fa riferimento non fa parte del tunnel in esecuzione.

Segui la catena di configurazione risolta dal demone

OpenVPN non scansiona una directory in cerca di impostazioni. Legge il file passato con --config, segue ogni config direttiva al suo interno e poi applica le opzioni della riga di comando. Il manuale 2.6 descrive quell’ordine, e conta quando due file non concordano su porta, dispositivo o cifratura.

Prima esporta l’invocazione effettiva, poi guarda le direttive che decidono identità e raggiungibilità. Entrambi i comandi sono in sola lettura e sicuri su un server attivo, anche se il secondo stampa percorsi che forse non vuoi in un ticket pubblico.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Un file .ovpn in una directory home è un artefatto client. Il demone del server non lo legge mai, quindi modificare quel file per correggere un guasto di handshake lato server non ottiene nulla.

Le inclusioni sono l’altra trappola. Una riga config tira dentro un secondo file le cui opzioni vengono elaborate in quel punto, così una direttiva successiva a valore singolo può scavalcare ciò che il file principale sembra dire. Se il file visibile sembra corretto e il demone si comporta ancora diversamente, leggi il file incluso prima di cambiare qualcosa.

Abbina il log al processo, non all’errore che ricordi

Due destinazioni di log sono comuni, e solo una è il journal. Con log-append impostato, il demone scrive in quel file e il journal conserva poco oltre le righe di avvio. Senza, journalctl è la fonte degli eventi.

journalctl -u openvpn-server@server -n 80 --no-pager

Correla un tentativo di connessione con una finestra temporale. Annota l’endpoint del client, poi leggi gli eventi del server degli stessi secondi. Un handshake TLS che non arriva mai allo scambio dei certificati indica raggiungibilità o disallineamento di protocollo, mentre un rifiuto di autenticazione arriva dopo che i parametri del tunnel sono già stati concordati.

Una vecchia voce di log non dimostra nulla su un profilo scaricato cinque minuti fa. Rigenera il file client, riconnettiti una volta e leggi solo le righe comparse durante quel tentativo.

Annota il primo guasto concreto invece dell’ultimo generico. Un errore di bind, uno scambio esterno senza risposta, un rifiuto di certificato e un rifiuto di account ti mandano ciascuno a uno strato diverso, e un timeout alla fine spesso nasconde l’evento utile sopra di esso.

Ricostruire il tunnel non è un passo diagnostico

La scorciatoia tentatrice è alzare un secondo tunnel più semplice: chiave statica, nessun certificato, nessuna autenticazione aggiuntiva. Spesso si connetterà, e dimostra solo che due host possono far passare UDP o TCP tra loro. Non dice nulla sul perché la distribuzione autenticata con certificati fallisca, e sostituisce in silenzio il modello di sicurezza che ti era stato chiesto di mantenere.

Lo stesso vale per disattivare tls-auth o tls-crypt, allentare verify-x509-name, o eliminare un secondo fattore per ottenere uno stato verde. Un tunnel che si connette perché la verifica è stata rimossa è un altro sistema, non uno riparato.

Fai un solo cambiamento circoscritto allo strato indicato dal log, riavvia la stessa unità e ripeti l’unico tentativo di connessione. Questo mantiene onesto il confronto e lascia una modifica che puoi annullare.

Cosa consegnare alla persona successiva

Annota quattro fatti finché li hai ancora: la versione di OpenVPN da openvpn --version, l’unità attiva, la catena di configurazione con le sue inclusioni e la finestra di log che copre un tentativo. Quei quattro trasformano un reclamo vago in un caso riproducibile.

Oscura prima di condividere. Le chiavi private, auth-user-pass e altri file, il materiale di chiave statica e i bundle client completi non hanno posto in un ticket; i nomi delle opzioni e la forma della catena bastano di solito a un secondo paio d’occhi.

Se la catena è intatta e il log punta ancora alla rete, il passo successivo è il percorso tra client e server invece di un’altra installazione. È l’unica parte della storia che l’helper non ha mai posseduto.