Szolgáltatás újraindítása OpenVPN up eseménynél: a hookok legyőzik a tun0.device-t

Egy függő szolgáltatás tun0.device-hoz kötése az alagútra való feliratkozásnak tűnik, de nem az. Az eszközegység azt tükrözi, hogy a csatoló létezik, ami igaz maradhat egy sikertelen kapcsolat és az azt követő újracsatlakozás során is. A szolgáltatás ezután rossz pillanatban cselekszik, vagy soha, attól függően, hogy a csatoló közben eltűnt-e. Az a hook írja le az eseményt, amely valóban számít, amelyet az OpenVPN hív meg, nem az, amelyet a systemd következtet ki.

Döntse el, milyen feltételre van szüksége a szolgáltatásnak, mielőtt kiválasztja a kiváltó okot, mert a három jelölt nem felcserélhető.

Mit követ valójában az eszközegység

A systemd egy eszközegységet a kernel hálózati csatolóra vonatkozó nézetéből hoz létre, ezért a tun0.device akkor válik aktívvá, amikor a csatoló megjelenik, és inaktívvá, amikor eltávolítják. A persist-tun beállítással a lágy újraindítás a helyén tartja a csatolót, így az egység soha nem villog, és semmi a hozzá kötött dologból nem aktiválódik. Perzisztencia nélkül is az egység semmit nem mond az útvonalakról, a DNS-ről vagy arról, hogy a távoli vég válaszol-e.

Ez rossz helyettesítővé teszi a 'a VPN készen áll' állapotra. Az a hallgató, amelynek csak a helyi címre van szüksége, megelégedhet a csatoló létezésével, míg a távoli hálózaton egy alkalmazást hívó szolgáltatásnak útvonalakra és elérhetőségre van szüksége, amit az eszközegység nem tud kifejezni.

Az up, a route-up és az up-restart különböző dolgokat jelent

A up azután fut, hogy megnyílt a TUN/TAP eszköz és beállították a csatolót, ami a megfelelő pillanat a hozzárendelt címet kötő hallgató számára. A route-up az útvonalak telepítése után fut, a beállított útvonalkésleltetés függvényében, és az olyan munkához illik, amelynek az útvonalfázis befejezésére van szüksége. Egyik sem bizonyítja, hogy a távoli alkalmazás válaszol. A kettő közötti választás arról szól, mire van szüksége a szolgáltatásnak, nem arról, melyik hook hangzik készebbnek.

A persist-tun beállítással az újraindítások újrahasznosítják az eszközt, ezért a up nem fut le újra, hacsak a up-restart nincs beállítva. Ez az opció engedélyezi az up szkriptet a dokumentált újraindítási életciklushoz, és a környezete csökkent az első indításhoz képest. Az a szkript, amely a teljes környezetet feltételezi, az első kapcsolatnál működik, a következőnél pedig meghiúsul.

Küldje el a műveletet anélkül, hogy megvárná

Egy hook, amely szinkron módon hívja a systemctl restart parancsot, holtpontba kerülhet egy olyan egységgel szemben, amelynek sorrendje az alagútra vár. A systemctl --no-block try-restart vpn-dependent.service sorba állítja a feladatot és visszatér, ami megakadályozza, hogy a hook blokkolja a kapcsolatot, amelyre reagált. A try-restart csak futó egységen hat, míg a restart egy inaktívat is elindít; szándékosan válasszon, ne megszokásból.

A sorba állítás nem ellenőrzés. A hook azonnal sikert ad vissza, amint a feladatot elfogadták, ezért az ellenőrzésnek a célegység naplójában vagy annak tényleges hallgatóállapotában kell megtörténnie.

Az újraindítási politika az egységben él, nem a hookban

Egy oneshot egység a RemainAfterExit=yes beállítással aktív marad a parancsa kilépése után, és a második indítási kérés nem tesz semmit, mert a systemd már elindítottnak tekinti. Ez olyan tulajdonság, amely körül tervezni kell, nem hiba, amelyet ismételt indítási hívásokkal kell megkerülni. Ha a műveletnek kapcsolatonként kell futnia, az egységnek olyan formára van szüksége, amely ezt lehetővé teszi.

A After= rendezi az egységeket, a BindsTo= pedig összeköti az élettartamokat, de egyik sem jelenti azt, hogy 'indítsd újra ezt, valahányszor a VPN újracsatlakozik'. Az alagúthoz kötött egység leáll, amikor az alagút leáll; nem indítja újra magát, amikor az alagút visszatér, kivéve, ha valami újraindítja.

Három újracsatlakozást teszteljen, ne egyet

A hidegindítás, a teljes kliens-újraindítás és a lágy újracsatlakozás mind más utat gyakorolnak. A lágy újracsatlakozás az, amely felfedi a hiányzó up-restart beállítást, a csökkent környezetet vagy az eszközegységet, amely soha nem vált inaktívvá. Futtassa mindhármat, és erősítse meg mindkét irányt: a szolgáltatás cselekszik, amikor az alagút feljön, és nem indul újra a nem kapcsolódó kapcsolatváltozásokra, például Wi-Fi barangolásra.

Tartson független helyreállítási útvonalat, amikor a függő szolgáltatás a saját adminisztratív hozzáférését hordozza. Az a hook, amely újraindítja azt, amin keresztül kapcsolódik, olyan változás, amely kizárhatja Önt.