Per què mor OpenVPN després que l’ordinador portàtil es desperti?

Suspeneu la màquina, reprengueu-la i després comproveu tres coses en aquest ordre abans de tocar cap configuració: si tun0 encara existeix, si la ruta cap a una adreça interna encara el tria i si el servidor encara llista aquest peer. Un dispositiu que sobreviu a la suspensió mentre la ruta apunta a un altre lloc és una resta, no un túnel. Quan la ruta és correcta i el trànsit encara mor, la fallada és per sobre del túnel i reiniciar el client no la canviarà. Automatitzar un reinici només té sentit després que una prova manual hagi mostrat quin d’aquests tres casos teniu.

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

Reproduïu la represa abans d’automatitzar-la

La suspensió acaba la sessió xifrada més sovint del que elimina el dispositiu. El flux UDP que mantenia viu el túnel s’atura, el servidor pot descartar el peer i el client o bé se n’adona i es reconnecta o bé manté una interfície sense res al darrere. Una comprovació de la interfície per si sola demostra poc, perquè un dispositiu obsolet sembla exactament un de funcional fins que els paquets hi han de travessar. Executeu la consulta de ruta més una petició real a través del túnel i després llegiu el registre al voltant del moment de la represa.

Si el client torna sol, un hook afegeix moviment en lloc de fiabilitat. Si no es recupera mai, l’automatització és la solució honesta.

On viu realment un hook de suspensió de systemd

Moltes guies antigues apunten a /etc/pm/sleep.d, un directori propietat de pm-utils que una suspensió basada en systemd no consulta mai. systemd llegeix els hooks de /usr/lib/systemd/system-sleep/ i /etc/systemd/system-sleep/, passant primer la fase i després l’operació, de manera que pre i post són els únics valors sobre els quals un hook es ramifica. Manteniu la còpia local sota /etc en lloc d’editar un fitxer empaquetat i recordeu que l’script s’executa com a root al mig de la transició, així que ha de retornar de pressa.

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

try-restart només toca una unitat quan ja és activa, així que un túnel que heu aturat a propòsit continua aturat durant la represa. --no-block evita que el hook esperi mentre el client negocia, cosa que importa quan la xarxa encara no ha pujat. Junts, els dos indicadors signifiquen un hook que falla en silenci en lloc de retenir tota la seqüència de represa. Quan la unitat ja està aturada no passa absolutament res, que és exactament el resultat que voleu allà.

Recupereu el servei, deixeu tun0 tranquil

Baixar tun0 a mà deixa el dimoni supervisant una interfície que ja no posseeix, i el següent canvi d’estat produeix errors confusos. Apunteu al servei o al seu perfil de connexió en lloc de la interfície; comproveu primer el nom exacte de la unitat, perquè els paquets de distribució, OpenVPN 3 i NetworkManager trien noms diferents. Un perfil de NetworkManager torna quan es recicla aquesta connexió, així que la unitat de systemd no és l’objectiu allà. Sigui quin sigui el mecanisme, hauria de ser la mateixa acció que vau verificar a mà.

Un reinici reinstal·la les rutes que el client va empènyer en connectar-se. La majoria de represes volen això. Una màquina on heu afegit camins propis no, així que torneu a comprovar-los en lloc de suposar que la recuperació els ha restaurat, i escriviu-los on la propera represa els pugui trobar.

Gestioneu el moment que no podeu controlar

L’associació sense fil i el DHCP sovint acaben després que el hook s’hagi executat, així que un reinici pot fallar mentre encara no hi ha cap camí cap al servidor. Espereu breument aquesta adreça, torneu-ho a provar una vegada i registreu el resultat.

La resolució de noms és una cursa a part, perquè la pila de xarxa de l’escriptori pot restaurar el DNS després que el túnel ja estigui aixecat. Proveu les consultes per separat amb resolvectl query internal.example en lloc d’inferir-les d’una ruta funcional. Un túnel que encamina correctament i no resol res és un problema de DNS, no un problema del hook.

Manteniu visible la decisió del hook escrivint la fase, el nom de la unitat i el resultat al registre. Anoteu a les notes de la màquina quina prova de represa heu executat, perquè una recuperació funcional es pugui distingir d’una de sort. Trieu l’acció menys disruptiva que torni el servei i deixeu que un client que es recupera sol ho faci. Un reinici complet descarta les sessions en curs, que és un cost real en un portàtil que es reprèn diverses vegades al dia.