Warum dein VPN jedes Mal ausfällt, wenn die Schlüssel rotieren

Die Verbindung läuft eine Stunde und stirbt dann, und der Client meldet nichts Nützlicheres als disconnected. Genau dieser Zeitraum ist der Hinweis, denn am Erneuerungsaustausch unterscheidet sich etwas vom ersten Handshake. Der Timer entscheidet nur, wann du ihm begegnest. Sichere die Nachrichten aus diesem Austausch statt des abschließenden Labels.

Lies die Stufe, nicht das Label

In IKEv2 werden die IKE-Assoziation und die CHILD-Assoziation nach getrennten Zeitplänen erneuert. Ein Vorschlag, der für die erste Aushandlung akzeptabel war, ist es für die zweite nicht automatisch. Eine kann abgeschlossen werden, während die andere abgelehnt wird, was einen Tunnel erzeugt, der zur Hälfte existiert. Erfasse den Austausch mit dem Werkzeug, das ihn besitzt, statt mit einer Client-Logzeile:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

Bei OpenVPN ist das entsprechende Ereignis eine Neuverhandlung, die von der Version und den Bereitstellungseinstellungen gesteuert wird. Sein Authentifizierungsverhalten hat eigene Fehlermodi. Die entscheidende Nachricht nennt die gescheiterte Stufe, und du solltest sie wörtlich festhalten, statt sie in ein Ticket umzuformulieren.

Schreib auch die Zeitstempel auf. Ein Ausfall in festem Abstand nach der letzten erfolgreichen Aushandlung ist ein ganz anderer Befund als einer, der während der Nutzung zufällig auftritt, und der Abstand ist oft der einzige Beweis, der überlebt.

Vergleiche den Vorschlag, der scheitert

Ein abgelehnter Vorschlag erzeugt eine klare Meldung beim Responder. Die übliche Ursache ist ein Unterschied zwischen beiden Enden bei Algorithmus, Schlüssellänge, Gruppe oder Lebensdauer. Die erste CHILD-Aushandlung kann erfolgreich gewesen sein, weil die Gegenseite sie eingeleitet hat, was bedeutet, dass deren Vorschlagsliste verwendet wurde. Schau dir beide Enden an, bevor du etwas änderst.

Abweichungen bei der Lebensdauer verdienen besondere Aufmerksamkeit, denn ein Wert, der an einem Ende großzügig wirkte, kann das andere Ende zu einer Erneuerung veranlassen, die es nicht abschließen kann. Die Dokumentation zum Neuverschlüsselungsverhalten beschreibt, wie die Assoziationserneuerung ausgelöst wird und wie die beiden Enden in ihren Zeiterwartungen abweichen können. Vergleiche, was jedes Ende zu unterstützen behauptet, statt was die Konfigurationsdatei nahelegt.

Ein altes Profil oder eine Anbietervorlage kann einen Vorschlag festnageln, den die aktuelle Version nicht mehr anbietet. Die Abweichung zeigt sich erst, wenn eine neue Aushandlung erzwungen wird.

Trenne ein Zugangsdatenproblem von einem unerreichbaren Peer

Eine Erneuerung, die an der Authentifizierung scheitert, sieht im Client ähnlich und auf dem Server völlig anders aus. Wird ein Zugangsdatum bei der Neuverhandlung erneut geprüft, erzeugen ein abgelaufenes Zertifikat, ein widerrufenes Konto oder ein geändertes Passwort einen Ausfall genau im Erneuerungsintervall, während jede frühere Verbindung erfolgreich war. Ein unerreichbarer Peer ist die dritte Möglichkeit, und er erzeugt gar keine Ablehnung: Die Pakete gehen hinaus und nichts antwortet. Dieser Fall folgt meist einer Netzwerkänderung statt einem Timer, prüfe also, ob der Fehler nach einem Roaming, einer Ruhephase oder einer Routenänderung auftritt.

Unterscheide die drei danach, was das ferne Ende protokolliert hat. Eine Ablehnung mit Grund, ein Authentifizierungsfehler und Stille sind drei verschiedene Korrekturen. Ein Client-Neustart verschmilzt sie zu einer nutzlosen Beobachtung.

Prüfe die Zertifikatsdaten und den Kontostatus, bevor du das Netzwerk beschuldigst. Beides ist billig zu prüfen und beides ist in der Client-Meldung unsichtbar.

Erzwinge eine Erneuerung und lies das Ergebnis

Erzwinge eine Erneuerung über die vom Betreiber unterstützte Methode, statt eine Stunde auf die nächste zu warten. Halte dabei die erforderliche Fehlerrichtlinie intakt. Verifikation abzuschalten oder Lebensdauern auf einen Tag zu strecken lässt das Symptom aus deinen Logs verschwinden, ohne irgendetwas zu korrigieren. Es hinterlässt außerdem einen längeren Ausfall für die nächste Person.

Wenn der Fix steht, prüfe den erneuerten Tunnel und stelle dann eine neue Anfrage aus der Anwendung. Eine Anwendungssitzung, die beim Wechsel der Assoziation lebte, braucht möglicherweise ihre eigene Erholung, obwohl der Tunnel wieder gesund ist. Nutzer melden das als weiterhin kaputtes VPN.

Halte die Release-Versionen, die ausgehandelten Timer und die gescheiterte Stufe fest. Der nächste Vorfall lässt sich dann mit diesem vergleichen, statt erneut aus dem Gedächtnis beschrieben zu werden.