Zisťovanie mŕtveho partnera v IKEv2 netestuje vašu aplikáciu

Kontrola životnosti IKEv2 kladie jednu otázku: odpovedá druhý partner ešte na chránenom riadiacom vzťahu. Nemeria, či je interná aplikácia zdravá, či za bránou existuje trasa, ani či sa prehliadanie zdá rýchle. Kontrola môže prejsť, kým všetko užitočné za tunelom zlyháva.

Prečítajte si dva druhy dôkazov oddelene, skôr než zmeníte časovač.

Na čo sa kontrola životnosti skutočne pýta

Výmena životnosti sa odosiela v ustanovenej bezpečnostnej asociácii IKE a očakáva odpoveď v nakonfigurovanom okne. Úspech znamená že implementácia IKE partnera je stále tam a stále ochotná komunikovať. Nehovorí nič o podriadených bezpečnostných asociáciách, ktoré prenášajú prevádzku, nič o smerovaní za bránou a nič o službe, pre ktorú ste tunel otvorili. To sú tri oddelené otázky s tromi oddelenými spôsobmi zlyhania.

Ten rozdiel rozhoduje, kam sa pozrieť, keď relácia stíchne. Partner, ktorý naďalej odpovedá, kým je dátová cesta pokazená, ukazuje na pravidlá, smerovanie alebo službu nižšie. Partner, ktorý prestane odpovedať, ukazuje na dostupnosť alebo na vlastný stav vzdialeného konca.

Prečítajte si bezpečnostné asociácie pred prehliadačom

Riadiaci stav a dátový stav sa vypisujú oddelene, keď sa opýtate démona, a počítadlá hovoria, či sa vôbec niečo pokúsilo. Podriadená asociácia, ktorá nikdy nebola nainštalovaná, vyzerá úplne inak ako tá, ktorá sa nainštalovala a potom prestala prepúšťať pakety, hoci obe dávajú rovnakú používateľskú sťažnosť.

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

Zapíšte názvy stavov doslovne do tiketu spolu s počítadlami v okamihu sťažnosti. Opis ako tunel dole skrýva, ktorá z dvoch asociácií sa skončila, a to je zvyčajne jediný fakt, ktorý stojí za to mať.

Zlyhanie trasy vyzerá presne ako mŕtvy partner

Brána môže odpovedať na riadiace výmeny, kým je súkromný server offline, chýba preposlaná trasa alebo vnútorné rozlišovanie názvov úplne zlyhá. Z pohľadu klienta každý z týchto prípadov vyzerá ako relácia, ktorá je hore, a cieľ, ktorý nie je. Skontrolujte spiatočnú cestu rovnako starostlivo ako cestu vpred, pretože asymetrické smerovanie na vzdialenej strane vytvára ticho iba v jednom smere.

Testujte zamýšľanú aplikáciu priamo a pomenujte adresu, ktorú skúsila, namiesto testovania, či je tunel hore. Ping na bránu dokazuje, že brána odpovedá; nikdy nedokázal, že odpovedala aplikácia. Zapíšte presnú adresu, ktorú aplikácia skúsila. Ten reťazec neskôr zúži hľadanie a je to jediný fakt, ktorý tiket zvyčajne vynechá.

Držte časovače mimo diagnózy

Skrátenie intervalu zisťovania nie je zmenou výkonu a nepridáva kapacitu. Pri strate paketov mení, ako rýchlo sa zlyhanie rozpozná, čo môže spôsobiť, že príznak vyzerá inak bez toho, aby sa čokoľvek zlepšilo. Najprv zapíšte skutočný čas zlyhania, potom rozhodnite, či je tolerancia nesprávna pre spojenie, ktoré naozaj máte.

Obnovy mapovania NAT patria do rovnakej kategórie. Udržujú preloženú cestu použiteľnou a nie sú dôkazom, že vzdialená aplikácia funguje.

Úplná politika obnovy hovorí, čo má klient urobiť, keď je partner vyhlásený za mŕtveho: reštartovať, zavrieť alebo podržať, a čo môže robiť iná prevádzka, kým sa to deje. Bez toho sa ten istý incident každý štvrťrok diagnostikuje od nuly.