Használhatja egy OpenVPN hook-szkript az éppen épített alagutat?

Az, hogy egy hook-szkript eléri-e az alagút túloldalát, három feltételtől függ: melyik eseményhez van csatolva, az OpenVPN még a saját indítási sorozatában van-e a szkript futásakor, és a munka le van-e választva arról a sorozatról. A legtöbb szkript a harmadikon bukik el. Egy alvás hozzáadása életciklus-problémát kezel időzítési problémaként, és éppen elég gyakran működik ahhoz, hogy félrevezessen.

Először döntse el az eseményt, aztán a munka elhalasztásának mechanizmusát, aztán azt a helyet, ahol az elhalasztott munka fut. Ez a három döntés független, és összekeverésük az, amitől egy kétsoros hook egy egész délutánná válik.

Miért vár a hook egy rá várakozó alagútra

OpenVPN szinkron módon hívja a hookjait, ugyanabban a folyamatban, amely a csomagokat mozgatja. up akkor fut le, amikor a tun vagy tap eszköz létezik, de még egyetlen útvonal hozzáadása előtt, route-up pedig az útvonalak után; egyik pillanat sem ígéri, hogy a partner válaszol. Amíg bármelyik hook szkriptje fut, a démon nem továbbít, ezért az a parancs, amely elvárja, hogy a forgalom átkeljen az alagúton, egy olyan alagútra vár, amely a parancsra vár. Ez a körkörös várakozás az oka, hogy egy kézi futtatás átmegy, a hook pedig időtúllépésbe fut.

A kézenfekvő folt, néhány másodperc alvás, néha azért működik, mert a távoli vég magától felállt, nem azért, mert az alvás bármit is megjavított. Egy készenlétet kérdező segéd más válasz: a hook visszatér, a továbbítás elkezdődik, és a segéd megkapja, amire szüksége van, amikor az valóban ott van.

Esemény szerint válassza a hookot, ne kényelem szerint

Csatolja a up-t a csak az eszközt igénylő munkához, a route-up-at az útvonalakat igénylő munkához, és tartsa a client-connect-et és a client-disconnect-öt a kiszolgálóoldali ügyfélenkénti feladatokhoz. A bontáskor végzett tisztításnak el kell viselnie a kétszeri futást, mert az állandó interfészen át történő újracsatlakozás nem ugyanazt a sorrendet követi, mint egy teljes újraindítás. A kiszolgálón a client-connect akkor fut le, amikor az ügyfél hitelesíti magát, nem amikor a démon elindul, amit érdemes megerősíteni, mielőtt a logikát odaköltözteti. Ha a munka a szolgáltatás életciklusához tartozik, nem egyetlen kapcsolathoz, egy systemd-egység jobb otthon bármelyik hooknál.

A hookparancsokat közvetlenül a démon hajtja végre, köztes héj nélkül, ezért a ifconfig_remote egy up-sorban szó szerinti szövegként érkezik. Csomagolja a parancsot kifejezett héjba, vagy tartsa a logikát egy környezetet olvasó szkriptben. A ipchange egyetlen utasítás, amely saját argumentumokat ad hozzá: átadja a címet és a portot a parancsnak, ezért a senkihez írt szkript két váratlant lát.

Három mód a munka leválasztására

Az első lehetőség a segédet a hookon belülről a háttérbe küldeni: indítsa el a setsid vagy a systemd-run --scope segítségével, zárja be az örökölt leírókat, és azonnal lépjen ki nullával. A második, hogy a hook írjon egy kis állapotfájlt, és egy systemd-időzítő vagy egy elérésiút-egység cselekedjen rá, ami triviálisan tartja a hookot, és oda teszi az újrapróbálkozási szabályt, ahol naplók vannak. A harmadik, hogy teljesen elhagyja a hookot, és a munkát a VPN-szolgáltatás után rendezett egységbe helyezze; ez a helyes válasz, ha a munka egyáltalán nem kapcsolatonkénti. Mindhárom egy szabályt oszt: a hooknak vissza kell térnie, mielőtt szüksége lenne az alagútra.

Bármit is választ, tegye a segédet idempotenssé és megfigyelhetővé. Két átfedő hívás nem hajthatja végre ugyanazt a visszafordíthatatlan műveletet kétszer, és a meghiúsuló segédnek hagynia kell valamit, amit egy ember el tud olvasni.

Válassza külön a homokozó hibáit az életciklus hibáitól

Amikor egy szkript root-parancssorból fut, és szolgáltatásként meghiúsul, az ok általában homokozó, nem a hálózat. Egy korlátozó ProtectHome, egy csak olvasható ProtectSystem vagy egy nem létező munkakönyvtár elérhetetlenné teheti a szkriptet vagy annak adatait, és egy SELinux-gazdagépen a fájlnak olyan kontextusra is szüksége van, amely engedélyezi a végrehajtást. Olvassa az egységet a systemctl cat openvpn-server@server paranccsal és a naplót a journalctl -u openvpn-server@server -n 80 paranccsal, majd keressen engedély- vagy kontextushibát a kapcsolati időtúllépés helyett. A homokozó kikapcsolása az utolsó lépés legyen, ne az első.

Az életciklus-hiba másképp néz ki: a hook elindul, a segéd fut, és a foglalat egyszerűen még nincs ott. Írjon időbélyeges sort magából a hookból, bontsa és csatlakozzon újra, és olvassa az eseményeket sorrendben. Amikor a segédnek valóban szüksége van az alagútra, hagyja, hogy készenlétet kérdezzen ahelyett, hogy rögzített ideig aludna.

Három mező teszi hasznossá a következő jelentést: melyik hook futott, melyik fiókot használta, és hol állt meg. Ezek nélkül minden későbbi vizsgálat elölről kezdődik.