Waarom een drukke IPsec-tunnel vroeg heronderhandelt: tijd- en volumelimieten

Ongeveer elke vijftig minuten valt een tunnel op een drukke verbinding een paar seconden weg, en de eerste verdachte is de klok. Associaties kunnen eindigen op een tijdslimiet of op een bytetelling, en welke grens het eerst komt, is degene die ze met pensioen stuurt. Op een verbinding die echt verkeer draagt, kan een volumelimiet ruim voor het einde van het ingestelde uur afgaan. Dus «te vroeg» is een uitspraak over de klok, niet over de associatie.

Tel wat de associatie telt, niet de interface

Een bytetotaal van een interface, de gecombineerde doorvoer van een dashboard en de eigen teller van de associatie zijn drie aparte getallen, en slechts één ervan wordt met de limiet vergeleken. Registreer de inkomende en uitgaande associatie apart met hun identificatoren, zodat een sleutelwissel die één richting raakt als een gerichte gebeurtenis verschijnt in plaats van als een raadsel. De teller van de associatie begint bij een sleutelwissel ook opnieuw, waardoor een totaal dat van de interface is genomen groeit terwijl de waarde die ertoe doet wordt gereset.

De rekensom is het een keer waard, zodat de orde van grootte ophoudt willekeurig te voelen. Een geteld budget van één gibibyte dat met een gestage 128 mebibyte per minuut wordt verbruikt, is in acht minuten op, en dat is een eenheidsomrekening, geen meting van je tunnel. Als het resulterende getal ver onder de tijdslimiet ligt, is volume het mechanisme en geen enkele klokobservatie verklaart het interval. Als het ver erboven ligt, is de bytelimiet niet je trigger en hoort de zoektocht elders.

Zachte en harde drempels zijn twee verschillende gebeurtenissen

Een zachte drempel vraagt om vervanging ruim voordat de harde limiet de associatie beëindigt, en implementaties leggen hun eigen marges en randomisatie bovenop wat je hebt geconfigureerd. Daarom is het waargenomen interval bijna nooit een rond getal. IPsec-architectuur beschrijft levensduren uitgedrukt in tijd en bytetellingen met de twee soorten drempels, en de vroegste afloop geldt. Behandel je één afgedrukte levensduur als een schema, dan zit je ernaast met de marge.

Lees het effectieve beleid uit de actieve toestand in plaats van het af te leiden uit een getal in een bestand, want de marge hoort bij de implementatie, niet bij je bedoeling. Weerst de neiging om grenzen naar hun maximum te rekken om het symptoom te sussen: een tunnel die volgens schema heronderhandelt gedraagt zich zoals ontworpen, en een langere levensduur stelt de gebeurtenis alleen uit terwijl een gecompromitteerde sleutel langer bruikbaar blijft. Als de vervanging zelf faalt, is de limiet de boodschapper en niet de fout.

Lees de effectieve levensduur uit de actieve toestand

Op strongSwan drukt swanctl --list-sas de samenvatting van de associatie af met de sleutelwissel- en levenstijden, zodat de waarde die de daemon wil afdwingen zichtbaar is zonder gissen. Op een Linux-host zonder daemonweergave meldt ip xfrm state de geconfigureerde zachte en harde byte- en packetlimieten naast de huidige tellers. Die twee uitlezingen beantwoorden verschillende vragen en beide zijn de moeite waard in het ticket.

swanctl --list-sas
ip -s xfrm state

Vergelijk de afgedrukte zachte drempel met het interval dat je hebt gemeten, want een vervanging die begint met een marge onder de harde limiet is normaal en een die nooit begint niet. Als de daemon één levensduur toont en de kerneltoestand een andere, kijk je naar twee lagen die het niet eens zijn, en dat is op zichzelf de bevinding.

Let op de uitwisseling die de SA vervangt

Houd de drie vernieuwingen gescheiden, want ze falen op verschillende manieren: een sleutelwissel van IKE SA bouwt een nieuwe besturingsassociatie, een sleutelwissel van CHILD SA vervangt de data-associatie, en herauthenticatie herhaalt de identiteitsuitwisseling. In IKEv2 bepaalt elke peer zijn eigen levensduren in plaats van één gedeelde waarde te onderhandelen, dus een uitwisseling die je niet zelf bent begonnen is gewoon. Een verschil in perfect forward secrecy is een veelvoorkomende reden dat een nieuwe child SA precies op het sleutelwisselinterval sterft, en het ziet er precies als een timerfout uit tot iemand het voorstel leest.

Vergelijk de oude associatie met haar opvolger en met de uitwisseling die haar heeft voortgebracht. Een verdwijnende identificator is routinematige vervanging; een afgewezen voorstel, een ontbrekend antwoord of het ontbreken van bruikbare opvolgerstatus is een andere gebeurtenis met een andere eigenaar. Bewaar dat bewijs voordat je iets wijzigt, want de versiespecifieke notities, het voorstel van de peer en de onderhandelde levensduren zijn wat de zaak een week later leesbaar maakt, nadat de logs zijn geroteerd.

Bewijs de vernieuwing in plaats van haar te verbergen

Accepteer de uitrol door een vernieuwing te doorlopen die je hebt gepland en niet een die je overkomt. Forceer één sleutelwissel binnen een onderhoudsvenster en bevestig daarna dat beide richtingen gegevens dragen en dat het applicatieresultaat ongewijzigd is, niet alleen dat de tunnelindicator groen is. Noteer welke limiet afging en welke uitwisseling erbij betrokken was.

Een conclusie van die vorm doorstaat de toets, terwijl een gewijzigde timerwaarde die de verbinding een middag rustig liet lijken dat niet doet. Als alleen de timer verschoof, verschoof het bewijs mee.