Hvorfor en travel IPsec-tunnel bytter nøkler tidlig: tids- og volumbegrensninger

Omtrent hvert femtionde minutt faller en tunnel på en travel forbindelse ut i noen sekunder, og den første mistenkte er klokken. Assosiasjoner kan avsluttes på en tidsgrense eller på et byttetall, og hvilken grense som kommer først, er den som pensjonerer dem. På en forbindelse som bærer reell trafikk, kan en volumgrense utløses lenge før den konfigurerte timen er omme. Så «for tidlig» er en uttalelse om klokken, ikke om assosiasjonen.

Tell det assosiasjonen teller, ikke grensesnittet

Et grensesnitts byttetotal, en dashboards samlede gjennomstrømning og assosiasjonens egen teller er tre separate tall, og bare ett av dem sammenlignes med grensen. Registrer den innkommende og den utgående assosiasjonen hver for seg med identifikatorene deres, slik at et nøkkelbytte som berører én retning vises som en retningsbestemt hendelse i stedet for et mysterium. Assosiasjonens teller starter også på nytt ved nøkkelbytte, og derfor vokser en total hentet fra grensesnittet mens verdien som betyr noe nullstilles.

Regnestykket er verdt å gjøre én gang, slik at størrelsesordenen slutter å føles vilkårlig. Et telt budsjett på én gibibyte som tømmes med jevne 128 mebibyte per minutt, er brukt opp på åtte minutter, og det er en enhetsomregning, ikke en måling av tunnelen din. Hvis det resulterende tallet ligger langt under tidsgrensen, er volumet mekanismen, og ingen klokkekikking vil forklare intervallet. Hvis det ligger langt over, er bytegrensen ikke utløseren din, og søket hører til et annet sted.

Myk og hard terskel er to forskjellige hendelser

En myk terskel ber om en erstatning lenge før den harde grensen avslutter assosiasjonen, og implementasjoner legger sine egne marginer og randomisering oppå det du har konfigurert. Derfor er det observerte intervallet nesten aldri et rundt tall. IPsec-arkitekturen beskriver levetider uttrykt i tid og byttetall med de to terskeltypene, og den tidligste utløpsdatoen gjelder. Behandler du én trykt levetid som en tidsplan, tar du feil med marginens størrelse.

Les den effektive policyen fra kjørende tilstand i stedet for å utlede den fra et tall i en fil, fordi marginen tilhører implementasjonen, ikke intensjonen din. Motstå fristelsen til å strekke grenser mot maksimum for å dempe symptomet: en tunnel som bytter nøkler etter tidsplan, oppfører seg som designet, og en lengre levetid utsetter bare hendelsen mens en kompromittert nøkkel holdes brukbar lenger. Når selve erstatningen feiler, er grensen budbringeren og ikke feilen.

Les den effektive levetiden fra kjørende tilstand

På strongSwan skriver swanctl --list-sas ut sammendraget av assosiasjonen med nøkkelbytte- og levetidstidene, slik at verdien daemonen vil håndheve er synlig uten gjetting. På en Linux-vert uten daemonvisning rapporterer ip xfrm state de konfigurerte myke og harde byte- og pakkegrensene ved siden av de gjeldende tellerne. De to avlesningene svarer på forskjellige spørsmål, og begge er verdt å ta vare på i saken.

swanctl --list-sas
ip -s xfrm state

Sammenlign den trykte myke terskelen med intervallet du målte, fordi en erstatning som starter med en margin under den harde grensen, er normal, og en som aldri starter, er det ikke. Hvis daemonen viser én levetid og kjernetilstanden en annen, ser du på to lag som ikke er enige, og det er i seg selv funnet.

Følg med på utvekslingen som erstatter SA-en

Hold de tre fornyelsene atskilt, fordi de feiler på forskjellige måter: et nøkkelbytte for IKE SA bygger en ny kontrollassosiasjon, et nøkkelbytte for CHILD SA erstatter dataassosiasjonen, og reagodkjenning gjentar identitetsutvekslingen. I IKEv2 avgjør hver part sine egne levetider i stedet for å forhandle én felles verdi, så en utveksling du ikke startet, er vanlig. Uoverensstemmelse om perfect forward secrecy er en hyppig årsak til at en ny child SA dør nøyaktig på nøkkelbytteintervallet, og det ser nøyaktig ut som en timerfeil til noen leser forslaget.

Sammenlign den gamle assosiasjonen med etterfølgeren og med utvekslingen som skapte den. En identifikator som forsvinner, er rutinemessig erstatning; et avvist forslag, et manglende svar eller fraværet av brukbar etterfølgertilstand er en annen hendelse med en annen eier. Bevar disse bevisene før du endrer noe, fordi de versjonsspesifikke notatene, motpartens forslag og de forhandlede levetidene er det som gjør saken lesbar en uke senere, etter at loggene har rotert.

Bevis fornyelsen i stedet for å skjule den

Aksepter utrullingen ved å gå gjennom en fornyelse du planla, ikke en som skjer med deg. Tving gjennom ett enkelt nøkkelbytte innenfor et vedlikeholdsvindu, og bekreft deretter at begge retninger bærer data etterpå og at applikasjonsresultatet er uendret, ikke bare at tunnelindikatoren er grønn. Noter hvilken grense som utløste, og hvilken utveksling som var involvert.

En konklusjon av den formen tåler gransking, mens en endret timerverdi som fikk forbindelsen til å virke stille en ettermiddag, ikke gjør det. Hvis bare timeren flyttet seg, flyttet bevisene seg med den.