Un singur hook de somn nu readuce VPN-ul

Un hook care iese cu zero dovedește doar că scriptul a rulat. Puneți-l după rețea, folosiți identitatea corectă și verificați dacă profilul este măcar eligibil.

Puneți o comandă de reconectare în hook-ul de somn și problema pare rezolvată. Este rezolvată doar dacă hook-ul rulează după ce rețeaua există, ca o identitate pe care clientul o recunoaște, pe o cale pe care clientul o implementează cu adevărat. Majoritatea eșecurilor după revenire sunt una dintre acestea trei, și niciuna nu apare ca eroare în hook-ul însuși. Hook-ul returnează succes oricum.

Un script care iese cu zero nu v-a spus nimic despre dacă un tunel a revenit.

Hook-ul rulează, și apoi?

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

Fiecare eveniment apelează hook-ul de două ori, înainte și după tranziție, dându-i faza și numele evenimentului. Rulează ca root cu un mediu minim, așa că sunt necesare căi absolute și nu trebuie așteptată nicio variabilă de sesiune desktop. Întoarcerea rapidă a ambelor apeluri spune doar că scriptul a rulat. Dacă profilul a urcat după aceea este o observație separată și are nevoie de propria dovadă în jurnal.

Tratați argumentul fazei ca parte a designului. O încercare de reconectare în faza pre are loc în timp ce mașina este pe cale să piardă totul, și nu poate reuși.

Root, mediu minim, utilizator greșit

Dacă clientul păstrează tokenul de autentificare pentru fiecare utilizator, rularea hook-ului ca root îl lasă fără nimic de prezentat. Verificați starea sub identitatea pe care hook-ul o folosește efectiv, nu cea pe care ați testat-o dintr-un terminal de desktop. Unele compilări lasă după deconectare și un daemon care ține interfața, așa că reconectarea ajunge într-o stare învechită, iar curățarea procesului mai întâi o restabilește cu prețul unei opriri necurate. Niciunul dintre cele două comportamente nu este vizibil dacă testați doar calea fericită.

Scrieți hook-ul cu căi absolute, păstrați-l deținut de root și executabil, și înregistrați ce a făcut. Fără acel jurnal următoarea investigație începe de la zero.

Conexiunea automată nu este calea VPN

NetworkManager oferă două mecanisme de activare: un steag de conectare automată pe profil și conexiuni secundare care pornesc atunci când se activează un profil primar. Tipurile de dispozitiv native îl implementează pe primul; pluginurile VPN au implementat istoric doar al doilea, așa că bifarea conectării automate pe un profil OpenVPN poate să nu aibă niciun efect. Inspectați ambele proprietăți și apoi atașați VPN-ul ca secundar al profilului Wi-Fi sau Ethernet.

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

O interfață WireGuard gestionată de o unitate systemd are nevoie de acel fișier suplimentar în loc de hook, ordonat după ce rețeaua este online.

Așteptați rețeaua, cu un plafon

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"

La revenire, tunelul poate fi cerut în timp ce Wi-Fi încă se reasociază, ceea ce face din orice așteptare fixă o presupunere. Așteptați o adresă accesibilă, apoi ridicați profilul, și limitați așteptarea ca un hook să nu poată ține calea de revenire deschisă la nesfârșit. Preferați numele profilului în locul unui index numeric, și dacă profilul corect variază în funcție de rețea, lăsați tunelul sănătos să-și înregistreze alegerea într-un fișier dinainte.

Feriți-vă și de furtunile de repornire, numărând încercările și oprindu-vă. Un watchdog care reacționează la fiecare sondă eșuată transformă o pană într-o buclă.

Suspendați o dată, apoi citiți jurnalul pentru ieșirea propriului hook. Acesta este singurul test care dovedește ordinea.

Articole similare