Un hook de suspensió sol no recupera la VPN

Un hook que surt amb zero només demostra que el script s'ha executat. Ordeneu-lo després de la xarxa, feu servir la identitat correcta i comproveu si el perfil és apte.

Poseu una ordre de reconnexió al hook de suspensió i el problema sembla resolt. Només es resol si el hook s'executa després que existeixi la xarxa, amb una identitat que el client reconegui, per un camí que el client implementi de veritat. La majoria de fallades després de reprendre són una d'aquestes tres, i cap no apareix com a error al mateix hook. El hook retorna èxit igualment.

Un script que surt amb zero no us ha dit res sobre si un túnel ha tornat.

El hook s'executa, i després què?

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

Cada esdeveniment invoca el hook dues vegades, abans i després de la transició, i li passa la fase i el nom de l'esdeveniment. S'executa com a root amb un entorn mínim, així que calen camins absoluts i no s'ha d'esperar cap variable de sessió d'escriptori. Que les dues invocacions tornin de pressa només diu que el script s'ha executat. Si el perfil s'ha aixecat després és una observació a part i necessita la seva pròpia evidència al registre.

Tracteu l'argument de fase com a part del disseny. Un intent de reconnexió a la fase pre passa quan la màquina està a punt de perdre-ho tot, i no pot tenir èxit.

Root, entorn mínim, usuari equivocat

Si el client guarda el testimoni d'inici de sessió per usuari, executar el hook com a root el deixa sense res a presentar. Comproveu l'estat sota la identitat que el hook fa servir de veritat, no la que vau provar des d'un terminal d'escriptori. Algunes compilacions també deixen un dimoni que reté la interfície després d'una desconnexió, així que la reconnexió cau en un estat obsolet, i netejar el procés primer ho restaura a costa d'un tancament brut. Cap dels dos comportaments no es veu si només proveu el camí feliç.

Escriviu el hook amb camins absoluts, manteniu-lo propietat de root i executable, i registreu què ha fet. Sense aquest registre la investigació següent comença de zero.

La connexió automàtica no és el camí de la VPN

NetworkManager ofereix dos mecanismes d'activació: una marca de connexió automàtica al perfil, i connexions secundàries que arrenquen quan s'activa un perfil primari. Els tipus de dispositiu natius implementen el primer; els connectors de VPN històricament només han implementat el segon, així que marcar la connexió automàtica en un perfil OpenVPN pot no tenir cap efecte. Inspeccioneu les dues propietats i, en lloc d'això, adjunteu la VPN com a secundària del perfil Wi-Fi o Ethernet.

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

Una interfície WireGuard gestionada per una unitat de systemd necessita aquest fitxer addicional en lloc d'un hook, ordenat després que la xarxa estigui en línia.

Espereu la xarxa, amb un límit

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"

En reprendre, el túnel es pot demanar mentre el Wi-Fi encara es reassocia, cosa que fa de qualsevol espera fixa una endevinalla. Espereu una adreça abastable, després aixequen el perfil, i limiteu l'espera perquè un hook no pugui mantenir el camí de represa obert indefinidament. Preferiu el nom del perfil a un índex numèric, i si el perfil correcte varia segons la xarxa, feu que el túnel saludable registri la seva tria en un fitxer per endavant.

Guardeu-vos també de les tempestes de reinici, comptant intents i aturant. Un vigilant que reacciona a cada sonda fallida converteix una caiguda en un bucle.

Suspeneu un cop, després llegiu el registre per veure la sortida pròpia del hook. Aquesta és l'única prova que demostra l'ordenació.

Articles relacionats