Un hook de suspensión por si só non devolve a VPN

Un hook que sae con cero só demostra que o script se executou. Colóqueo despois da rede, use a identidade correcta e comprobe se o perfil é sequera apto.

Poña un comando de reconexión no hook de suspensión e o problema parece resolto. Só está resolto se o hook se executa despois de que exista a rede, cunha identidade que o cliente recoñeza, por unha ruta que o cliente realmente implemente. A maioría dos fallos tras a reanudación son un deses tres, e ningún aparece como erro no propio hook. O hook devolve éxito de todos os xeitos.

Un script que sae con cero non lle dixo nada sobre se volveu un túnel.

O hook execútase, e logo que?

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

Cada evento invoca o hook dúas veces, antes e despois da transición, e pásalle a fase e o nome do evento. Execútase como root cun ambiente mínimo, así que fan falta rutas absolutas e non debe esperarse ningunha variable de sesión de escritorio. Que ambas as invocacións volvan rápido só di que o script se executou. Se o perfil subiu despois é unha observación aparte e necesita a súa propia evidencia no rexistro.

Trate o argumento de fase como parte do deseño. Un intento de reconexión na fase pre ocorre mentres a máquina está a piques de perdelo todo, e non pode ter éxito.

Root, ambiente mínimo, usuario equivocado

Se o cliente garda o token de inicio de sesión por usuario, executar o hook como root déixao sen nada que presentar. Comprobe o estado baixo a identidade que o hook usa realmente, non a que probou desde un terminal de escritorio. Algunhas compilacións tamén deixan un daemon que retén a interface tras unha desconexión, así que a reconexión aterra nun estado obsoleto, e limpar o proceso primeiro restáurao a costa dun apagado sucio. Ningún dos dous comportamentos se ve se só proba o camiño feliz.

Escriba o hook con rutas absolutas, mantéñao propiedade de root e executable, e rexistre o que fixo. Sen ese rexistro a seguinte investigación comeza de cero.

A conexión automática non é a ruta da VPN

NetworkManager ofrece dous mecanismos de activación: unha marca de conexión automática no perfil e conexións secundarias que arrincan cando se activa un perfil primario. Os tipos de dispositivo nativos implementan a primeira; os complementos de VPN historicamente só implementaron a segunda, así que marcar a conexión automática nun perfil OpenVPN pode non ter ningún efecto. Inspeccione ambas as propiedades e despois anexe a VPN como secundaria do perfil Wi-Fi ou Ethernet.

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

Unha interface WireGuard xestionada por unha unidade de systemd necesita ese ficheiro adicional en lugar dun hook, ordenado despois de que a rede estea en liña.

Espere a rede, cun límite

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 reanudar, o túnel pode pedirse mentres o Wi-Fi aínda se reasocia, o que fai de calquera espera fixa unha adiviñanza. Espere un enderezo alcanzable, despois suba o perfil e limite a espera para que un hook non poida manter a ruta de reanudación aberta indefinidamente. Prefira o nome do perfil a un índice numérico, e se o perfil correcto varía segundo a rede, faga que o túnel san rexistre a súa elección nun ficheiro de antemán.

Gárdese tamén das tormentas de reinicio, contando intentos e deténdose. Un vixiante que reacciona a cada sonda fallida converte unha caída nun bucle.

Suspenda unha vez e despois lea o rexistro para ver a saída propia do hook. Esa é a única proba que demostra a orde.

Artigos relacionados