Por que o OpenVPN morre depois que o portátil acorda?

A suspensão pode matar a sessão do OpenVPN e deixar o tun0 para trás. Teste o túnel e depois reinicie a unidade a partir de um hook de suspensão do systemd, não o dispositivo.

Suspenda a máquina, acorde-a e verifique então três coisas nesta ordem antes de tocar em qualquer configuração: se o tun0 ainda existe, se a rota para um endereço interno ainda o escolhe e se o servidor ainda lista esse peer. Um dispositivo que sobrevive à suspensão enquanto a rota aponta para outro lugar é um resto, não um túnel. Quando a rota está certa e o tráfego morre mesmo assim, a falha está acima do túnel e reiniciar o cliente não vai mudá-la. Automatizar um reinício só faz sentido depois que um teste manual mostrou qual desses três casos você tem.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Reproduza o despertar antes de automatizá-lo

A suspensão encerra a sessão cifrada com mais frequência do que remove o dispositivo. O fluxo UDP que mantinha o túnel vivo para, o servidor pode descartar o peer e o cliente ou percebe e reconecta ou mantém uma interface sem nada atrás. Uma verificação da interface por si só prova pouco, porque um dispositivo obsoleto parece exatamente um que funciona até que os pacotes tenham de atravessá-lo. Execute a consulta de rota mais uma requisição real pelo túnel e depois leia o registro em torno do momento do despertar.

Se o cliente volta sozinho, um hook acrescenta transtorno em vez de confiabilidade. Se nunca se recupera, a automação é a solução honesta.

Onde vive de fato um hook de suspensão do systemd

Muitos guias antigos apontam para /etc/pm/sleep.d, um diretório de propriedade do pm-utils que uma suspensão baseada em systemd nunca consulta. O systemd lê hooks em /usr/lib/systemd/system-sleep/ e /etc/systemd/system-sleep/, passando primeiro a fase e depois a operação, então pre e post são os únicos valores nos quais um hook se ramifica. Mantenha a cópia local em /etc em vez de editar um arquivo empacotado e lembre-se de que o script roda como root no meio da transição, então precisa retornar rápido.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart só mexe numa unidade quando ela já está ativa, então um túnel que você desligou de propósito continua desligado durante o despertar. --no-block impede o hook de esperar enquanto o cliente negocia, o que importa quando a rede ainda não subiu. Juntas, as duas opções significam um hook que falha em silêncio em vez de segurar toda a sequência de despertar. Quando a unidade já está parada, não acontece absolutamente nada, que é exatamente o resultado que você quer ali.

Recupere o serviço, deixe o tun0 em paz

Baixar o tun0 à mão deixa o daemon supervisionando uma interface que já não possui, e a próxima mudança de estado produz erros confusos. Mire no serviço ou no perfil de conexão dele em vez da interface; confira primeiro o nome exato da unidade, porque os pacotes de distribuição, o OpenVPN 3 e o NetworkManager escolhem nomes diferentes. Um perfil do NetworkManager volta quando aquela conexão é reciclada, então a unidade do systemd não é o alvo ali. Seja qual for o mecanismo, deve ser a mesma ação que você verificou à mão.

Um reinício reinstala as rotas que o cliente empurrou ao conectar. A maioria dos despertares quer isso. Uma máquina em que você adicionou rotas próprias não, então verifique essas de novo em vez de supor que a recuperação as restaurou, e anote-as onde o próximo despertar possa encontrá-las.

Lide com o tempo que você não controla

A associação sem fio e o DHCP muitas vezes terminam depois que o hook já rodou, então um reinício pode falhar enquanto ainda não existe caminho até o servidor. Espere brevemente por esse endereço, tente mais uma vez e registre o resultado.

A resolução de nomes é uma corrida separada, porque a pilha de rede do desktop pode restaurar o DNS depois que o túnel já subiu. Teste as consultas separadamente com resolvectl query internal.example em vez de deduzi-las de uma rota funcional. Um túnel que roteia corretamente e não resolve nada é um problema de DNS, não um problema de hook.

Mantenha a decisão do hook visível escrevendo a fase, o nome da unidade e o resultado no registro. Anote nas notas da máquina qual teste de despertar você executou, para que uma recuperação funcional se distinga de uma sortuda. Escolha a ação menos disruptiva que devolva o serviço e deixe que um cliente que se recupera sozinho o faça. Um reinício completo derruba sessões em andamento, o que é um custo real num portátil que desperta várias vezes por dia.

Artigos relacionados