Az IKEv2 holt partner észlelése nem az alkalmazást teszteli

Az IKEv2 életjel-ellenőrzés egyetlen kérdést tesz fel: a másik fél még válaszol-e a védett vezérlőkapcsolaton. Nem méri, hogy egy belső alkalmazás egészséges-e, létezik-e útvonal az átjáró mögött, vagy gyorsnak tűnik-e a böngészés. Az ellenőrzés átmehet, miközben az alagút mögötti minden hasznos dolog meghibásodik.

A kétféle bizonyítékot külön olvassa el, mielőtt az időzítőhöz nyúl.

Mit kérdez valójában az életjel-ellenőrzés

Az életjel-csere a létrehozott IKE biztonsági társításon belül megy, és a beállított ablakon belül választ vár. A siker azt jelenti, hogy a partner IKE-megvalósítása még ott van, és még hajlandó beszélni. Semmit nem mond a forgalmat hordozó gyermek biztonsági társításokról, semmit az átjárón túli útválasztásról, és semmit arról a szolgáltatásról, amelyért az alagutat megnyitotta. Ez három külön kérdés, három külön hibaállapottal.

Ez a különbség dönti el, hova nézzen, amikor a munkamenet elhallgat. Ha a partner tovább válaszol, miközben az adatútvonal törött, az irányelvre, az útválasztásra vagy egy alsóbb szolgáltatásra mutat. Az a partner, amely abbahagyja a válaszolást, elérhetőségi vagy a túlsó vég saját állapotára mutat.

Előbb olvassa el a biztonsági társításokat, csak utána a böngészőt

A vezérlési állapot és az adatállapot külön listázódik, ha megkérdezi a daemont, a számlálók pedig megmondják, történt-e egyáltalán kísérlet. Egy soha nem telepített gyermek társítás egészen másképp néz ki, mint amelyik települt, majd abbahagyta a csomagok átengedését, pedig mindkettő ugyanazt a felhasználói panaszt kelti.

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

Jegyezze fel az állapotneveket szó szerint a jegybe, a panasz pillanatában érvényes számlálókkal együtt. Egy olyan leírás, hogy alagút le, elrejti, melyikük ért véget a két társítás közül, és általában ez az egyetlen tény, amit érdemes megtartani.

Az útvonalhiba pontosan úgy néz ki, mint egy holt partner

Az átjáró válaszolhat vezérlőcserékre, miközben egy privát kiszolgáló offline, egy továbbított útvonal hiányzik, vagy a belső névfeloldás teljesen meghiúsul. Az ügyfél szemszögéből mindegyik élő munkamenetként és nem élő célpontként jelenik meg. A visszaútvonalat ugyanolyan gondosan ellenőrizze, mint az odaútvonalat, mert a túlsó oldali aszimmetrikus útválasztás csak egy irányban okoz csendet.

Közvetlenül a szándékolt alkalmazást tesztelje, és nevezze meg a címet, amelyet megpróbált, ahelyett hogy azt vizsgálná, áll-e az alagút. Az átjáró pingelése azt bizonyítja, hogy az átjáró válaszol; soha nem bizonyította, hogy az alkalmazás válaszolt. Rögzítse a pontos címet, amelyet az alkalmazás megpróbált. Ez a karaktersor később szűkíti a keresést, és ez az az egyetlen tény, amelyet a jegy általában kihagy.

Tartsa ki az időzítőket a diagnózisból

Az észlelési időköz lerövidítése nem teljesítményváltozás, és nem ad kapacitást. Csomagvesztés esetén azt változtatja meg, milyen gyorsan ismerik fel a hibát, amitől a tünet másképp nézhet ki anélkül, hogy bármi javulna. Először a hiba valódi idejét rögzítse, majd döntse el, hogy a tűréshatár rossz-e a ténylegesen meglévő kapcsolathoz.

A NAT-leképezés frissítései ugyanebbe a kategóriába tartoznak. A lefordított útvonalat használhatóvá teszik, és nem bizonyítékai annak, hogy a távoli alkalmazás működik.

A teljes helyreállítási irányelv megmondja, mit tegyen az ügyfél, amikor egy partnert halottnak nyilvánítanak: újraindítás, lezárás vagy várakozás, és mit tehet más forgalom eközben. Enélkül ugyanazt az incidenst negyedévente elölről diagnosztizálják.