Varför din IPsec-tunnel fungerar fram till den första CHILD SA-nyckelförnyelsen

Tunneln kom upp, pinget svarade och alla signerade. Fyra timmar senare faller sessionen, parterna loggar ett förslags- eller nyckelutbytesfel, och den första gissningen är att något ändrades i nätverket. Inget ändrades. En tunnel som bär trafik har bevisat att de två parterna är överens om hur de autentiserar och hur de skyddar den första underordnade associationen, och den har inte bevisat något om nyckelutbytet de kommer att kräva vid förnyelsen. Avvikelsen sitter i glappet mellan de två händelserna.

Ansluten betyder inte att PFS-inställningarna stämmer

Med IKEv2 skapas den första underordnade associationen under autentiseringsutbytet, och dess nycklar härleds från material som IKE-associationen redan har producerat. Inget separat Diffie-Hellman-utbyte sker för det underordnade, så en policy som kräver ett vid förnyelsen prövas inte vid uppstart.

Förnyelsen är ett annat utbyte. När nyckeln för en underordnad association förnyas kan parterna göra ett nytt nyckelutbyte med gruppen som nämns i deras förslag, och det är det första tillfället då gruppinställningarna jämförs. Därför kan två parter som inte är överens autentisera, installera en underordnad association och släppa igenom trafik, och sedan misslyckas vid förnyelsen.

Var avvikelsen gömmer sig i förslagssträngen

I strongSwan läggs gruppen till i det underordnade förslaget, och därför ser en sträng som aes256gcm16-prfsha256-ecp256 ut som ett krypteringsval men bär också ett krav på nyckelutbyte. En part som bara erbjuder aes256gcm16-prfsha256 har inget sådant krav, och de två listorna överlappar på kryptering men skiljer sig på utbytet.

Läs det underordnade förslaget och IKE-förslaget som separata listor. En grupp som syns i IKE-listan säger inget om den underordnade listan, och att redigera den ena medan man läser den andra är det vanliga sättet detta missas på.

Läs felet, inte filen du redigerade

Hitta notify-meddelandet som avslutade utbytet. En underordnad nyckelförnyelse som returnerar »inget acceptabelt förslag« pekar på förslagslistorna; en förnyelsebegäran som aldrig får svar pekar på vägen eller på en part som slutade lyssna. Dessa två kräver olika rättelser, och formuleringen i loggraden skiljer dem.

Bekräfta den körande konfigurationen och inte den på disken. En fil som sparats men inte laddats, eller en anslutning som lästs in igen från en annan include, ger en avvikelse som ingen redigering av den synliga filen kan rätta.

Tre händelser som alla kallas nyckelförnyelse

Förnyelse av IKE-associationens nyckel, IKE-reautentisering och förnyelse av den underordnade associationens nyckel är separata operationer med separata förslagsregler. Ett fel som rapporteras vid en av dem säger inget direkt om de andra, och en logg som blandar dem läses som ett enda återkommande fel när det är tre.

Notera vilken händelse parterna nämner och kontrollera sedan bara förslagen för den händelsen. Ändra en lista, ladda om och tvinga fram samma händelse igen. Om loggen nämner en reautentisering är IKE-förslaget det som ska läsas. Om den nämner en underordnad nyckelförnyelse bär det underordnade förslaget gruppen som spelar roll.

Att stänga av förnyelsen är inte en rättning

Att sätta förnyelsetiden till noll dämpar utbytet som misslyckas, och tunneln överlever sedan tills den rivs eller parterna startar om. Det du köpt är en längre livslängd för nyckeln och en avvikelse som kommer att möta dig igen under en migrering, en revision eller en leverantörsuppdatering. Samma sak gäller livslängder som sträcks långt utöver den policy som andra sidan förväntar sig.

Justera i stället förslagen. Välj en grupp som båda parterna implementerar, sätt den i det underordnade förslaget i båda ändar, och håll förnyelsepolicyn inom det intervall som organisationen faktiskt kräver.

Bevisa det med utbytet som misslyckades

Korta den underordnade förnyelsetiden i ett underhållsfönster så att händelsen kommer inom minuter i stället för timmar, eller starta en manuell underordnad nyckelförnyelse. Håll sedan utkik efter en lyckad förnyelse och bekräfta att trafiken fortsätter genom den, eftersom en ny handskakning som installerar en underordnad association men tappar applikationsflödet är ett annat fel.

Återställ sedan den normala livslängden och behåll båda händelseregistreringarna, den misslyckade och den lyckade. Det bevis du vill ha är att anslutningen överlever sin egen livscykel, inte att den överlevde ett ping.