Um hook de suspensão sozinho não traz a VPN de volta

Um hook que termina com zero só prova que o script rodou. Coloque-o depois da rede, use a identidade certa e verifique se o perfil é sequer elegível.

Coloque um comando de reconexão no hook de suspensão e o problema parece resolvido. Só fica resolvido se o hook rodar depois que a rede existe, com uma identidade que o cliente reconhece, por um caminho que o cliente realmente implementa. A maioria das falhas após a retomada é uma dessas três, e nenhuma delas aparece como erro no próprio hook. O hook retorna sucesso de qualquer forma.

Um script que termina com zero não disse nada sobre se um túnel voltou.

O hook roda, e depois?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

Cada evento chama o hook duas vezes, antes e depois da transição, passando a fase e o nome do evento. Ele roda como root com um ambiente mínimo, então são necessários caminhos absolutos e nenhuma variável de sessão de desktop deve ser esperada. O retorno rápido das duas chamadas diz apenas que o script rodou. Se o perfil subiu depois é uma observação separada e precisa da própria evidência no log.

Trate o argumento de fase como parte do projeto. Uma tentativa de reconexão na fase pre acontece enquanto a máquina está prestes a perder tudo, e não pode dar certo.

Root, ambiente mínimo, usuário errado

Se o cliente guarda o token de login por usuário, rodar o hook como root o deixa sem nada a apresentar. Verifique o estado sob a identidade que o hook realmente usa, não a que você testou em um terminal de desktop. Algumas compilações também deixam um daemon segurando a interface após uma desconexão, então a reconexão cai em um estado obsoleto, e limpar o processo antes o restaura ao custo de um desligamento sujo. Nenhum dos dois comportamentos aparece se você testar apenas o caminho feliz.

Escreva o hook com caminhos absolutos, mantenha-o como propriedade de root e executável, e registre o que ele fez. Sem esse log a próxima investigação começa do zero.

A conexão automática não é o caminho da VPN

O NetworkManager oferece dois mecanismos de ativação: uma flag de conexão automática no perfil e conexões secundárias que iniciam quando um perfil primário é ativado. Tipos de dispositivo nativos implementam o primeiro; plugins de VPN historicamente implementaram apenas o segundo, então marcar a conexão automática em um perfil OpenVPN pode não ter efeito nenhum. Inspecione as duas propriedades e depois anexe a VPN como secundária do perfil Wi-Fi ou Ethernet.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

Uma interface WireGuard gerenciada por uma unidade do systemd precisa desse arquivo adicional em vez de um hook, ordenada depois que a rede estiver online.

Espere a rede, com um teto

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

Ao retomar, o túnel pode ser solicitado enquanto o Wi-Fi ainda reassocia, o que torna qualquer espera fixa um palpite. Espere um endereço alcançável, depois suba o perfil, e limite a espera para que um hook não possa manter o caminho de retomada aberto indefinidamente. Prefira o nome do perfil a um índice numérico, e se o perfil correto variar conforme a rede, faça o túnel saudável registrar sua escolha em um arquivo de antemão.

Proteja-se também de tempestades de reinício, contando tentativas e parando. Um watchdog que reage a cada sondagem falha transforma uma queda em um laço.

Suspenda uma vez e depois leia o journal para ver a saída do próprio hook. Esse é o único teste que prova a ordenação.

Artigos relacionados