A keepalive nem újracsatlakozás: a meglévő hiba szerint válasszon

A keepalive és az újracsatlakozás egy levegővel konfigurálható, mégis különböző problémákat old meg, ezért az egyik hangolása ritkán javítja a másikat. A keepalive kis forgalmat küld, hogy életben tartsa az állapotbejegyzést, vagy észlelje, hogy egy partner abbahagyta a válaszadást. Az újracsatlakozás lebontja a törötte, és újra felépíti a kapcsolatot, kulcsokkal, címekkel és útvonalakkal együtt. A hibához illő mechanizmust válassza, ne azt, amelynek a gombját már ismeri. Két kérdés dönti el: halott-e az útvonal, vagy valami a partnerek között elfelejti?

Amikor a leképezés a probléma

Az a tunnel, amely csak percek csend után hal meg, általában fordítási bejegyzést veszít, nem partnert. A WireGuard PersistentKeepalive NAT- és tűzfalállapothoz létezik, és a projekt saját jegyzetei is pontosan így írják le, nem egészségellenőrzésként. Néhány tíz másodperces intervallum melegen tartja a bejegyzést, míg a másodpercenkénti csomag akkumulátoros döntés, nem megbízhatósági. OpenVPN ugyanoda jut ping és ping-restart útján, amelyek először észlelik a csendet, aztán cselekszenek rá.

Ezek a beállítások protokollok között sem cserélhetők fel. Az IKEv2 halott partnerre vonatkozó szabálya, az OpenVPN ping-időzítője és a WireGuard keepalive-ja ugyanarra a kérdésre három különböző szintaxissal és három különböző alapértékkel válaszol, ezért a szám átmásolása köztük hangolásnak álcázott találgatás.

Amikor a kapcsolat eltűnt

Ha a partner címet vált, a hitelesítő adat lejár, vagy a távoli vég újraindul, a kis csomagok nem jelentenek javítást. Az újracsatlakozásnak újra kell építenie az állapotot : címet szerezni, újratelepíteni az útvonalakat, újratárgyalni a kulcsokat, és egyes telepítésekben újra hitelesíteni a felhasználót.

A felügyelet nélkül újracsatlakozó kliensek tanúsítványt vagy tárolt titkot tartanak. Az a kliens, amely embertől kérdezne, pontosan akkor bukik el, amikor senki sincs jelen, és ez az a forgatókönyv, amelyben az újracsatlakozás számított. Ez hónapokkal korábbi tervezési döntés, nem beállítás, amelyet kiesés közben megváltoztathat.

Mit nem bizonyít egyik sem

Egy tunnel lehet újracsatlakozva, kulcsolva és útvonalazva, miközben a mögötte lévő szolgáltatás áll, és a keepalive nyitva tarthat egy leképezést egy olyan munkamenet számára, amelynek kiszolgálója órák óta nincs. Mindkét mechanizmus jelenthet sikert, miközben az, ami igazán fontos önnek, nem elérhető.

Ezért a teszt egy valódi kérésnél ér véget. Küldjön valamit a tunnelen át az önt érdeklő intervallum után, majd külön váltsa ki a hibát, amelyre tervezett: tétlenségi időszak a leképezés esetében, újraindítás vagy címváltozás az újracsatlakozás esetében.

A közvetlen forgalom blokkolása külön döntés

Egy újracsatlakozási hurok teljesen egészséges lehet, miközben egy alkalmazás csendben a szokásos útvonalat használja, és ez szivárgás, nem hiba. Ha a követelmény az, hogy semmi ne lépjen ki a tunnelen kívülre, mondja ki egyértelműen a kliens konfigurációjában, és bizonyítsa azzal, hogy leveszi a tunnelt, és megnézi, mi kapcsolódik még. Egyik mechanizmus sem jelenti ezt a viselkedést, és semmilyen újrapróbálkozási fegyelem nem teremti meg.

Jegyezze fel, melyik mechanizmus futott, és hogy utána sikerült-e új kérés. Ez a két tény kell a következő mérnöknek, és egyik sem látható egy állapotikonon. Egy naplósor, amely szerint a kliens újracsatlakozott, nem ugyanaz, mint egy kérés, amely működött.

Írja meg a szabályt, ne csak a számot

Tegye a párt egy mondatba: a tétlenségi intervallum, az életképességi küszöb, mi váltja ki az újraépítést , és mit tesz a kliens, miközben újrapróbálkozik. E mondat nélkül minden jövőbeli esemény újranyitja ugyanazt a vitát arról, hogy a keepalive túl rövid-e, vagy az újracsatlakozás túl lassú.

A WireGuard jegyzetei a korlátokról hasznos emlékeztető arra, hogy a keepalive köztes eszközök kerülőútja, nem általános életképességi terv. Olvassa el ezt a korlátot, mielőtt növelné a gyakoriságot egy olyan probléma válaszként, amelyet nem tud megoldani.