IKEv2: nøkkelnying kontra reautentisering — hvorfor forbindelsen faller senere

Tunnelen kommer opp om morgenen og virker i timer. Så faller den, kobler til igjen etter ett forsøk og gjør det samme neste dag. Ingenting endret seg på nettverket, og ingen rørte et passord. Økter som feiler ved en nøkkelnyingsgrense, krysser vanligvis en av to forskjellige operasjoner, og bare én av dem sjekker påloggingsinformasjonen din på nytt. Å lese hvilken som ble utløst, er hele diagnosen.

To operasjoner som ser like ut utenfra

Nøkkelnying erstatter sikkerhetstilknytninger eller nøkkelmateriale innenfor utvekslingen protokollen definerer. Autentisering gjentas ikke, så identiteten som ble godtatt ved øktstart, føres bare videre.

Reautentisering går lenger: den etablerer et nytt autentisert forhold, som betyr at påloggingsinformasjonen vurderes på nytt. Alt som er utløpt, tilbakekalt eller endret i katalogen, blir synlig i det øyeblikket.

Hva en nøkkelnying faktisk erstatter

IKEv2 holder to slags tilknytninger med separate livssykluser. IKE SA beskytter kontrollkanalen, og CHILD SA beskytter den faktiske trafikken. Å fornye én er ikke synonymt med å koble klienten til på nytt.

Den oppdelingen forklarer et kjent mønster: trafikken flyter fint, så fornyes en CHILD SA og forslaget passer ikke lenger fordi noen redigerte fase 2 på den ene siden uker tidligere. Endringen lå der ufarlig helt til fornyingen utløste den.

Uoverensstemmelser i levetid oppfører seg på samme måte. Den siden som først når grensen sin, starter utvekslingen, og den andre må godta den.

Hva reautentisering vurderer på nytt

Ved reautentisering kan klientcertifikatet som var gyldig ved innlogging, nå være utløpt. En tilbakekalt påloggingsdetalj, et rotert passord eller en utilgjengelig andre faktor dukker alle opp her, ikke ved fornyingstidspunktet.

Derfor føles det som en rettelse å forlenge hver levetid, og det er det ikke. Du har utsatt kontrollen i stedet for å bestå den. Neste fornying kommer med samme defekt og et kortere avbruddsvindu til å oppdage den.

Noen implementasjoner overlapper gammel og ny tilstand under reautentisering. Andre gir et kort hull. Identiske innstillinger hos to leverandører kan derfor gi ulike brukeropplevelser. Test oppførselen i stedet for å anta at standarden pålegger den.

Les tidsstemplene før du endrer noe

Fang feiløyeblikket sammen med tilknytningens tilstand før og etter. Hvis den gamle tilknytningen ble erstattet uten en autentiseringsutveksling, var du ved en nøkkelnyingsgrense. Hvis en AUTH-utveksling vises rett før feilen, var du ved en reautentisering.

strongSwan eksponerer dette som separate innstillinger: rekey styrer nøkkelnying, reauth styrer om en ny autentisering skjer, og margin-verdier avgjør hvor langt før utløp hver av dem starter. dokumentasjonen om nøkkelnying beskriver samspillet, og den er verdt å lese før du kopierer en levetid fra et foruminnlegg.

Skill alt dette fra et vanlig nettverkstap. En brutt lenke gir en hendelse for registrering av død peer eller en storm av videresendinger, ikke en ren utveksling med samsvarende forslag.

Endre det som feilet

En avvisning av påloggingsinformasjon krever at identitetsproblemet rettes: forny sertifikatet, gjenopprett kontoen, registrer faktoren på nytt. En uoverensstemmelse i forslag eller levetid krever at parameterne sammenlignes på begge sider.

Å strekke levetider for å unngå symptomet er det ene alternativet som alltid ser ut som det virket, og aldri gjør det.

Test en kontrollert fornying

Tving fornyingen i stedet for å vente en dag på den. Gjenta deretter med en reautentisering hvis utrullingen støtter det, og følg med på begge endene.

En vellykket førstegangsinnlogging øver ikke noe av dette. Livssyklusen etterpå er der disse utrullingene faktisk bryter sammen.