OpenVPN: a helyi kötés meghiúsul indításkor — várni vagy újrapróbálni

Egy indításkor el nem induló OpenVPN-kiszolgálóhoz két megoldást kínálnak: várni a címre, vagy hagyni, hogy a szolgáltatás újrapróbálkozzon, amíg a kötés sikerül. Mindkettő ugyanazt a tünetet kezeli eltérő hiba-viselkedéssel. A várakozás egy konkrét előfeltételt kódol, és hangosan meghiúsul, ha az hiányzik; az újrapróbálkozás elrejti az előfeltételt, és tovább próbálkozik. Hogy melyik illik az egységébe, attól függ, hogy az a cím tervezett függőség-e vagy az időzítés véletlene.

Mindkettő jobb egy rögzített alvásnál, amely semmire nem vár, és nem is jelenti, mire várt.

Mit követel valójában a local beállítás

local nevezi meg azt a címet, amelyhez a démon a socketjét köti, és egy még nem létező címhez kötni azonnal meghiúsul a kért címről szóló hibával. Ha a beállítás hiányzik, a démon minden címen figyel, ezért ugyanaz a profil működik olyan gépen, amelynek illesztője még nem jött fel: mindenhol figyel a megnevezett egyetlen cím helyett. Ez a különbség a teljes hiba, és újraindításig láthatatlan marad.

A követelmény nem az, hogy az illesztő valamilyen általános értelemben fent legyen. A címnek a kötés pillanatában a megfelelő illesztőhöz kell rendelve lennie, és az alap-illesztőnek kell lennie, nem pedig egy alagútnak, amelyet ugyanez a démon később hozna létre. A bejelentkezés után percekkel végzett ellenőrzés semmit sem bizonyít az indítási sorrendről.

Várni a címre vagy újrapróbálni a kötést

A várakozás egy ExecStartPre, amely addig kérdez, amíg a cím meg nem jelenik, korlátozott számú kísérlettel és nullától eltérő kilépéssel, amikor az idő lejár. Az újrapróbálkozás azt jelenti, hogy hagyjuk a fő folyamatot meghiúsulni, és megkérjük a szolgáltatáskezelőt, hogy indítsa újra, például Restart=on-failure a RestartSec=5 beállítással. Az első hiányzó előfeltételként jelenti a meghiúsult egységet, míg a második újraindítások sorozataként, amely végül leáll; ez hangosabb a naplóban, de túlél egy címet, amely kiszámíthatatlan okokból későn érkezik.

Akkor részesítse előnyben a várakozást, ha a cím tervezett függőség, és az újrapróbálkozást, ha a cím általában megjelenik, de az időzítése változó. Ezek kombinálása ésszerű: a korlátozott várakozás lefedi a szokásos esetet, az újraindítási szabályzat a kivételt. Egyik sem futhat örökké, mert a végtelenségig újrapróbálkozó egység elrejti a hibás konfigurációt ahelyett, hogy jelentené.

Miért nem elég a network-online.target

network-online.target azt ígéri, amit az aktív hálózati megvalósítás online alatt ért, és semmi többet. systemd-networkd esetén systemd-networkd-wait-online dönti el, mikor érhető el ez a cél, és annak alapértelmezett online-felfogása teljesülhet, mielőtt az Ön konkrét címe létezne. NetworkManager alatt a wait-online szolgáltatás a saját szabályait alkalmazza. A cél után sorrendezni megalapozott kiindulás, nem garancia arra, hogy egy cím, egy DNS-válasz vagy egy távoli fél készen áll.

Ugyanez az érvelés zárja ki a szokásos alternatívákat. Az asztali automatikus indítási bejegyzés olyan felhasználói munkamenetre vár, amely egy kiszolgálón talán soha nem nyílik meg, a késleltetett cron-parancs pedig eltelt időt ad hozzá anélkül, hogy megnevezné az erőforrást, amelynek megjelenésében reménykedett. Mindkettő hónapokig sikeresnek tűnhet, majd azon az egyetlen indításon hiúsul meg, amely számít.

Ellenőrizze a kötést hideg indítás után

Valódi hideg indítással ellenőrizze, ne szolgáltatás-újraindítással, mert az újraindítás olyan címet örököl, amelyet az indítási sorrendnek kellett létrehoznia. Indítás után a ss -lntp vagy a ss -lunp mutatja, hogy az egyes figyelők ténylegesen melyik helyi címhez kötődtek, a journalctl -b -u openvpn-server@server pedig azt, hogy az első kísérlet meghiúsult-e. Hasonlítsa össze a kötött címet a profilban lévővel, majd ismételje meg az összehasonlítást hálózati újracsatlakozás után.

Ha a profilnak soha nem kellett rögzített cím, a local eltávolítása jogos egyszerűsítés, de tegye biztonsági döntéssé, ne hibakeresési szokássá.

A figyelő kiszélesítése megváltoztatja, ki érheti el, ezért párosítsa ezt a változtatást azzal a tűzfal-szabályzattal, amelynek korlátoznia kellett volna. Egy szolgáltatás, amely minden illesztőn megbízhatóan indul, nem oldotta meg az eredeti problémát; a problémát a hálózat peremére helyezte át.