Un hook de suspensión por sí solo no devuelve la VPN

Un hook que termina con cero solo demuestra que el script se ejecutó. Colóquelo después de la red, use la identidad correcta y compruebe si el perfil es siquiera apto.

Ponga un comando de reconexión en el hook de suspensión y el problema parece resuelto. Solo está resuelto si el hook se ejecuta después de que exista la red, con una identidad que el cliente reconozca, por una ruta que el cliente realmente implemente. La mayoría de los fallos tras la reanudación son uno de esos tres, y ninguno aparece como error en el propio hook. El hook devuelve éxito de todos modos.

Un script que termina con cero no le ha dicho nada sobre si volvió un túnel.

El hook se ejecuta, ¿y luego qué?

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

Cada evento invoca el hook dos veces, antes y después de la transición, y le pasa la fase y el nombre del evento. Se ejecuta como root con un entorno mínimo, así que hacen falta rutas absolutas y no debe esperarse ninguna variable de sesión de escritorio. Que ambas invocaciones vuelvan rápido solo dice que el script se ejecutó. Si el perfil subió después es una observación aparte y necesita su propia evidencia en el registro.

Trate el argumento de fase como parte del diseño. Un intento de reconexión en la fase pre ocurre mientras la máquina está a punto de perderlo todo, y no puede tener éxito.

Root, entorno mínimo, usuario equivocado

Si el cliente guarda su token de inicio de sesión por usuario, ejecutar el hook como root lo deja sin nada que presentar. Compruebe el estado bajo la identidad que el hook usa realmente, no la que probó desde un terminal de escritorio. Algunas compilaciones también dejan un demonio que retiene la interfaz tras una desconexión, así que la reconexión aterriza en un estado obsoleto, y limpiar el proceso primero lo restaura a costa de un apagado sucio. Ninguno de los dos comportamientos se ve si solo prueba el camino feliz.

Escriba el hook con rutas absolutas, manténgalo propiedad de root y ejecutable, y registre lo que hizo. Sin ese registro, la siguiente investigación empieza de cero.

La conexión automática no es la ruta de la VPN

NetworkManager ofrece dos mecanismos de activación: una marca de conexión automática en el perfil y conexiones secundarias que arrancan cuando se activa un perfil primario. Los tipos de dispositivo nativos implementan la primera; los complementos de VPN históricamente solo han implementado la segunda, así que marcar la conexión automática en un perfil OpenVPN puede no tener ningún efecto. Inspeccione ambas propiedades y luego adjunte la VPN como secundaria del perfil Wi-Fi o Ethernet.

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

Una interfaz WireGuard gestionada por una unidad de systemd necesita ese archivo adicional en lugar de un hook, ordenado después de que la red esté en línea.

Espere a la red, con un 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"

Al reanudar, el túnel puede pedirse mientras el Wi-Fi aún se reasocia, lo que convierte cualquier espera fija en una adivinanza. Espere una dirección alcanzable, luego suba el perfil y limite la espera para que un hook no pueda mantener la ruta de reanudación abierta indefinidamente. Prefiera el nombre del perfil a un índice numérico, y si el perfil correcto varía según la red, haga que el túnel sano registre su elección en un archivo de antemano.

Guárdese también de las tormentas de reinicio, contando intentos y deteniéndose. Un vigilante que reacciona a cada sonda fallida convierte una caída en un bucle.

Suspenda una vez y luego lea el registro en busca de la salida propia del hook. Esa es la única prueba que demuestra el orden.

Artículos relacionados