Por que morre OpenVPN cando o portátil esperta?

Suspende a máquina, reanúdaa e despois comproba tres cousas nesta orde antes de tocar calquera configuración: se tun0 aínda existe, se a ruta cara a un enderezo interno aínda o escolle e se o servidor aínda lista este peer. Un dispositivo que sobrevive á suspensión mentres a ruta apunta a outro sitio é un resto, non un túnel. Cando a ruta é correcta e o tráfico morre igualmente, a avaría está por riba do túnel e reiniciar o cliente non a cambiará. Automatizar un reinicio só ten sentido despois de que unha proba manual mostrase cal deses tres casos tes.

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

Reproduce a reanudación antes de automatizala

A suspensión remata a sesión cifrada máis a miúdo do que elimina o dispositivo. O fluxo UDP que mantén vivo o túnel detense, o servidor pode descartar o peer e o cliente ou ben o nota e reconecta ou ben conserva unha interface sen nada detrás. Unha comprobación da interface por si soa demostra pouco, porque un dispositivo obsoleto parece exactamente un que funciona ata que os paquetes teñen que atravesalo. Executa a consulta de ruta máis unha petición real a través do túnel e despois le o rexistro arredor do momento da reanudación.

Se o cliente volve só, un hook engade axitación en lugar de fiabilidade. Se nunca se recupera, a automatización é a solución honesta.

Onde vive realmente un hook de suspensión de systemd

Moitas guías antigas apuntan a /etc/pm/sleep.d, un directorio propiedade de pm-utils que unha suspensión baseada en systemd nunca consulta. systemd le os hooks de /usr/lib/systemd/system-sleep/ e /etc/systemd/system-sleep/, pasando primeiro a fase e despois a operación, así que pre e post son os únicos valores sobre os que un hook se ramifica. Mantén a copia local baixo /etc en lugar de editar un ficheiro empaquetado e lembra que o script se executa como root no medio da transición, así que debe volver rápido.

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

try-restart só toca unha unidade cando xa está activa, así que un túnel que detiveches a propósito segue detido durante a reanudación. --no-block evita que o hook espere mentres o cliente negocia, o que importa cando a rede aínda non subiu. Xuntos, os dous indicadores significan un hook que falla en silencio en lugar de reter toda a secuencia de reanudación. Cando a unidade xa está parada non ocorre absolutamente nada, que é exactamente o resultado que queres aí.

Recupera o servizo, deixa tun0 en paz

Baixar tun0 á man deixa o daemon supervisando unha interface que xa non posúe, e o seguinte cambio de estado produce erros confusos. Apunta ao servizo ou ao seu perfil de conexión en lugar de á interface; comproba primeiro o nome exacto da unidade, porque os paquetes de distribución, OpenVPN 3 e NetworkManager elixen nomes distintos. Un perfil de NetworkManager volve cando se recicla esa conexión, así que a unidade de systemd non é o obxectivo alí. Calquera que sexa o mecanismo, debería ser a mesma acción que verificaches á man.

Un reinicio reinstala as rutas que o cliente empuxou ao conectarse. A maioría de reanudacións queren iso. Unha máquina onde engadiches rutas propias non, así que volve comprobalas en lugar de supoñer que a recuperación as restaurou, e escríbeas onde a seguinte reanudación poida atopalas.

Xestiona o momento que non podes controlar

A asociación inalámbrica e DHCP a miúdo terminan despois de que o hook se executou, así que un reinicio pode fallar mentres aínda non existe camiño ao servidor. Espera brevemente ese enderezo, reintenta unha vez e rexistra o resultado.

A resolución de nomes é unha carreira aparte, porque a pila de rede do escritorio pode restaurar o DNS despois de que o túnel xa estea arriba. Proba as consultas por separado con resolvectl query internal.example en lugar de deducilas dunha ruta funcional. Un túnel que encamiña correctamente e non resolve nada é un problema de DNS, non un problema do hook.

Mantén visible a decisión do hook escribindo a fase, o nome da unidade e o resultado no rexistro. Anota nas notas da máquina que proba de reanudación executaches, para que unha recuperación funcional se distinga dunha afortunada. Escolle a acción menos disruptiva que devolva o servizo e deixa que un cliente que se recupera só o faga. Un reinicio completo descarta as sesións en curso, que é un custo real nun portátil que se reanuda varias veces ao día.