IKEv2: Schlüsselerneuerung gegen erneute Authentifizierung — warum die Verbindung später abbricht

Der Tunnel kommt morgens hoch und läuft stundenlang. Dann bricht er ab, verbindet sich nach einem Versuch neu und macht am nächsten Tag dasselbe. Im Netzwerk hat sich nichts geändert, und niemand hat ein Passwort angefasst. Sitzungen, die an einer Erneuerungsgrenze scheitern, überschreiten meist eine von zwei unterschiedlichen Operationen, und nur eine davon prüft Ihre Anmeldedaten erneut. Zu lesen, welche ausgelöst wurde, ist die gesamte Diagnose.

Zwei Operationen, die von außen ähnlich aussehen

Die Schlüsselerneuerung ersetzt Sicherheitsassoziationen oder Schlüsselmaterial im Rahmen des vom Protokoll definierten Austauschs. Die Authentifizierung wird nicht wiederholt, daher wird die zu Sitzungsbeginn akzeptierte Identität einfach weitergetragen.

Die erneute Authentifizierung geht weiter: Sie stellt eine frische authentifizierte Beziehung her, was bedeutet, dass die Anmeldedaten erneut bewertet werden. Alles, was abgelaufen, widerrufen oder im Verzeichnis geändert wurde, wird in diesem Moment sichtbar.

Was eine Schlüsselerneuerung tatsächlich ersetzt

IKEv2 führt zwei Arten von Assoziationen mit getrennten Lebenszyklen. Die IKE SA schützt den Steuerkanal, und CHILD SAs schützen den tatsächlichen Datenverkehr. Eine davon zu erneuern ist kein Synonym für das Wiederverbinden des Clients.

Diese Trennung erklärt ein vertrautes Muster: Der Verkehr läuft gut, dann wird eine CHILD SA erneuert, und der Vorschlag passt nicht mehr, weil jemand Wochen zuvor Phase 2 auf einer Seite bearbeitet hat. Die Änderung lag harmlos da, bis die Erneuerung sie ausübte.

Abweichungen bei der Lebensdauer verhalten sich genauso. Welcher Peer zuerst sein Limit erreicht, beginnt den Austausch, und der andere muss ihn akzeptieren.

Was die erneute Authentifizierung neu bewertet

Bei der erneuten Authentifizierung kann das Client-Zertifikat, das beim Login gültig war, inzwischen abgelaufen sein. Eine widerrufene Anmeldeinformation, ein rotiertes Passwort oder ein nicht verfügbarer zweiter Faktor treten hier zutage, nicht zum Zeitpunkt der Erneuerung.

Deshalb fühlt sich das Verlängern jeder Lebensdauer wie eine Reparatur an und ist keine. Sie haben die Prüfung verschoben, statt sie zu bestehen. Die nächste Erneuerung kommt mit demselben Defekt und einem kürzeren Ausfallfenster, um ihn zu bemerken.

Manche Implementierungen überlappen alten und neuen Zustand während der erneuten Authentifizierung. Andere erzeugen eine kurze Lücke. Identische Einstellungen bei zwei Herstellern können daher unterschiedliche Benutzererfahrungen ergeben. Testen Sie das Verhalten, statt anzunehmen, der Standard schreibe es vor.

Lesen Sie die Zeitstempel, bevor Sie etwas ändern

Erfassen Sie den Moment des Fehlschlags zusammen mit dem Zustand der Assoziation davor und danach. Wurde die alte Assoziation ohne einen Authentifizierungsaustausch ersetzt, waren Sie an einer Erneuerungsgrenze. Erscheint direkt vor dem Fehlschlag ein AUTH-Austausch, waren Sie bei einer erneuten Authentifizierung.

strongSwan stellt dies als getrennte Einstellungen bereit: rekey steuert die Schlüsselerneuerung, reauth steuert, ob eine neue Authentifizierung stattfindet, und Margin-Werte entscheiden, wie weit vor dem Ablauf jede beginnt. die Dokumentation zur Schlüsselerneuerung beschreibt die Interaktion, und sie ist lesenswert, bevor Sie eine Lebensdauer aus einem Forenbeitrag kopieren.

Unterscheiden Sie all dies von einem gewöhnlichen Netzwerkverlust. Eine abgerissene Verbindung erzeugt ein Dead-Peer-Erkennungsereignis oder einen Sturm von Neuübertragungen, keinen sauberen Austausch mit passenden Vorschlägen.

Ändern Sie das, was gescheitert ist

Eine Ablehnung der Anmeldedaten erfordert, das Identitätsproblem zu beheben: Erneuern Sie das Zertifikat, stellen Sie das Konto wieder her, registrieren Sie den Faktor neu. Eine Abweichung bei Vorschlag oder Lebensdauer erfordert den Vergleich der Parameter auf beiden Seiten.

Lebensdauern zu strecken, um das Symptom zu vermeiden, ist die eine Option, die immer so aussieht, als hätte sie funktioniert, und es nie tut.

Testen Sie eine kontrollierte Erneuerung

Erzwingen Sie die Erneuerung, statt einen Tag darauf zu warten. Wiederholen Sie es dann mit einer erneuten Authentifizierung, wenn das Deployment eine unterstützt, und beobachten Sie beide Enden.

Ein erfolgreicher Erst-Login übt nichts davon. Der Lebenszyklus danach ist der Punkt, an dem diese Deployments tatsächlich brechen.