IKEv2: kulcsújítás kontra újrahitelesítés — miért szakad meg később a kapcsolat

Az alagút reggel feljön és órákig működik. Aztán megszakad, egy próbálkozás után újracsatlakozik, és másnap ugyanezt teszi. A hálózaton semmi nem változott, és senki nem nyúlt jelszóhoz. A megújítási határnál meghibásodó munkamenetek általában két különböző művelet egyikét lépik át, és csak az egyik ellenőrzi újra a hitelesítő adatokat. Annak elolvasása, melyik lépett életbe, maga a teljes diagnózis.

Két művelet, amely kívülről hasonlónak tűnik

A kulcsújítás a biztonsági társításokat vagy a kulcsanyagot cseréli a protokoll által meghatározott csere keretében. A hitelesítés nem ismétlődik, ezért a munkamenet elején elfogadott identitás egyszerűen továbbvitelre kerül.

Az újrahitelesítés tovább megy: friss hitelesített kapcsolatot hoz létre, ami azt jelenti, hogy a hitelesítő adatok újra értékelődnek. Minden, ami lejárt, visszavonásra került vagy megváltozott a címtárban, abban a pillanatban láthatóvá válik.

Mit cserél valójában a kulcsújítás

Az IKEv2 kétféle társítást tart külön életciklusokkal. Az IKE SA a vezérlőcsatornát védi, a CHILD SA-k a tényleges forgalmat. Az egyik megújítása nem azonos az ügyfél újracsatlakoztatásával.

Ez a szétválasztás magyaráz egy ismerős mintát: a forgalom szépen folyik, aztán megújul egy CHILD SA, és a javaslat már nem illik, mert valaki hetekkel korábban szerkesztette a 2. fázist az egyik oldalon. A változás ártalmatlanul ott hevert, amíg a megújítás ki nem próbálta.

Az élettartam-eltérések ugyanígy viselkednek. Amelyik fél előbb éri el a határát, az indítja a cserét, a másiknak el kell fogadnia.

Mit értékel újra az újrahitelesítés

Újrahitelesítéskor a bejelentkezéskor érvényes ügyféltanúsítvány már lejárt lehet. A visszavont hitelesítő adat, a rotált jelszó vagy az elérhetetlen második tényező mind itt bukkan fel, nem a megújítás idején.

Ezért tűnik minden élettartam meghosszabbítása javításnak, és nem az. Elhalasztottad az ellenőrzést ahelyett, hogy átmentél volna rajta. A következő megújítás ugyanazzal a hibával és rövidebb kiesési ablakkal érkezik, hogy észrevedd.

Egyes implementációk átfedik a régi és az új állapotot az újrahitelesítés során. Mások rövid rést hoznak létre. Ezért az azonos beállítások két szállítónál eltérő felhasználói élményt adhatnak. Teszteld a viselkedést, ahelyett hogy feltételeznéd, a szabvány előírja.

Olvasd el az időbélyegeket, mielőtt bármit megváltoztatsz

Rögzítsd a hiba pillanatát a társítás előtti és utáni állapotával együtt. Ha a régi társítást hitelesítési csere nélkül cserélték le, megújítási határnál voltál. Ha közvetlenül a hiba előtt AUTH csere jelenik meg, újrahitelesítésnél voltál.

A strongSwan ezt külön beállításként teszi elérhetővé: rekey a kulcsújítást vezérli, reauth azt vezérli, történik-e új hitelesítés, a margin értékek pedig eldöntik, mennyivel a lejárat előtt kezdődik mindegyik. a kulcsújítás dokumentációja leírja a kölcsönhatást, és érdemes elolvasni, mielőtt élettartamot másolnál egy fórumbejegyzésből.

Különböztesd meg mindezt egy egyszerű hálózatkieséstől. A megszakadt kapcsolat halott partner észlelési eseményt vagy újraküldési vihart okoz, nem tiszta cserét egyező javaslatokkal.

Változtasd meg azt, ami meghibásodott

A hitelesítő adatok elutasítása az identitásprobléma javítását igényli: újítsd meg a tanúsítványt, állítsd helyre a fiókot, regisztráld újra a tényezőt. A javaslat vagy élettartam eltérése a paraméterek kétoldali összehasonlítását igényli.

Az élettartamok nyújtása a tünet elkerülésére az egyetlen lehetőség, amely mindig úgy tűnik, hogy működött, és soha nem működik.

Tesztelj egy ellenőrzött megújítást

Kényszerítsd ki a megújítást, ahelyett hogy egy napot várnál rá. Aztán ismételd meg újrahitelesítéssel, ha a telepítés támogat egyet, és figyeld mindkét végét.

A sikeres első bejelentkezés semmit nem gyakorol ebből. Az utána következő életciklus az, ahol ezek a telepítések valóban eltörnek.