Hvorfor en travl IPsec-tunnel skifter nøgler tidligt: tids- og volumenbegrænsninger

Omtrent hvert halvtreds minut falder en tunnel på et travlt link ud i nogle få sekunder, og den første mistænkte er uret. Associeringer kan slutte på en tidsgrænse eller på et bytetal, og uanset hvilken grænse der kommer først, er det den, der pensionerer dem. På et link med rigtig trafik kan en volumengrænse udløse længe før den konfigurerede time er gået. Så «for tidligt» er en udtalelse om uret, ikke om associeringen.

Tæl det, associeringen tæller, ikke grænsefladen

En grænseflades bytetotal, et dashboards samlede gennemstrømning og associeringens egen tæller er tre forskellige tal, og kun ét af dem sammenlignes med grænsen. Registrér den indgående og den udgående associering hver for sig med deres identifikatorer, så et nøgleskifte, der rører én retning, viser sig som en retningsbestemt hændelse i stedet for et mysterium. Associeringens tæller starter også forfra ved nøgleskifte, og derfor vokser en total taget fra grænsefladen, mens den værdi, der betyder noget, nulstilles.

Regnestykket er værd at lave én gang, så størrelsesordenen holder op med at føles vilkårlig. Et talt budget på én gibibyte, der drænes med en jævn 128 mebibyte i minuttet, er brugt op på otte minutter, og det er en enhedsomregning snarere end en måling af din tunnel. Hvis det resulterende tal ligger langt under tidsgrænsen, er volumen mekanismen, og ingen mængde urkiggeri vil forklare intervallet. Hvis det ligger langt over, er bytegrænsen ikke din udløser, og søgningen hører til et andet sted.

Bløde og hårde tærskler er to forskellige hændelser

En blød tærskel beder om en erstatning længe før den hårde grænse afslutter associeringen, og implementeringer lægger deres egne marginer og randomisering oven på det, du har konfigureret. Derfor er det observerede interval næsten aldrig et rundt tal. IPsec-arkitekturen beskriver levetider udtrykt i tid og bytetal med de to slags tærskler, og den tidligste udløb gælder. Behandler du én trykt levetid som en tidsplan, tager du fejl med marginens størrelse.

Læs den effektive politik fra den kørende tilstand i stedet for at udlede den fra et tal i en fil, fordi marginen tilhører implementeringen, ikke din hensigt. Modstå fristelsen til at strække grænserne mod deres maksimum for at dæmpe symptomet: en tunnel, der skifter nøgler efter tidsplan, opfører sig som designet, og en længere levetid udskyder blot hændelsen, mens en kompromitteret nøgle holdes brugbar længere. Når selve erstatningen fejler, er grænsen budbringeren og ikke fejlen.

Læs den effektive levetid fra den kørende tilstand

På strongSwan udskriver swanctl --list-sas associeringens oversigt med dens nøgleskifte- og levetidstider, så den værdi, dæmonen vil håndhæve, er synlig uden gætværk. På en Linux-vært uden dæmonoversigt rapporterer ip xfrm state de konfigurerede bløde og hårde byte- og pakkegrænser ved siden af de aktuelle tællere. De to aflæsninger svarer på forskellige spørgsmål, og begge er værd at gemme i billetten.

swanctl --list-sas
ip -s xfrm state

Sammenlign den trykte bløde tærskel med det interval, du målte, fordi en erstatning, der starter med en margin under den hårde grænse, er normal, og en erstatning, der aldrig starter, er ikke. Hvis dæmonen viser én levetid og kernetilstanden en anden, ser du på to lag, der er uenige, og det er i sig selv fundet.

Hold øje med den udveksling, der erstatter SA'en

Hold de tre fornyelser adskilt, fordi de fejler på forskellige måder: et nøgleskifte for IKE SA bygger en ny kontrolassociering, et nøgleskifte for CHILD SA erstatter dataassocieringen, og reagodkendelse gentager identitetsudvekslingen. I IKEv2 beslutter hver part sine egne levetider i stedet for at forhandle én fælles værdi, så en udveksling, du ikke selv startede, er normal. Uenighed om perfect forward secrecy er en hyppig grund til, at en ny child SA dør præcis på nøgleskifteintervallet, og det ser præcis ud som en timerfejl, indtil nogen læser forslaget.

Sammenlign den gamle associering med dens efterfølger og med den udveksling, der frembragte den. En identifikator, der forsvinder, er rutinemæssig erstatning; et afvist forslag, et manglende svar eller fraværet af brugbar efterfølgertilstand er en anden hændelse med en anden ejer. Bevar den dokumentation, før du ændrer noget, fordi de versionsspecifikke noter, modpartens forslag og de forhandlede levetider er det, der gør sagen læsbar en uge senere, efter logfilerne er roteret.

Bevis fornyelsen i stedet for at skjule den

Accepter udrulningen ved at gå igennem en fornyelse, du har planlagt, i stedet for en, der sker for dig. Tving et enkelt nøgleskifte ind i et vedligeholdelsesvindue, og bekræft derefter, at begge retninger bærer data bagefter, og at applikationsresultatet er uændret, ikke blot at tunnelindikatoren er grøn. Notér, hvilken grænse der udløste, og hvilken udveksling der var involveret.

En konklusion af den form holder for en granskning, mens en ændret timerværdi, der fik forbindelsen til at virke stille en eftermiddag, ikke gør. Hvis kun timeren flyttede sig, flyttede dokumentationen med.