keepalive az OpenVPN-ben vagy systemd restart: melyik állítja helyre?

Három különböző dolog mehet rosszul egy alagúttal, és három különböző reakciót kívánnak. A partner abbahagyja a válaszadást, a démonfolyamat meghal, vagy az alagút mögötti alkalmazás abbahagyja a kiszolgálást. Az a konfiguráció, amely bármelyiküknél újraindítja a szolgáltatást, nem gondos felügyelet; ez egyetlen tompa művelet, amelyet egymással nem összefüggő hibákra alkalmaznak. Annak összehasonlítása, hogy az egyes mechanizmusok valójában mit tudnak megfigyelni, nyilvánvalóvá teszi a munkamegosztást.

Három hiba, amely egynek látszik

A partner csendje azt jelenti, hogy a másik vég abbahagyta a küldést, és OpenVPN ezt maga is észlelheti, mert övé a szívverés. A folyamat halála azt jelenti, hogy a démon kilépett, amit a szolgáltatáskezelő észrevesz, az OpenVPN pedig nem tud. Az alkalmazás hibája azt jelenti, hogy az alagút rendben van, és valami mögötte nincs, és a másik két mechanizmus egyikének sincs módja ezt tudni. Mindegyikük más reakciót igényel, és egyik sem ugyanaz, mint észrevenni, hogy az alagút él.

Ezek különböző rétegek különböző jelzései, és mindegyiknek van gazdája, aki találgatás nélkül cselekedhet rá. Ezek összekeverése olyan rendszert hoz létre, amely olyan tünetekre indít újra, amelyeket nem tud értelmezni.

Írja le a három esetet, mielőtt bármelyik időzítőt megváltoztatja. A lista általában maga mutatja meg, hogy egy mechanizmustól kérik mindhárom lefedését.

Mivé is bontja ki magát a keepalive

A keepalive utasítás rövidítés, és a kibontás módtól függően eltér. Kiszolgálón a keepalive 10 60 helyi pinggé válik tíz másodpercenként, 120 másodperces helyi újraindítási időkorláttá, valamint az ügyfeleknek küldött 10 és 60 értékekké. A kiszolgáló időkorlátja szándékosan megduplázódik, hogy az ügyfél esélyt kapjon az újraindításra, mielőtt a kiszolgáló feladja. A futó konfigurációban olvassa a kibontott alakot, ne a profilban lévő rövidítést.

Ez a megduplázás az oka annak, hogy minden leírás hibás, amely azt állítja, hogy mindkét vég hatvan másodperc után újraindul. Azt is megmagyarázza, miért nem lebeg együtt a két vég, amikor egy útvonal romlik.

A szívverés OpenVPN-partnerforgalom, nem valamely nyilvános gazdagép ICMP-próbája. A válasz csak azt bizonyítja, hogy az alagút távoli vége él. Semmit nem mond arról az adatbázisról vagy webszolgáltatásról, amelyre a felhasználónak valóban szüksége van.

Mit nem figyel a Restart=on-failure

Olvassa el a telepített egységet, mielőtt felülírást ad hozzá. A Restart=on-failure a dokumentált folyamathiba-feltételekre reagál, ami nem ugyanaz, mint a kapcsolat állapotának figyelése. Nem lép működésbe azért, mert belső újracsatlakozás indult, és a tiszta kilépés jelentése más, mint az összeomlásé.

Ez a megkülönböztetés azért számít, mert a belső újraindítás ugyanazt a folyamatot tartja életben. Az egység semmit nem lát, az alagút magától helyreáll, és ez a helyes eredmény.

Állítsa be szándékosan a RestartSec értéket és az indítási korlátokat, különben az összeomlási hurok terhelni fogja az átjárót, és az újraindítási üzenetek alá temeti a valódi hibát. A működésbe lépő újraindítási korlát hibás állapotban hagyja az egységet, ami látható, a korlátlan hurok pedig nem.

A ping-restart és a ping-exit nem felcserélhető

A ping-restart kiváltja az OpenVPN belső újraindítását, és megtartja a folyamatot. A ping-exit ugyanolyan időkorlátnál fejezi be a folyamatot, ami a döntést a szolgáltatáskezelőre bízza. Ezek kölcsönösen kizárják egymást, és a második választása megváltoztatja, kié a helyreállítás. A különbség az, hogy ki dönt az újrapróbálásról, és mennyi állapot éli túl a kísérletet.

Ha a kilépést választja időkorlátnál, az egységnek illeszkedő újraindítási szabályzatra és kilépési állapot kezelésére van szüksége, különben az életképességi hiba tartós leállásnak látszik. A tartóssági beállítások megőrizhetik a csatolókat és útvonalakat egy belső újraindítás során, de egy folyamatkilépés során nem.

Telepítésenként egy életciklust válasszon, és írja le, miért. Az a profil, amely mindkét utasítást hordozza, olyan profil, amely nem döntött.

Tesztelje minden hibát saját eseteként

Szimuláljon egy csendes partnert, egy megölt démont és egy elérhetetlen alkalmazást jóváhagyott ablakban, majd ellenőrizze, melyik helyreállítás lépett működésbe. A csendes partnernek belső újracsatlakozást kell adnia, a megölt folyamatnak egység-újraindítást, az alkalmazáskiesésnek pedig egyiket sem. Amikor két eset ugyanazt a műveletet adja, a tulajdonjog még mindig kevert.

Az ismételt helyreállítás sem javítás. Az elutasított hitelesítő adatok vagy két ügyfél, amely ugyanazt a hatékony nevet használja, továbbra is felváltja egymást, és a gyorsabb időzítők csak gyorsabbá teszik ezt a lebegést.