sudo, &, -b o --daemon: come portare un client OpenVPN in background

Nella frase «eseguilo in background» si nascondono due domande. La prima è se questo utente possa avviare un processo privilegiato; la seconda è se la sessione possa continuare senza che nessuno digiti in un terminale. Un ampersand della shell non risponde a nessuna delle due, e uno script che memorizza una password sudo in una variabile risponde male alla prima e lascia intatta la seconda. Separarle e le opzioni diventano facili da confrontare.

Confrontate i tre candidati sulla proprietà, non sulla comodità.

Tre modi per lasciare il terminale, tre proprietari diversi

Aggiungere un ampersand a un comando chiede alla shell di eseguirlo come lavoro in background, e il lavoro appartiene ancora a quella shell. sudo può chiedere prima ancora che il programma parta, e OpenVPN può chiedere dopo una passphrase della chiave o un accesso. Mettere in background un comando che attende input produce un processo che attende un terminale che nessuno guarda. Il terminale viene liberato; l’interazione no.

È l’opzione più economica e quella che fallisce nel modo più confuso, perché il prompt compare in un luogo che l’operatore ha già lasciato.

sudo -b non è un gestore di credenziali

sudo -b esegue il comando in background dal punto di vista di sudo stesso, il che suona come la funzione mancante e non lo è. Secondo il manuale di sudo, i comandi interattivi di solito si comportano male in quella modalità, e il controllo dei job della shell non può gestire i processi che crea. Sposta il processo senza dargli un modo di rispondere alle domande. Nulla in esso fornisce una passphrase per la chiave privata o un accesso al gateway.

Se la connessione richiede interazione, la soluzione è una configurazione di autenticazione non interattiva supportata, non un altro modo di avviare lo stesso prompt.

--daemon cambia il programma, non l’accesso

--daemon chiede a OpenVPN stesso di staccarsi dopo l’inizializzazione. Il manuale della versione 2.6 osserva che la redirezione di syslog avviene quando l’opzione viene analizzata, anche se il distacco avviene più tardi, quindi i messaggi possono smettere di comparire nel terminale prima del previsto. Il silenzio dopo quel punto non dimostra nulla sul tunnel. Aggiungete un --log o --log-append esplicito in modo che l’output finisca in un posto che potete leggere.

Anche la modalità demone rimuove la console in modo permanente. Una chiave privata protetta richiede askpass in quella modalità, e le credenziali inserite da console combinate con opzioni di cache possono lasciare una riautenticazione successiva senza un posto dove chiedere. Verificate il modello di autenticazione rispetto alla versione installata prima di supporre che un avvio in background sopravviva al primo rinnovo della chiave.

Cosa compra la validazione di sudo e cosa no

sudo -v convalida o aggiorna la credenziale locale memorizzata nella cache, autenticando se la policy lo richiede. Non avvia OpenVPN, non si autentica con il gateway e non garantisce che un comando successivo nello script sia consentito. sudo -n significa l’opposto: non chiedere, fallisci. Questo rende esplicito un fallimento di autorizzazione locale, il che è utile, e non dice nulla su ciò che OpenVPN chiederà più tardi.

Nessuna delle due opzioni è un motivo per concedere comandi senza password a tutti o per convogliare una password di amministratore in uno script.

Preferite un proprietario osservabile

Per un tunnel di proprietà della macchina, usate l’istanza di servizio supportata dalla distribuzione. Quel proprietario offre avvio, arresto, stato e log, e sopravvive alla fine della vostra sessione. Montare il background della shell, la demonizzazione e un ciclo di riavvio l’uno intorno all’altro crea tre proprietari per un solo tunnel e nessuna risposta chiara su quale stia girando.

Qualunque cosa scegliate, verificate la risorsa per cui il tunnel esiste. Una richiesta di avvio riuscita è un evento del processo, non la prova di una connessione funzionante.