Varför en upptagen IPsec-tunnel byter nycklar tidigt: tids- och volymgränser

Ungefär var femtionde minut faller en tunnel på en upptagen länk ut i några sekunder, och den första misstänkta är klockan. Associationer kan avslutas på en tidsgräns eller på ett bytanttal, och vilken gräns som kommer först är den som pensionerar dem. På en länk som bär verklig trafik kan en volymgräns slå till långt innan den konfigurerade timmen är slut. Så «för tidigt» är ett påstående om klockan, inte om associationen.

Räkna det associationen räknar, inte gränssnittet

Ett gränssnitts bytansumma, en instrumentpanels sammanlagda genomströmning och associationens egen räknare är tre separata tal, och bara ett av dem jämförs med gränsen. Registrera den inkommande och den utgående associationen var för sig med deras identifierare, så att ett nyckelbyte som rör en riktning visas som en riktningsbestämd händelse i stället för ett mysterium. Associationens räknare börjar också om vid nyckelbyte, och därför växer en summa hämtad från gränssnittet medan värdet som betyder något nollställs.

Räkningen är värd att göra en gång, så att storleksordningen slutar kännas godtycklig. En räknad budget på en gibibyte som töms med jämna 128 mebibyte per minut är slut på åtta minuter, och det är en enhetsomvandling, inte en mätning av din tunnel. Om det resulterande talet ligger långt under tidsgränsen är volymen mekanismen, och ingen klocktittning förklarar intervallet. Om det ligger långt över är byggränsen inte din utlösare och sökningen hör hemma någon annanstans.

Mjuk och hård tröskel är två olika händelser

En mjuk tröskel begär en ersättning långt innan den hårda gränsen avslutar associationen, och implementationer lägger sina egna marginaler och slumpmässighet ovanpå det du konfigurerat. Därför är det observerade intervallet nästan aldrig ett runt tal. IPsec-arkitekturen beskriver livslängder uttryckta i tid och bytanttal med de två tröskeltyperna, och det tidigaste utgångsdatumet gäller. Behandlar du en tryckt livslängd som ett schema tar du fel med marginalens storlek.

Läs den effektiva policyn från körande tillstånd i stället för att härleda den från ett tal i en fil, eftersom marginalen tillhör implementationen, inte din avsikt. Motstå frestelsen att sträcka gränser mot maximum för att tysta symptomet: en tunnel som byter nycklar enligt schema beter sig som designat, och en längre livslängd skjuter bara upp händelsen medan en komprometterad nyckel hålls användbar längre. När själva ersättningen misslyckas är gränsen budbäraren och inte felet.

Läs den effektiva livslängden från körande tillstånd

På strongSwan skriver swanctl --list-sas ut sammanfattningen av associationen med dess nyckelbytes- och livstider, så värdet som daemonen avser att upprätthålla syns utan gissning. På en Linux-värd utan daemonvy rapporterar ip xfrm state de konfigurerade mjuka och hårda byte- och paketgränserna bredvid de aktuella räknarna. De två avläsningarna svarar på olika frågor och båda är värda att behålla i ärendet.

swanctl --list-sas
ip -s xfrm state

Jämför den tryckta mjuka tröskeln med intervallet du mätte, eftersom en ersättning som börjar med en marginal under den hårda gränsen är normal och en som aldrig börjar inte är det. Om daemonen visar en livslängd och kerneltillståndet en annan tittar du på två lager som inte är överens, och det är i sig fyndet.

Håll koll på utbytet som ersätter SA:n

Håll de tre förnyelserna åtskilda, eftersom de misslyckas på olika sätt: ett nyckelbyte för IKE SA bygger en ny kontrollassociation, ett nyckelbyte för CHILD SA ersätter dataassociationen, och nyautentisering upprepar identitetsutbytet. I IKEv2 avgör varje part sina egna livslängder i stället för att förhandla fram ett gemensamt värde, så ett utbyte du inte startade är normalt. En avvikelse i perfect forward secrecy är en vanlig orsak till att en ny child SA dör exakt vid nyckelbytesintervallet, och det ser exakt ut som ett timerfel tills någon läser förslaget.

Jämför den gamla associationen med sin efterträdare och med utbytet som skapade den. En identifierare som försvinner är rutinmässig ersättning; ett avvisat förslag, ett saknat svar eller avsaknaden av användbart efterträdartillstånd är en annan händelse med en annan ägare. Bevara dessa bevis innan du ändrar något, eftersom de versionsspecifika anteckningarna, motpartens förslag och de förhandlade livslängderna är det som gör ärendet läsbart en vecka senare, efter att loggarna roterat.

Bevisa förnyelsen i stället för att dölja den

Acceptera utrullningen genom att gå igenom en förnyelse du planerat, inte en som händer dig. Tvinga fram ett enda nyckelbyte inom ett underhållsfönster och bekräfta sedan att båda riktningarna bär data efteråt och att applikationsresultatet är oförändrat, inte bara att tunnelindikatorn är grön. Notera vilken gräns som slog till och vilket utbyte som var inblandat.

En slutsats av den formen tål granskning, medan ett ändrat timervärde som fick anslutningen att verka tyst en eftermiddag inte gör det. Om bara timern flyttade sig flyttade bevisen med den.