Egy alvó-hook önmagában nem hozza vissza a VPN-t

Egy nullával kilépő hook csak azt bizonyítja, hogy a szkript lefutott. Helyezze a hálózat után, használja a megfelelő identitást, és ellenőrizze, hogy a profil egyáltalán alkalmas-e.

Tegyen újracsatlakozási parancsot az alvó-hookba, és a probléma megoldottnak tűnik. Csak akkor megoldott, ha a hook a hálózat létezése után fut, olyan identitásként, amelyet a kliens felismer, olyan útvonalon, amelyet a kliens valóban megvalósít. A folytatás utáni hibák többsége e három egyike, és egyik sem jelenik meg hibaként magában a hookban. A hook így is sikert ad vissza.

Egy nullával kilépő szkript semmit sem mondott arról, hogy visszatért-e egy alagút.

A hook lefut, és aztán?

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

Minden esemény kétszer hívja meg a hookot, az átmenet előtt és után, átadva neki a fázist és az esemény nevét. Rootként fut minimális környezetben, ezért abszolút útvonalakra van szükség, és semmilyen asztali munkamenet-változóra nem kell számítani. Az, hogy mindkét hívás gyorsan visszatér, csak azt mondja, hogy a szkript lefutott. Hogy utána feljött-e a profil, az külön megfigyelés, és saját bizonyítékot igényel a naplóban.

Tekintse a fázis argumentumot a tervezés részének. Az újracsatlakozási kísérlet a pre fázisban akkor történik, amikor a gép mindent elveszíteni készül, és nem sikerülhet.

Root, minimális környezet, rossz felhasználó

Ha a kliens felhasználónként tartja a bejelentkezési tokent, a hook rootként futtatva semmit sem tud felmutatni. Az állapotot azon identitás alatt ellenőrizze, amelyet a hook ténylegesen használ, nem azon, amelyet asztali terminálból tesztelt. Egyes buildek leválasztás után egy démont is hagynak, amely fogja az interfészt, így az újracsatlakozás elavult állapotba kerül, és a folyamat előzetes tisztítása tisztátlan leállítás árán állítja helyre. Egyik viselkedés sem látszik, ha csak a boldog utat teszteli.

Írja a hookot abszolút útvonalakkal, tartsa root tulajdonban és futtathatóként, és naplózza, mit tett. E napló nélkül a következő vizsgálat nulláról indul.

Az automatikus csatlakozás nem a VPN útja

A NetworkManager két aktiválási mechanizmust kínál: egy automatikus csatlakozás jelzőt a profilon, és másodlagos kapcsolatokat, amelyek akkor indulnak, amikor egy elsődleges profil aktiválódik. A natív eszköztípusok az elsőt valósítják meg; a VPN-bővítmények történelmileg csak a másodikat valósították meg, ezért az automatikus csatlakozás bejelölése egy OpenVPN profilon egyáltalán nem hathat. Vizsgálja meg mindkét tulajdonságot, majd inkább csatolja a VPN-t a Wi-Fi vagy Ethernet profil másodlagosaként.

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

A systemd-egység által kezelt WireGuard-interfésznek erre a drop-inre van szüksége hook helyett, a hálózat online állapota után sorolva.

Várjon a hálózatra, felső korláttal

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"

Folytatáskor az alagutat akkor is kérhetik, amikor a Wi-Fi még újra csatlakozik, ami minden rögzített alvást találgatássá tesz. Várjon egy elérhető címre, majd hozza fel a profilt, és korlátozza a várakozást, hogy egy hook ne tarthassa végtelenül nyitva a folytatás útvonalát. Részesítse előnyben a profil nevét egy numerikus indexszel szemben, és ha a helyes profil hálózatonként változik, az egészséges alagút előre írja le a választását egy fájlba.

Az újraindítási viharok ellen is védekezzen a kísérletek számolásával és leállításával. Az a watchdog, amely minden sikertelen próbára reagál, egy kiesést hurokká tesz.

Egyszer függessze fel a rendszert, majd olvassa el a naplóban a hook saját kimenetét. Csak ez a teszt bizonyítja a sorrendet.

Kapcsolódó cikkek