systemd detén o servizo VPN: axusta Type= ao cliente

As unidades poden parecer correctas, systemctl start pode informar de éxito e, dez segundos despois, o servizo queda inactivo. Ou reiníciase cada medio minuto ata que o límite de arranques o detén. Ningún dos dous comportamentos é unha falla de rede: a unidade describe unha vida de proceso que non coincide co que o cliente fai en realidade. O cliente pode facer fork e saír, ou configurar a sesión e saír de inmediato.

Por que a unidade queda inactiva segundos despois dun arranque correcto

systemd deduce o estado do proceso que iniciou, así que Type= é unha afirmación sobre ese proceso, non documentación. Con Type=simple, a unidade conta como activa mentres o comando se executa e queda inactiva cando volve. Por iso un cliente que entrega a conexión a un axudante e sae parece un fallo, mesmo co túnel levantado. Entón o rexistro mostra un patrón de inicio e parada que se le como un binario defectuoso.

Le o tipo de unidade xunto ao comportamento do cliente antes de tocar a configuración de rede.

Escolle o tipo que coincida co cliente

Dous patróns cobren a maioría das CLI de provedores: un comando que configura unha sesión e sae, e un comando que fai fork dun axudante antes de volver. Cada un precisa unha forma de unidade distinta.

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

oneshot con RemainAfterExit=true mantén a unidade activa despois de que o comando volva, o que encaixa co patrón de configurar e saír, e o comando de parada dá ao servizo un peche limpo. Un cliente que fai fork conserva a mesma forma, pero precisa Type=forking para que systemd siga o fillo. Define Restart=on-failure, RestartSec=30 e un StartLimitBurst finito, para que unha caída do provedor non se converta nun bucle de reinicios que enterre o erro.

Nunca deixes que un cliente supervisado se converta en demonio

Os supervisores fóra de systemd chocan coa mesma parede. Un script de runit que lanza un cliente demonizado volve de inmediato ao supervisor, que le o retorno como un fallo e arrinca outra copia. Todo supervisor espera posuír o proceso en primeiro plano, tal como sshd -D queda diante. Quita a bandeira de demonio dos comandos supervisados e deixa que o supervisor faga o traballo en segundo plano. Os scripts envoltorio que volven antes de que exista o túnel causan a mesma confusión.

Un proceso que se desengancha é invisible para todo o que debía vixialo.

A sesión remata e leva o túnel consigo

Unha sesión de escritorio posúe o cliente que lanza. Remata o inicio de sesión e o bus de sesión desaparece, levando o túnel consigo, o que explica por que a conexión dun cliente gráfico adoita caer ao pecharse a última ventá. Os servidores deberían usar unha unidade de sistema ou un perfil de NetworkManager que suba só. Unha unidade de usuario só ten sentido cando o túnel debe rematar co inicio de sesión, así que lígaa ao obxectivo da sesión gráfica e dío na súa descrición.

O usuario do servizo é a outra metade do mesmo problema. Unha chave propiedade de root con modo 0600 é ilexible para unha unidade que corre con outra conta, faga o que faga sudo na túa shell.

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

Ordena os dependentes cando o enderezo xa exista

Cando un demonio se liga a un enderezo de túnel que aínda non se creou, sae con Cannot assign requested address. A reparación é unha ordenación explícita, non un bucle de reintentos.

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

After= ordena as tarefas, mentres que Requires= na unidade do dispositivo liga o dependente á existencia da interface, o que é máis forte que agardar só polo obxectivo de rede. Recarga o xestor tras editar e reinicia o servizo dependente, e despois le o seu rexistro en lugar de supor que a orde surtiu efecto. Envía a saída do cliente ao rexistro con StandardOutput=journal ou unha opción de log, porque un cliente supervisado que escribe nun ficheiro que ninguén abre vese idéntico a un que nunca arrincou.

Despois reinicia unha vez e confirma que a unidade está activa cando aparece o dispositivo do túnel. Unha corrección verificada só con systemctl start non probou a orde de arranque que debía reparar.