openvpn3 session-start ignora il file delle credenziali

Connetti con il client 2.x e il profilo funziona; passa lo stesso file al client 3.x e si ferma a un prompt della password. Passa --auth-user-pass creds.txt a openvpn3 session-start e il risultato è lo stesso, perché il client più recente non ha uno stadio che legga il file. Il rifiuto è deliberato: le credenziali appartengono a una sessione, e una sessione è creata da un servizio, non dal processo nel tuo terminale. Scegli tra il prompt interattivo e l’helper autoload, e sappi cosa memorizza ciascuno.

Perché il file salvato non ha dove andare

Nel design più recente, la gestione della configurazione e quella delle sessioni sono servizi separati che comunicano sul bus di sistema. È questa separazione che consente a un utente normale di avviare una sessione senza che un demone privilegiato legga per lui un file di password protetto. Le credenziali basate su file non hanno posto in quel modello, perché non esiste un avvio lato demone che le legga. Il rifiuto è una conseguenza dell’architettura, non una funzione mancante.

Vale la pena nominare il vecchio schema per disimpararlo più facilmente: un profilo fa riferimento a un file di credenziali e il demone lo legge quando parte il tunnel. Nel nuovo modello le credenziali appartengono a una sessione e vengono fornite quando quella sessione inizia. openvpn3 session-start --config work.ovpn le chiede, e --auth-user-pass creds.txt viene rifiutato perché nulla in quel percorso aprirebbe il file. Ogni ricetta 2.x che trovi presuppone uno stadio che non esiste più.

Anche la configurazione e le impostazioni locali del sito sono separate, il che spiega una seconda sorpresa. Un profilo può sembrare completo mentre la connessione che produce manca di configurazione di routing e resolver. Quei pezzi vengono applicati come impostazioni locali del sito, separatamente dal file importato.

Il percorso del prompt e la sessione che lascia

Fornire la password all’avvio della sessione è il flusso di lavoro previsto. Il client chiede una volta, consegna le credenziali al backend della sessione e prosegue:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Niente viene scritto su disco da quel percorso. La sessione continua anche dopo che il terminale si chiude, cosa che sorprende chi si aspetta che il processo muoia con la shell. È proprio questo il senso di spostare la gestione delle sessioni in un servizio. La sessione sopravvive al terminale che l’ha richiesta e deve essere fermata esplicitamente.

Per una workstation con una persona davanti, è anche l’opzione più sicura, perché non c’è alcun segreto memorizzato da proteggere o dimenticare. È inadatta solo dove nessuno è presente per digitare.

Automazione senza una persona alla tastiera

Dove una macchina deve connettersi senza una persona, il progetto fornisce openvpn3-autoload. Legge una directory di profili e un descrittore corrispondente per ogni profilo, e il descrittore fornisce le credenziali in testo semplice. L’helper è un binario separato, di solito in /usr/sbin/openvpn3-autoload, non un’opzione di session-start. Configurarlo significa creare la directory, copiare il profilo con il nome che il descrittore si aspetta e scrivere il descrittore.

Una configurazione per utente è così, eseguita con l’account che possiederà la sessione. La modalità della directory tiene fuori gli altri utenti locali:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Il descrittore nomina le credenziali e chiede un avvio automatico. Tieni il valore della password fuori dal controllo di versione:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Poi invoca l’helper una volta e conferma che la sessione compaia. Il secondo comando è il controllo, non un altro passo di configurazione:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

All’avvio, un’unità pacchettizzata chiamata openvpn3-autoload.service usa la directory di sistema /etc/openvpn3/autoload, non quella per utente. Quella posizione richiede proprietà di root e una modalità più restrittiva, e il descrittore contiene ancora la password in chiaro. Il compromesso è esplicito: ora la password sta su disco, quindi tratta quella directory come un segreto, escludila dai backup fuori host e scegli il percorso interattivo ogni volta che una persona è presente.

Guasti del bus che sembrano guasti della password

Alcuni guasti attribuiti alle credenziali non sono affatto tali. Un errore di permessi che nomina il percorso di attivazione del servizio significa una di due cose: il backend non è attivo, oppure il chiamante non ha il permesso di attivarlo. Nessuna modifica al profilo cambierà nessuna delle due. Controlla lo stato del servizio e la politica del bus fornita prima di toccare la configurazione.

I comandi sotto separano le due cose. Il primo riporta se il backend è in esecuzione; il secondo mostra gli errori recenti del bus:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

L’altra lettura sbagliata frequente è una sessione che compare e poi sparisce subito. Quella sequenza di solito significa che le impostazioni locali del sito non sono mai state applicate, quindi il tunnel è salito senza le rotte e le modifiche al resolver che lo rendono utile. Leggi la sequenza invece dell’ultima riga: se la sessione è stata creata, se ha raggiunto uno stato connesso e se è sopravvissuta sono tre fatti separati.

Quando il client più vecchio è ancora in uso

Il client 2.x accetta ancora un file di credenziali, e un portachiavi può rispondere al suo prompt senza che il segreto tocchi mai il disco. Un wrapper risolve la voce, così il file nomina la ricerca invece della password. Questo assetto dipende da un portachiavi sbloccato, che un container senza sessione di login o un’unità che parte prima che qualcuno acceda non possono fornire. Lo strumento di ricerca segnala allora una collezione su cui non può scrivere, quindi l’errore sembra un guasto delle credenziali quando è un guasto del portachiavi.

Prima di costruire qualsiasi cosa del genere, controlla se un’impostazione di keepalive nel profilo elimina del tutto la necessità di riavviare. Una sessione che resta attiva non raggiunge mai il prompt che stai cercando di automatizzare.