Miért hal meg az OpenVPN, amikor a laptop felébred?

Az alvás megölheti az OpenVPN-munkamenetet, miközben a tun0 megmarad. Teszteld az alagutat, majd indítsd újra az egységet egy systemd alvás-hookból, ne az eszközt.

Altasd el a gépet, ébreszd fel, majd ellenőrizz három dolgot ebben a sorrendben, mielőtt bármilyen konfigurációhoz nyúlnál: hogy a tun0 még létezik-e, hogy a belső címhez vezető útvonal még mindig azt választja-e, és hogy a szerver még mindig listázza-e ezt a peert. Az az eszköz, amely túléli az alvást, miközben az útvonal máshová mutat, maradvány, nem alagút. Amikor az útvonal helyes, és a forgalom mégis meghal, a hiba az alagút felett van, és az ügyfél újraindítása nem változtat rajta. Az újraindítás automatizálásának csak azután van értelme, hogy egy kézi teszt megmutatta, melyik a három eset közül.

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

Reprodukáld az ébredést, mielőtt automatizálod

Az alvás gyakrabban zárja le a titkosított munkamenetet, mint ahányszor eltávolítja az eszközt. Leáll az UDP-folyam, amely életben tartotta az alagutat, a szerver eldobhatja a peert, és az ügyfél vagy észleli és újracsatlakozik, vagy megtart egy interfészt, amely mögött nincs semmi. Az interfész önmagában való ellenőrzése keveset bizonyít, mert egy elavult eszköz pontosan úgy néz ki, mint egy működő amíg a csomagoknak át kell haladniuk rajta. Futtasd az útvonalkeresést és egy valódi kérést az alagúton keresztül, majd olvasd el a naplót az ébredés pillanata körül.

Ha az ügyfél magától visszatér, a hook inkább nyűgöt ad, mint megbízhatóságot. Ha soha nem áll helyre, az automatizálás az őszinte megoldás.

Hol él valójában a systemd alvás-hook

Sok régebbi útmutató a /etc/pm/sleep.d könyvtárra mutat, amely a pm-utils tulajdona, és amelyet a systemd-alapú alvás soha nem kérdez. A systemd a /usr/lib/systemd/system-sleep/ és a /etc/systemd/system-sleep/ könyvtárakból olvassa a hookokat, először a fázist, majd a műveletet adva át, ezért a pre és a post az egyetlen érték, amelyre egy hook elágazik. Tartsd a helyi példányt a /etc alatt, ahelyett hogy egy csomagolt fájlt szerkesztenél, és ne feledd, hogy a szkript rootként fut az átmenet közepén, ezért gyorsan vissza kell térnie.

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

A try-restart csak akkor nyúl egy egységhez, ha az már aktív, ezért egy szándékosan leállított alagút az ébredés során is leállítva marad. A --no-block megakadályozza, hogy a hook várakozzon, miközben az ügyfél tárgyal, ami akkor számít, amikor a hálózat még nem állt fel. Együtt a két kapcsoló olyan hookot jelent, amely csendben meghiúsul, ahelyett hogy visszatartaná a teljes ébredési sorrendet. Ha az egység már le van állítva, egyáltalán semmi nem történik, ami pontosan az az eredmény, amit ott szeretnél.

Állítsd helyre a szolgáltatást, hagyd békén a tun0-t

A tun0 kézi leállítása a démont olyan interfész felügyeletében hagyja, amely már nem az övé, és a következő állapotváltozás zavaros hibákat okoz. A szolgáltatást vagy annak kapcsolati profilját célozd az interfész helyett; előbb ellenőrizd az egység pontos nevét, mert a disztribúciós csomagok, az OpenVPN 3 és a NetworkManager mind mást választanak. A NetworkManager-profil akkor tér vissza, amikor azt a kapcsolatot újraciklizálják, tehát ott nem a systemd egység a cél. Bármi is a mechanizmus, ugyanannak a műveletnek kell lennie, amit kézzel ellenőriztél.

Az újraindítás újratelepíti azokat az útvonalakat, amelyeket az ügyfél a csatlakozáskor betolt. A legtöbb ébredés ezt akarja. Az a gép, ahol saját útvonalakat adtál hozzá, nem, ezért azokat ellenőrizd újra, ahelyett hogy feltételeznéd, hogy a helyreállítás visszatette őket, és írd le őket ott, ahol a következő ébredés megtalálhatja őket.

Kezeld az időzítést, amit nem tudsz irányítani

A vezeték nélküli társítás és a DHCP gyakran a hook lefutása után fejeződik be, ezért az újraindítás meghiúsulhat, miközben még nincs út a szerverhez. Várj röviden arra a címre, próbáld újra egyszer, és naplózd az eredményt.

A névfeloldás külön verseny, mert az asztali hálózati verem csak azután állíthatja helyre a DNS-t, hogy az alagút már fent van. A lekérdezéseket külön teszteld a resolvectl query internal.example paranccsal, ahelyett hogy egy működő útvonalból következtetnél rájuk. Az az alagút, amely helyesen irányít és semmit nem old fel, DNS-probléma, nem hook-probléma.

Tartsd láthatóvá a hook döntését azzal, hogy a fázist, az egység nevét és az eredményt a naplóba írod. Jegyezd fel a gép jegyzeteibe, melyik ébredési tesztet futtattad, hogy egy működő helyreállítás megkülönböztethető legyen egy szerencséstől. Válaszd a legkevésbé zavaró műveletet, amely visszahozza a szolgáltatást, és hagyd, hogy egy magától helyreálló ügyfél tegye meg. A teljes újraindítás eldobja a folyamatban lévő munkameneteket, ami valódi költség egy naponta többször felébredő laptopon.

Kapcsolódó cikkek