systemd atura el servei VPN: fes coincidir Type= amb el client

Les unitats poden semblar correctes, systemctl start pot informar d'èxit i, deu segons després, el servei queda inactiu. O es reinicia cada mig minut fins que el límit d'inicis l'atura. Cap dels dos comportaments no és una fallada de xarxa: la unitat descriu una vida de procés que no coincideix amb el que el client fa realment. El client pot fer fork i sortir, o configurar la sessió i sortir immediatament.

Per què la unitat queda inactiva segons després d'un inici correcte

systemd dedueix l'estat del procés que ha iniciat, així que Type= és una afirmació sobre aquest procés, no documentació. Amb Type=simple, la unitat compta com a activa mentre la comanda s'executa i queda inactiva quan torna. Per tant, un client que lliura la connexió a un auxiliar i surt sembla una caiguda, fins i tot amb el túnel aixecat. Llavors el registre mostra un patró d'inici i aturada que es llegeix com un binari defectuós.

Llegeix el tipus d'unitat al costat del comportament del client abans de tocar la configuració de xarxa.

Tria el tipus que coincideixi amb el client

Dos patrons cobreixen la majoria de CLI de proveïdors: una comanda que configura una sessió i surt, i una comanda que fa fork d'un auxiliar abans de tornar. Cadascuna necessita una forma d'unitat diferent.

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

oneshot amb RemainAfterExit=true manté la unitat activa després que la comanda torni, cosa que encaixa amb el patró de configura i surt, i la comanda d'aturada dona al servei un tancament net. Un client que fa fork conserva la mateixa forma, però necessita Type=forking perquè systemd segueixi el fill. Defineix Restart=on-failure, RestartSec=30 i un StartLimitBurst finit, perquè una caiguda del proveïdor no es converteixi en un bucle de reinicis que enterri l'error.

No deixis mai que un client supervisat es converteixi en dimoni

Els supervisors fora de systemd topen amb la mateixa paret. Un script de runit que llança un client en dimoni torna de seguida al supervisor, que llegeix el retorn com una caiguda i n'inicia una altra còpia. Tot supervisor espera posseir el procés en primer pla, tal com sshd -D es queda davant. Treu la bandera de dimoni de les comandes supervisades i deixa que el supervisor faci la feina en segon pla. Els scripts embolcall que tornen abans que existeixi el túnel causen la mateixa confusió.

Un procés que es desenganxa és invisible per a tot allò que l'havia de vigilar.

La sessió acaba i s'emporta el túnel

Una sessió d'escriptori posseeix el client que llança. Acaba la sessió d'inici i el bus de sessió desapareix, emportant-se el túnel, cosa que explica per què la connexió d'un client gràfic sovint cau quan es tanca l'última finestra. Els servidors haurien d'usar una unitat de sistema o un perfil de NetworkManager que s'aixequi sol. Una unitat d'usuari només té sentit quan el túnel ha d'acabar amb l'inici de sessió, així que lliga-la a l'objectiu de la sessió gràfica i digues-ho a la seva descripció.

L'usuari del servei és l'altra meitat del mateix problema. Una clau propietat de root amb mode 0600 és il·legible per a una unitat que s'executa amb un altre compte, faci el que faci sudo a la teva shell.

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

Ordena els dependents quan l'adreça ja existeixi

Quan un dimoni s'enllaça a una adreça de túnel que encara no s'ha creat, surt amb Cannot assign requested address. La reparació és una ordenació explícita, no un bucle de reintents.

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

After= ordena les tasques, mentre que Requires= a la unitat del dispositiu lliga el dependent a l'existència de la interfície, cosa més forta que esperar només l'objectiu de xarxa. Recarrega el gestor després d'editar i reinicia el servei dependent, i després llegeix el seu registre en lloc de suposar que l'ordre s'ha aplicat. Envia la sortida del client al registre amb StandardOutput=journal o una opció de log, perquè un client supervisat que escriu en un fitxer que ningú obre sembla idèntic a un que no s'ha iniciat mai.

Després reinicia un cop i confirma que la unitat és activa quan apareix el dispositiu del túnel. Una correcció verificada només amb systemctl start no ha provat l'ordre d'arrencada que havia de reparar.