Rekey, Reconnect oder Reauthentifizierung: Was brauchen Sie?

Eine Sitzung, die seit Stunden läuft, behält ihre Schlüssel nicht ewig – das ist beabsichtigt. Drei verschiedene Ereignisse werden als Schlüsselrotation bezeichnet: neues Sitzungsmaterial unter einer bestehenden Assoziation, ein vollständiger Neuaufbau der Verbindung und eine Wiederholung der Identitätsprüfung. Jedes hat einen anderen Auslöser, andere Kosten und eine andere Fehlersignatur. Wählen Sie das falsche, bewirkt die Korrektur entweder nichts oder legt den Tunnel ohne Grund lahm.

Die Entscheidung hängt davon ab, welche Schicht tatsächlich abgelaufen ist.

Drei Vorgänge, die Rotation genannt werden

Ein Rekey erzeugt frische Verkehrsschlüssel innerhalb der bestehenden Kontrollbeziehung, und zwar mit dem Mechanismus, den das Protokoll vorgibt. IKEv2 tut das mit einer neuen Child-Sicherheitsassoziation, TLS 1.3 mit einer Key-Update-Nachricht und WireGuard mit einem neuen Handshake, sobald seine Zeit- oder Nachrichtengrenzen erreicht sind. Die Tunneladressen und die authentifizierte Identität bleiben, wo sie waren.

Ein Reconnect verwirft die Verbindung und baut sie von Anfang an neu auf, was Adresszuweisung, Routeninstallation und jede Aushandlung des ersten Versuchs wiederholt.

Eine Reauthentifizierung wiederholt den Identitätsnachweis selbst, was ein Credential, ein Zertifikat oder einen zweiten Faktor umfassen kann. Sie kann mit oder ohne Reconnect erfolgen, je nach Produkt.

Was Nutzer bei der Erneuerung bemerken

Ein Rekey sollte nahezu unsichtbar sein. Assoziationskennungen ändern sich, Zähler können zurückgesetzt werden, und Anwendungen behalten ihre Sockets; eine kurze Pause in eine Richtung ist während des Austauschs normal. Eine neue Kennung in einer Statusliste ist kein Beweis für einen Fehler. Die Logzeile nach dem Austausch sagt Ihnen, ob er abgeschlossen wurde.

Ein echter Abbruch bei der Erneuerung zeigt auf eine bestimmte Stelle. Proposal-Mismatch, abgelaufenes Credential oder Pfadwechsel erzeugen jeweils eine andere Logzeile, und nur eine davon wird durch Anpassen der Laufzeiten behoben.

Wo die drei in der Praxis auseinandergehen

Ist nur Schlüsselmaterial abgelaufen, dann Rekey. Haben sich Peer-Adresse, Route oder NAT-Bindung geändert und kommen keine Pakete mehr an, dann Reconnect. Verlangt die Organisation eine regelmäßige Identitätsprüfung, ist das Reauthentifizierung, und keine Laufzeitanpassung ersetzt sie.

Die Protokollvorgaben enthalten meist die richtige Antwort. WireGuard wechselt die Schlüssel nach einer Zeit- und Datenschwelle ohne Zutun des Nutzers; IKEv2-Laufzeiten werden pro Child-Assoziation ausgehandelt; TLS-basierte Tunnel rotieren Schlüssel innerhalb der bestehenden Sitzung. Laufzeiten zu erhöhen, um einen wiederkehrenden Fehler zu vermeiden, verschiebt den Ausfall und verlängert die Exposition, falls ein Schlüssel kompromittiert wird.

Ein Vorbehalt zählt bei langen Sitzungen: Häufigkeit allein schafft keine Forward Secrecy. Die Eigenschaft hängt davon ab, wie Sitzungsschlüssel mit langfristigen Geheimnissen zusammenhängen und ob alte Schlüssel vernichtet werden – eine Frage von Design und Implementierung, nicht einer Einstellung.

Vorgaben wählen, dann die Phase protokollieren

Behalten Sie die Vorgaben des Herstellers, sofern keine dokumentierte Anforderung etwas anderes verlangt, und ändern Sie Laufzeiten auf beiden Seiten, wenn überhaupt. Protokollieren Sie dann, welche Phase jedes Ereignis erreicht hat, damit der nächste Fall an derselben Stelle des Handshakes geprüft werden kann.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Führen Sie nach einer Korrektur eine kontrollierte Erneuerung durch und senden Sie frischen Anwendungsverkehr über die neue Assoziation. Ein Tunnel, der als etabliert meldet, aber nichts weiterleitet, ist der Ausfall, den diese Prüfung abfangen soll.