Por que o seu cliente OpenVPN fica parado depois de um único tempo limite

Segunda-feira de manhã: o túnel que subiu na sexta desapareceu, a interface ainda está listada e nada no registro diz que alguém notou. O host está online, o painel está verde e tudo o que ele enviou no fim de semana saiu pela interface física. Aqui faltam duas decisões independentes: uma sobre se o processo do cliente sobrevive a uma falha transitória e outra sobre se algo acima dele reinicia o processo depois que ele sai. Corrigir apenas uma deixa a outra lacuna aberta.

Comece pelo que a unidade realmente fez, não pelo que o monitoramento afirma. systemctl status openvpn-client@office e journalctl -u openvpn-client@office -n 50 mostram o motivo da saída e a última linha que o cliente escreveu antes de partir.

O processo saiu antes de alguém notar

Um cliente que desaparece sem erro normalmente saiu de propósito. O perfil decide esse comportamento, não o gerenciador de serviços: ping-exit encerra o processo assim que o par para de responder, enquanto ping-restart mantém o processo e se reconecta dentro dele. Limites de sessão e temporizadores de inatividade produzem a mesma imagem de fora: sem túnel e sem alarme.

As duas diretivas ping não podem aparecer juntas em um único perfil, então escolha uma e registre a escolha. Olhe também o servidor, porque o ping-exit dele próprio fecha uma sessão independentemente do que o cliente pediu, e só o log do servidor registra quem tomou essa decisão.

Escolher entre ping-exit e ping-restart

Escolha ping-restart para um portátil ou um local remoto que precise se curar sozinho, e reserve ping-exit para casos em que um túnel morto precise parar o processo para que outra coisa possa agir sobre ele. Os números importam menos que a relação: ping 10 com ping-restart 60 significa dez segundos de silêncio antes de uma sondagem e sessenta antes do reinício, o que é agressivo num link móvel com perdas e razoável num cabo. Escreva o motivo ao lado da linha, porque, caso contrário, o próximo leitor assumirá que os valores padrão foram deliberados.

Depois confirme que o que saiu é realmente o processo. Uma unidade que relata atividade enquanto o túnel está morto é outra falha, tratada mais abaixo.

Supervisão que realmente reinicia a unidade

Num host systemd, a menor mudança durável é um único arquivo drop-in: Restart=on-failure e RestartSec=10 em /etc/systemd/system/[email protected]/restart.conf. Um drop-in só é lido quando o systemd recarrega as suas próprias definições, então execute systemctl daemon-reload depois. Verifique com systemctl show -p Restart -p ExecMainStatus openvpn-client@office em vez de presumir que o valor chegou. A instância no nome do arquivo tem de ser o perfil que a unidade realmente carrega, então um arquivo escrito para office não faz nada por openvpn-client@home.

on-failure ignora um caso: uma saída limpa com status zero. Alguns caminhos de desmontagem terminam assim, então leia o status registrado em vez de confiar na redação de uma página de manual. Se o seu cliente desistir com um zero, precisa de Restart=always, e o custo é que um perfil realmente quebrado volta repetidamente até o limite de taxa de arranque atuar e o registro encher.

Restart=always também dispara depois de uma parada deliberada. Use systemctl stop para manutenção e mascare a unidade se ela tiver de ficar parada enquanto trabalha.

Pegar a fuga enquanto o túnel está parado

A supervisão faz o túnel voltar; não impede que o tráfego saia enquanto o túnel está ausente. persist-tun mantém o dispositivo e as suas rotas entre reconexões, o que é conveniente e abre uma janela. O dispositivo sobrevive, as rotas ainda apontam para ele e os pacotes saem sem proteção e sem relato. É uma escolha de política, não um valor padrão neutro.

Quando um host não pode emitir pacotes sem proteção de forma alguma, só a firewall o pode garantir. Uma regra de saída que permite a interface do túnel e o endereço do servidor VPN enquanto descarta tudo o resto continua válida depois de o cliente morrer, e nada na configuração do próprio cliente pode filtrar tráfego que o cliente não transporta.

Teste-o parando o cliente de propósito. Execute systemctl stop openvpn-client@office, depois curl -m 5 https://example.com, que deve falhar em vez de funcionar pelo link físico. Um sucesso significa que a regra da firewall falta ou é demasiado permissiva.

Reconecte, confirme que o túnel volta a transportar tráfego e só então acrescente a verificação ao monitoramento. Sondar ip addr a partir do cron para um dispositivo tun é a supervisão que falha com mais frequência, porque com persist-tun o dispositivo sobrevive à sessão e a sonda relata saúde enquanto nada é transportado.