systemd ferma il servizio VPN: allinea Type= al client

Le unità possono sembrare corrette, systemctl start può riportare successo e dieci secondi dopo il servizio resta inattivo. Oppure si riavvia ogni mezzo minuto finché il limite di avvio non lo ferma. Nessuno dei due comportamenti è un guasto di rete: l'unità descrive una durata di processo che non corrisponde a ciò che il client fa davvero. Il client può fare fork e uscire, oppure configurare la sessione e uscire subito.

Perché l'unità diventa inattiva pochi secondi dopo un avvio riuscito

systemd deduce lo stato dal processo che ha avviato, quindi Type= è un'affermazione su quel processo, non documentazione. Con Type=simple l'unità conta come attiva finché il comando gira e diventa inattiva quando ritorna. Un client che consegna la connessione a un aiutante ed esce appare quindi come un crash, anche con il tunnel attivo. Il journal mostra allora uno schema di avvio e arresto che si legge come un binario difettoso.

Leggi il tipo dell'unità accanto al comportamento del client prima di toccare la configurazione di rete.

Scegli il tipo che corrisponde al client

Due schemi coprono la maggior parte delle CLI dei fornitori: un comando che configura una sessione ed esce, e un comando che fa fork di un aiutante prima di tornare. Ognuno richiede una forma di unità diversa.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot con RemainAfterExit=true mantiene l'unità attiva dopo il ritorno del comando, il che corrisponde allo schema configura ed esci, e il comando di arresto dà al servizio una chiusura pulita. Un client che fa fork conserva la stessa forma ma ha bisogno di Type=forking perché systemd segua il figlio. Imposta Restart=on-failure, RestartSec=30 e un StartLimitBurst finito, così un'interruzione del fornitore non diventa un ciclo di riavvii che seppellisce l'errore.

Non lasciare mai che un client supervisionato si demonizzi

I supervisori fuori da systemd sbattono contro lo stesso muro. Uno script runit che avvia un client demonizzato torna subito al supervisore, che legge il ritorno come un crash e avvia un'altra copia. Ogni supervisore si aspetta di possedere il processo in primo piano, come sshd -D resta davanti. Togli il flag demone dai comandi supervisionati e lascia che il supervisore gestisca lo sfondo. Gli script di avvolgimento che tornano prima che il tunnel esista causano la stessa confusione.

Un processo che si stacca da sé è invisibile a tutto ciò che avrebbe dovuto sorvegliarlo.

La sessione finisce e porta con sé il tunnel

Una sessione desktop possiede il client che avvia. Termina l'accesso e il bus di sessione scompare, portando con sé il tunnel, il che spiega perché la connessione di un client grafico spesso cade quando si chiude l'ultima finestra. I server dovrebbero usare un'unità di sistema o un profilo NetworkManager che sale da solo. Un'unità utente ha senso solo quando il tunnel deve finire con l'accesso, quindi legala al target della sessione grafica e dichiaralo nella descrizione.

L'utente del servizio è l'altra metà dello stesso problema. Una chiave di proprietà di root con modo 0600 è illeggibile per un'unità che gira con un altro account, qualunque cosa sudo abbia ottenuto nella tua shell.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Ordina i dipendenti dopo che l'indirizzo esiste

Quando un demone si lega a un indirizzo di tunnel non ancora creato, esce con Cannot assign requested address. La riparazione è un ordinamento esplicito, non un ciclo di tentativi.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= ordina i lavori, mentre Requires= sull'unità del dispositivo lega il dipendente all'esistenza dell'interfaccia, il che è più forte che aspettare solo il target di rete. Ricarica il gestore dopo la modifica e riavvia il servizio dipendente, poi leggi il suo journal invece di supporre che l'ordine abbia funzionato. Invia l'output del client al journal con StandardOutput=journal o un'opzione di log, perché un client supervisionato che scrive in un file che nessuno apre sembra identico a uno che non è mai partito.

Poi riavvia una volta e conferma che l'unità è attiva quando compare il dispositivo del tunnel. Una correzione verificata solo con systemctl start non ha provato l'ordine di avvio che doveva riparare.