systemd para o serviço VPN: alinhe Type= ao cliente

As unidades podem parecer corretas, o systemctl start pode reportar sucesso e, dez segundos depois, o serviço fica inativo. Ou reinicia a cada meio minuto até o limite de arranques o travar. Nenhum dos comportamentos é uma falha de rede: a unidade descreve uma vida de processo que não corresponde ao que o cliente faz na realidade. O cliente pode fazer fork e sair, ou configurar a sessão e sair de imediato.

Por que a unidade fica inativa segundos depois de um arranque bem-sucedido

O systemd deduz o estado a partir do processo que iniciou, pelo que Type= é uma afirmação sobre esse processo, não documentação. Com Type=simple a unidade conta como ativa enquanto o comando corre e fica inativa quando ele regressa. Por isso um cliente que entrega a ligação a um auxiliar e sai parece um crash, mesmo com o túnel ativo. O registo mostra então um padrão de arranque e paragem que se lê como um binário avariado.

Leia o tipo da unidade ao lado do comportamento do cliente antes de tocar na configuração de rede.

Escolha o tipo que corresponde ao cliente

Dois padrões cobrem a maioria das CLI de fornecedores: um comando que configura uma sessão e sai, e um comando que faz fork de um auxiliar antes de regressar. Cada um exige uma forma de unidade diferente.

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

oneshot com RemainAfterExit=true mantém a unidade ativa depois de o comando regressar, o que corresponde ao padrão configurar e sair, e o comando de paragem dá ao serviço um encerramento limpo. Um cliente que faz fork mantém a mesma forma mas precisa de Type=forking para que o systemd siga o filho. Defina Restart=on-failure, RestartSec=30 e um StartLimitBurst finito, para que uma falha do fornecedor não se transforme num ciclo de reinícios que enterra o erro.

Nunca deixe um cliente supervisionado transformar-se em daemon

Os supervisores fora do systemd batem na mesma parede. Um script runit que lança um cliente em daemon volta imediatamente ao supervisor, que lê o retorno como um crash e arranca outra cópia. Todo o supervisor espera deter o processo em primeiro plano, tal como sshd -D fica à frente. Retire a flag de daemon aos comandos supervisionados e deixe o trabalho de fundo para o supervisor. Scripts invólucro que regressam antes de o túnel existir causam a mesma confusão.

Um processo que se desliga de si próprio é invisível para tudo o que o devia vigiar.

A sessão termina e leva o túnel consigo

Uma sessão de ambiente de trabalho detém o cliente que lança. Termine a sessão e o bus de sessão desaparece, levando o túnel, o que explica por que a ligação de um cliente gráfico cai muitas vezes quando a última janela fecha. Os servidores devem usar uma unidade de sistema ou um perfil do NetworkManager que suba sozinho. Uma unidade de utilizador só faz sentido quando o túnel deve terminar com a sessão, por isso ligue-a ao alvo da sessão gráfica e diga-o na descrição.

O utilizador do serviço é a outra metade do mesmo problema. Uma chave pertencente ao root com modo 0600 é ilegível para uma unidade que corre com outra conta, faça o sudo o que fizer na sua shell.

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

Ordene os dependentes depois de o endereço existir

Quando um daemon se liga a um endereço de túnel que ainda não foi criado, sai com Cannot assign requested address. A reparação é uma ordenação explícita, não um ciclo de tentativas.

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

After= ordena as tarefas, enquanto Requires= na unidade do dispositivo liga o dependente à existência da interface, o que é mais forte do que esperar apenas pelo alvo de rede. Recarregue o gestor depois de editar e reinicie o serviço dependente, e depois leia o registo em vez de assumir que a ordem produziu efeito. Envie a saída do cliente para o registo com StandardOutput=journal ou uma opção de log, porque um cliente supervisionado que escreve num ficheiro que ninguém abre parece idêntico a um que nunca arrancou.

Depois reinicie uma vez e confirme que a unidade está ativa quando o dispositivo do túnel aparece. Uma correção verificada apenas com systemctl start não testou a ordem de arranque que devia reparar.