Duplikált IKE-csomagok: találja meg a hiányzó átmenetet

A napló kétszer mutatja ugyanazt az IKE-kérést, valaki a mobil uplinkre mutat, és a jegy egy találgatással zárul. Ez a találgatás a mítosz: az ismételt csomag egyetlen cseréről szóló megfigyelés, nem egy kapcsolat diagnózisa. Az újraküldés saját szabályokkal rendelkező normál viselkedés, és egészséges útvonalakon is megjelenik, valahányszor lassú a válasz. Kövesse a választ, mielőtt egy interfészt hibáztat.

A mítosz: az ismételt kérés egy kapcsolat veszteségét bizonyítja

Két különböző dolog hoz létre duplikátumot, és egyik sem nevez meg bűnöst. A kérelmező azért ismételheti meg a kérést, mert nem kapott választ, vagy a rögzítési pont azért mutathatja kétszer ugyanazt a csomagot, mert ott csatlakozik a veremhez. Az a csap, amely ugyanazon a gazdagépen látja a be- és kimenő forgalmat, szívesen naplóz egy csomagot kettőként, és a naplót olvasó üzemeltető a csereazonosítók nélkül nem tud különbséget tenni. Kezelje a duplikátumot időzítőeseményként, amíg meg nem tudja mondani, melyik van a kezében.

Két uplink inkább súlyosbítja, mint enyhíti a zavart. Egy naplósor egy interfészt nevez meg, miközben a válasz a másikon is kimehetett, tehát az üzenetben szereplő interfész azt írja le, hol látták a csomagot, és nem a beszélgetés alakját. Ezért az első kérdés az, melyik cserét nézi, és nem az, melyik kapcsolat hibás.

Mit mond valójában az újraküldés

Az IKEv2-ben az újraküldés így működik: a kérelmező megismétli a kérést, ha nem érkezett válasz, a válaszadó pedig újraszámlálás helyett újraküldheti a gyorsítótárazott válaszát. Az üzenetazonosítók ehhez a cseréhez tartoznak, és éppen ez teszi az azonos azonosítójú ismételt kérést a protokoll működéseként felismerhetővé, nem új kísérletként. Egy első kísérletnek gyakran többre van szüksége egy forráscímnél vagy egy kezdeményező SPI-nél a korreláláshoz, ezért a platform saját csere-rekordja jobb, mint egy csomaglista. Az IKEv1 más szabályokat követ más azonosítókkal, és a szállító figyelmeztetése a duplikált első csomagról nem jelent minden verzióban ugyanazt.

Tehát az újraküldési időbélyeg azt mondja, hogy lejárt egy időzítő. Nem mondja meg, melyik ugrás volt lassú, és biztosan nem mondja, hogy az üzemeltető a hibás. Ezek külön állítások, és a jegyben csak a második hasznos.

A gyakorlati következmény, hogy a következtetés előtt rögzítse a cserét. Jegyezze fel a helyi fogadási címet, a házirend által választott válaszútvonalat, a partner-tuple-t és a csereazonosítókat egy helyre, mert mindegyik más kérdésre válaszol, amikor a rekordot később olvassák.

Négy megfigyelési pont egyetlen láncként

Tekintse a cserét egy lánc négy szemeként, és ne négy külön néznivaló helyként. Egy szem bizonyítékot tart, vagy ismeretlen marad, és a lánc csak annyira informatív, mint a leggyengébb rögzített szeme. Az alábbi táblázat a leltár: mit tud megállapítani az egyes pozíciók, és mit hagy érintetlenül.

Csak ott töltse ki a láncot, ahol hozzáférése van, a többit pedig ismeretlenként jelölje meg ahelyett, hogy kikövetkeztetné. Egy hook, amely egy gépen rögzít csomagokat, semmit sem mond arról, mit kapott a távoli gép, és az a naplósor, hogy láttak egy kérést, nem bizonyíték arra, hogy valaha kiment válasz. A tisztességes hézagok hasznosabbak, mint a találgatásokból épített, teljesnek látszó rekord.

Találja meg az első hiányzó átmenetet

Járja végig a láncot a kezdeményezőtől kifelé, és álljon meg az első bizonyíték nélküli szemen. Ha az átjáró soha nem naplózza a kérést, a hiba az előtte lévő útvonalon van. Amikor az átjáró újra és újra ugyanazt a kérést naplózza, miközben a kliens soha nem naplóz választ, a visszirány a gyanús: forráscím, fordítás és szűrés minden Ön által ellenőrzött határon. Ha a válasz megérkezik, és a kliens mégsem lép tovább, a kérdés elhagyta a szállítást, és házirenddé vagy állapottá vált.

Tartsa rögzítve a partnert és a protokollt az összehasonlítás alatt, és ne feledje, hogy a késleltetés, a veszteség, a házirend és az állapot külön-külön más idővonalat ad. A mobilhálózat nem automatikusan az ok, és a vezetékes vonal nem automatikusan elég megbízható minden követelményhez. Rögzítse mindkét irányt, amíg a csere él:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

Amikor a hozzáférés a távoli vég előtt megszakad, a rekord akkor is segít, ha megmondja, hol szakad meg. Egy csak a kezdeményezőn végzett rögzítés megmutathatja, hogy egy kérés kimegy és nem érkezik válasz, ami a hibát a hook utáni mindenre szűkíti anélkül, hogy azt állítaná, tudja, melyik ugrás ejtette el. Jelölje a távoli szemeket ismeretlenként, és hagyja, hogy a következő hozzáféréssel rendelkező személy kitöltse őket. Így leírva a rekord őszinte marad, és még mindig rövid.

Hasonlítson össze, mielőtt bármit megváltoztat. Ugyanazon kérés ismétlése ugyanahhoz a partnerhez ugyanazzal a protokollal számon tarthatóvá teszi a változókat, míg a rögzítések közötti újraindítás, kulcsfrissítés vagy házirend-módosítás megsemmisíti az összehasonlítást. Ha a változás elkerülhetetlen, rögzítsen újra közvetlenül utána, hogy az előtte és utána még ugyanazt a cserét írja le.

Mit mond egy hasznos jelentés

A cselekvésre érdemes jelentés egy kérést a válaszához párosít, és megnevezi az első lépést, amely mögött nincs bizonyíték. Az a mondat túléli, hogy egy hét múlva olyan mérnök olvassa, aki nem volt ott, és a következő embernek kiindulópontot ad gyanúsított helyett.

Soha ne gyengítse az identitásellenőrzéseket, és ne szélesítse az engedélyezett protokollkészletet csak azért, hogy egy újraküldési elméletet ellenőrizzen. Mentse el az eredeti csomagokat és eseményrekordokat bármilyen újraindítás előtt, mert az újraindítás pontosan azt az anyagot pusztítja el, amelyet gyűjteni készült, és törli azt az időzítést, amely megmutatta, hol akadt el a csere.

A mítosz az, hogy egy duplikátum bizonyítja az üzemeltető hibáját. A valóság az, hogy egy duplikátum bizonyítja, hogy lejárt egy időzítő, és a válasz a válaszútvonalon él.