IKEv2: nøglefornyelse kontra genautentificering — hvorfor forbindelsen falder senere

Tunnelen kommer op om morgenen og virker i timer. Så falder den, genopretter forbindelse efter et forsøg og gør det samme igen næste dag. Intet ændrede sig på netværket, og ingen rørte en adgangskode. Sessioner, der fejler ved en fornyelsesgrænse, krydser normalt en af to forskellige operationer, og kun én af dem tjekker dine legitimationsoplysninger igen. At læse hvilken der blev udløst, er hele diagnosen.

To operationer, der ser ens ud udefra

Nøglefornyelse erstatter sikkerhedsassociationer eller nøglemateriale under protokollens definerede udveksling. Godkendelse gentages ikke, så den identitet, der blev accepteret i starten af sessionen, føres blot videre.

Genautentificering går videre: den etablerer et nyt godkendt forhold, hvilket betyder, at legitimationsoplysningerne vurderes igen. Alt, der er udløbet, blevet tilbagekaldt eller ændret i kataloget, bliver synligt i det øjeblik.

Hvad en nøglefornyelse egentlig erstatter

IKEv2 holder to slags associationer med adskilte livscyklusser. IKE SA beskytter kontrolkanalen, og CHILD SA beskytter den faktiske trafik. At forny den ene er ikke det samme som at genoprette klientens forbindelse.

Den adskillelse forklarer et velkendt mønster: trafikken flyder fint, så fornyes en CHILD SA, og forslaget passer ikke længere, fordi nogen redigerede fase 2 på den ene side for uger siden. Ændringen lå der harmløst, indtil fornyelsen udnyttede den.

Uoverensstemmelser i levetid opfører sig på samme måde. Den peer, der først når sin grænse, starter udvekslingen, og den anden skal acceptere den.

Hvad genautentificering vurderer igen

Ved genautentificering kan klientcertifikatet, der var gyldigt ved login, nu være udløbet. En tilbagekaldt legitimationsoplysning, en roteret adgangskode eller en utilgængelig anden faktor dukker alle op her, ikke på fornyelsestidspunktet.

Derfor føles det som en rettelse at forlænge enhver levetid, og det er det ikke. Du har udskudt kontrollen i stedet for at bestå den. Den næste fornyelse kommer med samme defekt og et kortere afbrydelsesvindue til at opdage den.

Nogle implementeringer overlapper gammel og ny tilstand under genautentificering. Andre giver et kort hul. Identiske indstillinger hos to leverandører kan derfor give forskellige brugeroplevelser. Test adfærden i stedet for at antage, at standarden foreskriver den.

Læs tidsstemplerne, før du ændrer noget

Registrer fejløjeblikket sammen med associationens tilstand før og efter. Hvis den gamle association blev erstattet uden en godkendelsesudveksling, var du ved en fornyelsesgrænse. Hvis en AUTH-udveksling vises lige før fejlen, var du ved en genautentificering.

strongSwan eksponerer dette som separate indstillinger: rekey styrer nøglefornyelse, reauth styrer, om der sker en ny godkendelse, og margin-værdier bestemmer, hvor langt før udløb hver især starter. dokumentationen om nøglefornyelse beskriver samspillet, og den er værd at læse, før du kopierer en levetid fra et forumopslag.

Skeln alt dette fra et almindeligt netværkstab. Et brudt link giver en hændelse med registrering af død peer eller en storm af genfremsendelser, ikke en ren udveksling med matchende forslag.

Ændr det, der fejlede

En afvisning af legitimationsoplysninger kræver, at identitetsproblemet rettes: forny certifikatet, gendan kontoen, tilmeld faktoren igen. En uoverensstemmelse i forslag eller levetid kræver, at parametrene sammenlignes på begge sider.

At strække levetider for at undgå symptomet er den ene mulighed, der altid ser ud, som om den virkede, og aldrig gør det.

Test en kontrolleret fornyelse

Tving fornyelsen frem i stedet for at vente en dag på den. Gentag derefter med en genautentificering, hvis udrulningen understøtter en, og hold øje med begge ender.

Et vellykket første login øver intet af dette. Livscyklussen derefter er, hvor disse udrulninger faktisk brækker.