IKEv2: reînnoirea cheilor versus reautentificare — de ce conexiunea cade mai târziu

Tunelul urcă dimineața și funcționează ore întregi. Apoi cade, se reconectează după o încercare și face același lucru a doua zi. Nimic nu s-a schimbat în rețea și nimeni nu a atins o parolă. Sesiunile care eșuează la o graniță de reînnoire traversează de obicei una din două operațiuni diferite, și doar una dintre ele reverifică acreditările. Citirea careia dintre ele s-a declanșat este întregul diagnostic.

Două operațiuni care arată la fel din exterior

Reînnoirea cheilor înlocuiește asocierile de securitate sau materialul cheilor în cadrul schimbului definit de protocol. Autentificarea nu se repetă, așa că identitatea acceptată la începutul sesiunii este pur și simplu dusă mai departe.

Reautentificarea merge mai departe: stabilește o relație autentificată nouă, ceea ce înseamnă că acreditările sunt evaluate din nou. Tot ce a expirat, a fost revocat sau s-a schimbat în director devine vizibil în acel moment.

Ce înlocuiește de fapt o reînnoire a cheilor

IKEv2 păstrează două tipuri de asociere cu cicluri de viață separate. IKE SA protejează canalul de control, iar CHILD SA protejează traficul real. Reînnoirea uneia nu este sinonimă cu reconectarea clientului.

Această separare explică un model cunoscut: traficul curge bine, apoi o CHILD SA este reînnoită și propunerea nu mai corespunde pentru că cineva a editat faza 2 pe o parte cu săptămâni înainte. Schimbarea a stat acolo inofensiv până când reînnoirea a exercitat-o.

Neconcordanțele de durată se comportă la fel. Partea care își atinge prima limita începe schimbul, iar cealaltă trebuie să îl accepte.

Ce reevaluează reautentificarea

La reautentificare, certificatul de client care era valabil la autentificare poate fi acum expirat. O acreditare revocată, o parolă rotită sau un al doilea factor indisponibil apar toate aici, nu la momentul reînnoirii.

De aceea prelungirea fiecărei durate pare o remediere și nu este. Ai amânat verificarea în loc să o treci. Următoarea reînnoire vine cu același defect și cu o fereastră de întrerupere mai scurtă pentru a-l observa.

Unele implementări suprapun starea veche și cea nouă în timpul reautentificării. Altele produc un gol scurt. De aceea setări identice la doi furnizori pot da experiențe diferite utilizatorului. Testează comportamentul în loc să presupui că standardul îl impune.

Citește marcajele de timp înainte de a schimba ceva

Capturează momentul eșecului împreună cu starea asocierii înainte și după. Dacă asociația veche a fost înlocuită fără un schimb de autentificare, erai la o graniță de reînnoire. Dacă un schimb AUTH apare chiar înainte de eșec, erai la o reautentificare.

strongSwan expune acest lucru ca setări separate: rekey controlează reînnoirea cheilor, reauth controlează dacă are loc o autentificare nouă, iar valorile margin decid cu cât timp înainte de expirare începe fiecare. documentația despre reînnoirea cheilor descrie interacțiunea, și merită citită înainte de a copia o durată dintr-o postare pe forum.

Distinge toate acestea de o pierdere simplă de rețea. O legătură întreruptă produce un eveniment de detectare a partenerului mort sau o furtună de retransmisii, nu un schimb curat cu propuneri potrivite.

Schimbă lucrul care a eșuat

Respingerea acreditărilor necesită repararea problemei de identitate: reînnoiește certificatul, restaurează contul, reînregistrează factorul. O neconcordanță de propunere sau de durată necesită compararea parametrilor pe ambele părți.

Întinderea duratelor pentru a evita simptomul este singura opțiune care pare mereu că a funcționat și nu funcționează niciodată.

Testează o reînnoire controlată

Forțează reînnoirea în loc să aștepți o zi pentru ea. Apoi repetă cu o reautentificare dacă implementarea suportă una, și urmărește ambele capete.

O autentificare inițială reușită nu exersează nimic din toate acestea. Ciclul de viață de după ea este locul unde aceste implementări chiar se strică.