IKEv2: nøkkelnying kontra reautentisering — kvifor sambandet fell seinare

Tunnelen kjem opp om morgonen og verkar i timar. Så fell han, koplar til att etter eitt forsøk og gjer det same neste dag. Ingenting endra seg på nettet, og ingen rørte eit passord. Økter som feilar ved ei nøkkelnyingsgrense, kryssar vanlegvis ein av to ulike operasjonar, og berre éin av dei sjekkar påloggingsinformasjonen din på nytt. Å lese kven som vart utløyst, er heile diagnosen.

To operasjonar som ser like ut utanfrå

Nøkkelnying erstattar tryggingskoplingar eller nøkkelmateriale innanfor utvekslinga protokollen definerer. Autentisering vert ikkje gjenteken, så identiteten som vart godteken ved øktstart, vert berre ført vidare.

Reautentisering går lenger: ho etablerer eit nytt autentisert tilhøve, som tyder at påloggingsinformasjonen vert vurdert på nytt. Alt som er gått ut, trekt attende eller endra i katalogen, vert synleg i det augeblikket.

Kva ei nøkkelnying faktisk erstattar

IKEv2 held to slag koplingar med separate livssyklusar. IKE SA vernar kontrollkanalen, og CHILD SA vernar den faktiske trafikken. Å fornye éin er ikkje synonymt med å kopie klienten til på nytt.

Den oppdelinga forklarar eit kjent mønster: trafikken flyt fint, så vert ein CHILD SA fornya og forslaget passar ikkje lenger fordi nokon redigerte fase 2 på den eine sida veker tidlegare. Endringa låg der ufarleg heilt til fornyinga utløyste henne.

Usemje i levetid oppfører seg på same måte. Den sida som først når grensa si, startar utvekslinga, og den andre må godta henne.

Kva reautentisering vurderer på nytt

Ved reautentisering kan klientcertifikatet som var gyldig ved innlogging, no vere gått ut. Ein attrekt påloggingsdetalj, eit rotert passord eller ein utilgjengeleg andre faktor dukkar alle opp her, ikkje ved fornyingstidspunktet.

Difor kjennest det som ei retting å forlenge kvar levetid, og det er det ikkje. Du har utsett kontrollen i staden for å bestå han. Neste fornying kjem med same defekt og eit kortare avbrot-vindauge til å oppdage han.

Nokre implementasjonar overlappar gamal og ny tilstand under reautentisering. Andre gir eit kort hol. Identiske innstillingar hos to leverandørar kan difor gi ulike brukaropplevingar. Test åtferda i staden for å anta at standarden pålegg henne.

Les tidsstempla før du endrar noko

Fang feilaugeblikket saman med tilstanden til koplinga før og etter. Viss den gamle koplinga vart erstatta utan ei autentiseringsutveksling, var du ved ei nøkkelnyingsgrense. Viss ei AUTH-utveksling viser seg rett før feilen, var du ved ei reautentisering.

strongSwan eksponerer dette som separate innstillingar: rekey styrer nøkkelnying, reauth styrer om ei ny autentisering skjer, og margin-verdiar avgjer kor langt før utløp kvar av dei startar. dokumentasjonen om nøkkelnying skildrar samspelet, og han er verdt å lese før du kopierer ei levetid frå eit foruminnlegg.

Skil alt dette frå eit vanleg netverkstap. Ei broten lenkje gir ei hending for registrering av daud peer eller ein storm av vidersendingar, ikkje ei rein utveksling med samsvarande forslag.

Endre det som feila

Ei avvising av påloggingsinformasjon krev at identitetsproblemet vert retta: forny sertifikatet, gjenopprett kontoen, registrer faktoren på nytt. Ei usemje i forslag eller levetid krev at parametrane vert samanlikna på begge sider.

Å strekke levetider for å unngå symptomet er det eine alternativet som alltid ser ut som det verka, og aldri gjer det.

Test ei kontrollert fornying

Tving fornyinga i staden for å vente ein dag på henne. Gjenta deretter med ei reautentisering viss utrullinga støttar det, og følg med på begge endane.

Ei vellukka førstegongsinnlogging øver ikkje noko av dette. Livssyklusen etterpå er der desse utrullingane faktisk bryt saman.