IKEv2: sleutelvernieuwing versus herauthenticatie — waarom de verbinding later wegvalt
De ene vernieuwt het sleutelmateriaal, de andere herhaalt de identiteitscontrole. Welke grens je sessie overschreed, bepaalt wat er hersteld moet worden.
De tunnel komt ’s ochtends op en werkt urenlang. Dan valt hij weg, verbindt opnieuw na één poging en doet de volgende dag hetzelfde. Er veranderde niets op het netwerk en niemand raakte een wachtwoord aan. Sessies die bij een vernieuwingsgrens mislukken, passeren meestal een van twee verschillende bewerkingen, en slechts één daarvan controleert je inloggegevens opnieuw. Lezen welke werd geactiveerd, is de hele diagnose.
Twee bewerkingen die er van buiten hetzelfde uitzien
Sleutelvernieuwing vervangt beveiligingsassociaties of sleutelmateriaal binnen de door het protocol bepaalde uitwisseling. Authenticatie wordt niet herhaald, dus de identiteit die bij de start van de sessie werd geaccepteerd, wordt eenvoudig doorgegeven.
Herautenticatie gaat verder: ze vestigt een nieuwe geauthenticeerde relatie, wat betekent dat de inloggegevens opnieuw worden beoordeeld. Alles wat verlopen, ingetrokken of in de directory gewijzigd is, wordt op dat moment zichtbaar.
Wat een sleutelvernieuwing werkelijk vervangt
IKEv2 houdt twee soorten associaties met afzonderlijke levenscycli bij. De IKE SA beschermt het controlekanal, en CHILD SA’s beschermen het werkelijke verkeer. Eén vernieuwen is geen synoniem voor de client opnieuw verbinden.
Die scheiding verklaart een bekend patroon: het verkeer loopt goed, dan wordt een CHILD SA vernieuwd en het voorstel past niet meer omdat iemand weken eerder fase 2 aan één kant heeft aangepast. De wijziging lag daar onschadelijk tot de vernieuwing hem uitvoerde.
Verschillen in levensduur gedragen zich hetzelfde. Welke peer het eerst zijn limiet bereikt, begint de uitwisseling, en de andere moet die accepteren.
Wat herauthenticatie opnieuw beoordeelt
Bij herauthenticatie kan het clientcertificaat dat bij het inloggen geldig was, inmiddels verlopen zijn. Een ingetrokken inloggegeven, een geroteerd wachtwoord of een niet beschikbare tweede factor komen allemaal hier naar boven, niet op het moment van vernieuwen.
Daarom voelt het verlengen van elke levensduur als een oplossing en is het er geen. Je hebt de controle uitgesteld in plaats van gehaald. De volgende vernieuwing komt met hetzelfde defect en een korter storingsvenster om het op te merken.
Sommige implementaties overlappen oude en nieuwe toestand tijdens herauthenticatie. Andere veroorzaken een korte leemte. Identieke instellingen bij twee leveranciers kunnen dus verschillende gebruikerservaringen geven. Test het gedrag in plaats van aan te nemen dat de standaard het voorschrijft.
Lees de tijdstempels voordat je iets verandert
Leg het moment van falen vast samen met de toestand van de associatie ervoor en erna. Als de oude associatie werd vervangen zonder authenticatie-uitwisseling, zat je op een vernieuwingsgrens. Als vlak voor het falen een AUTH-uitwisseling verschijnt, zat je bij een herauthenticatie.
strongSwan biedt dit als afzonderlijke instellingen: rekey regelt sleutelvernieuwing, reauth regelt of een nieuwe authenticatie plaatsvindt, en margin-waarden bepalen hoeveel voor het verlopen elk begint. de documentatie over sleutelvernieuwing beschrijft de interactie, en het is de moeite waard die te lezen voordat je een levensduur uit een forumbericht kopieert.
Onderscheid dit alles van gewoon netwerkverlies. Een verbroken link levert een dead-peer-detectiegebeurtenis of een herzendstorm op, geen schone uitwisseling met overeenkomende voorstellen.
Verander wat er mislukte
Een afwijzing van inloggegevens vereist dat het identiteitsprobleem wordt opgelost: vernieuw het certificaat, herstel het account, registreer de factor opnieuw. Een verschil in voorstel of levensduur vereist dat de parameters aan beide kanten worden vergeleken.
Levensduren oprekken om het symptoom te vermijden is de enige optie die altijd lijkt te hebben gewerkt en het nooit doet.
Test een gecontroleerde vernieuwing
Forceer de vernieuwing in plaats van er een dag op te wachten. Herhaal het daarna met een herauthenticatie als de uitrol er een ondersteunt, en kijk naar beide uiteinden.
Een geslaagde eerste login oefent hier niets van. De levenscyclus daarna is waar deze uitrollen echt breken.