IKEv2: nyckelomsättning kontra reautentisering — varför anslutningen faller senare

Tunneln kommer upp på morgonen och fungerar i timmar. Sedan faller den, återansluter efter ett försök och gör samma sak nästa dag. Ingenting ändrades i nätverket och ingen rörde ett lösenord. Sessioner som misslyckas vid en nyckelomsättningsgräns korsar vanligtvis en av två olika operationer, och bara en av dem kontrollerar dina inloggningsuppgifter igen. Att läsa vilken som utlöstes är hela diagnosen.

Två operationer som ser likadana ut utifrån

Nyckelomsättning ersätter säkerhetsassociationer eller nyckelmaterial inom det utbyte som protokollet definierar. Autentiseringen upprepas inte, så identiteten som accepterades i början av sessionen bärs bara vidare.

Reautentisering går längre: den etablerar en ny autentiserad relation, vilket innebär att inloggningsuppgifterna utvärderas igen. Allt som löpt ut, återkallats eller ändrats i katalogen blir synligt i det ögonblicket.

Vad en nyckelomsättning faktiskt ersätter

IKEv2 håller två typer av associationer med separata livscykler. IKE SA skyddar kontrollkanalen och CHILD SA skyddar den faktiska trafiken. Att förnya en är inte synonymt med att återansluta klienten.

Den uppdelningen förklarar ett välkänt mönster: trafiken flyter bra, sedan förnyas en CHILD SA och förslaget passar inte längre eftersom någon redigerade fas 2 på ena sidan veckor tidigare. Ändringen låg där ofarlig tills förnyelsen utövade den.

Skillnader i livslängd beter sig på samma sätt. Den part som först når sin gräns startar utbytet, och den andra måste acceptera det.

Vad reautentisering omvärderar

Vid reautentisering kan klientcertifikatet som var giltigt vid inloggningen nu ha löpt ut. En återkallad inloggningsuppgift, ett roterat lösenord eller en otillgänglig andra faktor dyker alla upp här, inte vid förnyelsetillfället.

Därför känns det som en rättelse att förlänga varje livslängd och det är det inte. Du har skjutit upp kontrollen i stället för att klara den. Nästa förnyelse kommer med samma defekt och ett kortare avbrottsfönster att upptäcka den i.

Vissa implementationer överlappar gammalt och nytt tillstånd under reautentisering. Andra ger en kort lucka. Identiska inställningar hos två leverantörer kan därför ge olika användarupplevelser. Testa beteendet i stället för att anta att standarden föreskriver det.

Läs tidsstämplarna innan du ändrar något

Fånga feletstillfället tillsammans med associationens tillstånd före och efter. Om den gamla associationen ersattes utan ett autentiseringsutbyte var du vid en nyckelomsättningsgräns. Om ett AUTH-utbyte dyker upp precis före felet var du vid en reautentisering.

strongSwan exponerar detta som separata inställningar: rekey styr nyckelomsättningen, reauth styr om en ny autentisering sker, och margin-värden avgör hur långt före utgången var och en börjar. dokumentationen om nyckelomsättning beskriver samspelet, och den är värd att läsa innan du kopierar en livslängd från ett foruminlägg.

Skilj allt detta från en vanlig nätverksförlust. En bruten länk ger en händelse för upptäckt av död peer eller en storm av återsändningar, inte ett rent utbyte med matchande förslag.

Ändra det som misslyckades

En avvisning av inloggningsuppgifter kräver att identitetsproblemet åtgärdas: förnya certifikatet, återställ kontot, registrera faktorn på nytt. En skillnad i förslag eller livslängd kräver att parametrarna jämförs på båda sidor.

Att sträcka ut livslängder för att undvika symptomet är det enda alternativet som alltid ser ut att ha fungerat och aldrig gör det.

Testa en kontrollerad förnyelse

Tvinga fram förnyelsen i stället för att vänta en dag på den. Upprepa sedan med en reautentisering om driftsättningen stöder det, och övervaka båda ändarna.

En lyckad första inloggning övar inget av detta. Livscykeln efteråt är där dessa driftsättningar faktiskt går sönder.