Detekce mrtvého protějšku v IKEv2 neověřuje vaši aplikaci

Kontrola živosti v IKEv2 klade jednu otázku: odpovídá druhý protějšek stále na chráněném řídicím spojení. Neměří, zda je vnitřní aplikace zdravá, zda za bránou existuje trasa, ani zda se prohlížení zdá rychlé. Kontrola může projít, zatímco všechno užitečné za tunelem selhává.

Přečtěte si oba druhy důkazů odděleně, než změníte časovač.

Na co se kontrola živosti vlastně ptá

Výměna živosti se odesílá uvnitř zavedené bezpečnostní asociace IKE a očekává odpověď v nastaveném okně. Úspěch znamená, že implementace IKE na protějšku je stále tam a stále ochotná mluvit. Nic to neříká o podřízených bezpečnostních asociacích, které nesou provoz, nic o směrování za bránou a nic o službě, kvůli které jste tunel otevřeli. To jsou tři oddělené otázky se třemi oddělenými režimy selhání.

Tento rozdíl určuje, kam se dívat, když relace ztichne. Protějšek, který dál odpovídá, zatímco datová cesta je rozbitá, ukazuje na politiku, směrování nebo navazující službu. Protějšek, který přestane odpovídat, ukazuje na dostupnost nebo na vlastní stav vzdáleného konce.

Přečtěte si bezpečnostní asociace dřív než prohlížeč

Řídicí stav a datový stav se vypisují odděleně, jakmile se zeptáte démona, a čítače říkají, zda se vůbec něco zkoušelo. Podřízená asociace, která nebyla nikdy nainstalována, vypadá úplně jinak než ta, která se nainstalovala a pak přestala propouštět pakety, i když obě dávají stejnou stížnost uživatele.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Zapište názvy stavů doslova do tiketu, spolu s čítači v okamžiku stížnosti. Popis jako tunel spadl skrývá, která ze dvou asociací skončila, a to je obvykle jediný fakt, který stojí za to mít.

Selhání trasy vypadá přesně jako mrtvý protějšek

Brána může odpovídat na řídicí výměny, zatímco soukromý server je offline, přeposílaná trasa chybí nebo vnitřní překlad jmen úplně selhává. Z pohledu klienta se každé z toho jeví jako relace, která běží, a cíl, který neběží. Kontrolujte zpětnou cestu stejně pečlivě jako cestu tam, protože asymetrické směrování na vzdálené straně vytváří ticho jen v jednom směru.

Testujte zamýšlenou aplikaci přímo a pojmenujte adresu, kterou zkusila, místo abyste testovali, zda je tunel nahoře. Ping na bránu dokazuje, že brána odpovídá; nikdy nedokázal, že odpověděla aplikace. Zaznamenejte přesnou adresu, kterou aplikace zkusila. Ten řetězec později zúží hledání a je to jediný fakt, který tiket obvykle vynechá.

Nechte časovače mimo diagnózu

Zkrácení intervalu detekce není změna výkonu a nepřidává kapacitu. Při ztrátě paketů mění, jak rychle se porucha rozpozná, což může symptom vypadat jinak, aniž by cokoli zlepšilo. Nejprve zaznamenejte skutečný čas poruchy, potom rozhodněte, zda je tolerance špatná pro spoj, který skutečně máte.

Obnovy mapování NAT patří do stejné kategorie. Udržují přeloženou cestu použitelnou a nejsou důkazem, že vzdálená aplikace funguje.

Úplná politika obnovy říká, co má klient udělat, když je protějšek prohlášen za mrtvý: restartovat, zavřít nebo podržet, a co smí dělat ostatní provoz, dokud se to děje. Bez toho se stejný incident každé čtvrtletí diagnostikuje znovu od nuly.