client-config-dir ignorato dopo che OpenVPN è diventato un servizio

Il tunnel si alza e il client si connette, ma l'indirizzo fisso e le rotte spinte che hai definito per quell'unico utente mancano. Nel log non c'è scritto “file not found”, ed è proprio questo che manda le persone a rigenerare i certificati. Nella maggior parte di questi casi il demone gira da una directory diversa dalla shell in cui hai fatto le prove, e client-config-dir non è mai stato risolto come presumevi. La correzione è una correzione di percorso, non un azzeramento delle credenziali.

Leggi l'unità prima di toccare la configurazione

Parti dal processo che gira davvero, non dal file che hai modificato. Chiedi a systemd la riga di esecuzione, la directory di lavoro e l'account a cui scende. Quelle tre risposte spiegano la maggior parte dei guasti di questa classe:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Un WorkingDirectory vuoto significa che l'unità parte in /, quindi un client-config-dir ccd relativo viene cercato in /ccd. Quella directory quasi non esiste mai, e il demone non considera la sua assenza un errore fatale.

Confrontalo con l'avvio interattivo che hai usato durante i test, dove la directory corrente della tua shell era probabilmente quella della configurazione. Stesso file, stesse parole chiave, due risultati diversi.

Rispetto a cosa viene risolto un percorso relativo

La parola chiave viene risolta rispetto alla directory di lavoro del processo nel momento in cui l'opzione viene usata. Non significa “accanto al file di configurazione che ho passato con --config”. OpenVPN leggerà volentieri una configurazione da un percorso assoluto e risolverà comunque i valori relativi altrove, ed è esattamente la trappola di qui. Il manuale di OpenVPN 2.6 enuncia la regola sotto --client-config-dir e di nuovo sotto --cd.

La parola chiave cd cambia quel contesto prima che vengano letti altri file, quindi un'unità che imposta cd /etc/openvpn/server e poi client-config-dir ccd si risolve in /etc/openvpn/server/ccd. Se aggiungi cd, controlla l'ordine delle direttive e ricorda che influisce su ogni altra referenza relativa nello stesso file.

Percorri il percorso come l'account del demone

Un percorso può essere corretto e comunque illeggibile. Dopo la rinuncia ai privilegi il demone non è più root, quindi ogni directory genitore ha bisogno del permesso di ricerca per quell'account, e il file del client stesso del permesso di lettura. Un solo bit di esecuzione mancante su un genitore basta a nascondere il file, e l'errore si manifesta solo come un client che riceve in silenzio il pool predefinito.

namei stampa i permessi di ogni componente in ordine, il che è più rapido che controllare le directory una per una:

namei -l /etc/openvpn/server/ccd/client1

Poi prova la lettura come account del servizio anziché come te stesso:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Se l'unità usa chroot, la directory deve esistere dentro la gabbia, e il percorso nella configurazione viene interpretato dopo l'applicazione del chroot. Un file presente sull'host fuori dalla gabbia è invisibile dall'interno.

Conferma la ricerca invece di indovinare

Alza il livello del log per un riavvio e leggi cosa dice il server sulle opzioni specifiche del client. A verb 4 il demone riporta la configurazione per client che ha importato, quindi una riga assente è prova diretta che nessun file è stato letto per quella connessione.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Esegui tutto in primo piano su una porta libera e collega un client. Così systemd esce del tutto dall'immagine: se le sostituzioni compaiono qui e non sotto il servizio, la differenza è il contesto dell'unità, non il file.

Decidi cosa deve succedere quando nessun file corrisponde. Senza ccd-exclusive il client viene ammesso solo con le impostazioni globali del pool, ed è il guasto silenzioso descritto sopra. Con essa, un file mancante diventa una connessione rifiutata, e quel rifiuto è più facile da notare ma più difficile da diagnosticare sotto carico.

Correggi, riavvia, verifica

Rendi la directory assoluta nella configurazione e lasciala così. I percorsi relativi sono sicuri solo quando l'unità fissa la directory di lavoro, e fissarla è un pezzo mobile in più che qualcuno rimuoverà più avanti.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Riavvia l'istanza, ricollega un client noto e leggi l'indirizzo che ha ricevuto insieme alle rotte spinte verso di lui. Se l'indirizzo corrisponde alla riga ifconfig-push nel file di quel client, la ricerca ha funzionato. Se il client finisce ancora nel pool generale, torna al conteggio delle righe del log: zero importazioni significa che il percorso o l'identità sono sbagliati, un'importazione con contenuto errato significa che stai modificando un file diverso da quello che legge il demone.

Torna indietro ripristinando insieme l'unità e la configurazione precedenti, poi riavvia. I certificati non vanno riemessi per nulla di tutto questo, e trattare un problema di directory come un problema di credenziali è il modo in cui una correzione di cinque minuti diventa una finestra di manutenzione.