Warum sich Ihr VPN länger erholt als der Ausfall dauert

Das WLAN ist vor dreißig Sekunden zurückgekommen, und das VPN ist immer noch down, also wirkt der Client defekt. Oft folgt er nur seinem eigenen Wiederholungsplan, und dieser Plan weiß nicht, dass das Netz gerade zurückgekehrt ist. Diese Lücke ist die ganze Geschichte: Die Erholungszeit ist der Ausfall plus die Wartezeit, auf die sich der Client bereits festgelegt hat. Jeden Timer zu senken ist eine Antwort, zu verstehen, welcher Timer zählt, die andere.

Drei Bedingungen entscheiden, ob die Abstimmung hilft: welche Stufe langsam ist, ob der Fehler überhaupt wiederholbar ist und wie der Client erfährt, dass das Netz zurück ist.

Drei Wartezeiten, die wie eine aussehen

Endpunktauflösung, IKE- oder TLS-Aushandlung, Paketwiederholung und einen neuen Versuch zu starten sind getrennte Ereignisse mit getrennten Timern. strongSwan dokumentiert Wiederholungs-Backoff für IKE, und OpenVPN hat eigene Wiederholungssteuerungen mit anderer Semantik. Eine Zahl von einem auf den anderen zu übertragen setzt voraus, dass die Mechanismen übereinstimmen, und das tun sie nicht. Lesen Sie die Logfolge, bevor Sie entscheiden, welches Intervall Sie vor sich haben.

Eine stille Minute im Log ist nicht zwangsläufig ein eingefrorener Prozess. Es kann ein exponentieller Backoff sein, der genau das tut, wofür er konfiguriert wurde.

Welche Stufe ist tatsächlich langsam?

Wenn das Log Versuche zeigt, die mit einem Authentifizierungsfehler scheitern, hilft keine Timer-Änderung, weil die Anmeldedaten falsch sind. Wenn überhaupt keine Versuche unternommen werden, befindet sich der Client in seinem Wartefenster, und der Plan ist die Lösung. Wenn Versuche unternommen werden und in eine Zeitüberschreitung laufen, liegt das Problem bei der Erreichbarkeit oder bei einem fehlenden Listener, und schnelleres Wiederholen füllt nur das Log. Jeder dieser drei Zustände hat einen anderen Verantwortlichen, und nur einer davon ist ein Timing-Problem.

Klassifizieren Sie den Fehler, bevor Sie eine Zahl anfassen.

Wann das Senken eines Timers hilft und wann nicht

Senken Sie die Wiederholungsobergrenze, wenn die dominierende Kostenposition das Warten nach einem kurzen, häufigen Ausfall ist, etwa bei einem Laptop, der zwischen Access Points wechselt. Lassen Sie sie in Ruhe, wenn die Fehler lang oder selten sind, weil aggressives Wiederholen genau in dem Moment Last hinzufügt, in dem der Konzentrator am wenigsten antworten kann. Ändern Sie in beiden Fällen einen Parameter, halten Sie ihn fest und messen Sie die nächste Erholung, statt anzunehmen, dass sie besser geworden ist.

Ein sehr niedriges Timeout, das in jedes Profil kopiert wird, ist der übliche Endzustand von Abstimmung ohne Messung.

Prüfen Sie die Bereitschaft, bevor Sie den Client beschuldigen

Der Client kann oft nicht sehen, dass das Netz nutzbar ist, bis etwas es versucht. Ein Captive Portal, eine DHCP-Erneuerung oder eine Routenänderung können ihn auf einen Plan warten lassen, der festgelegt wurde, bevor all das passierte. Beobachten Sie die Netzwerkstatusänderung des Betriebssystems und den nächsten Versuch des Clients auf derselben Uhr, und Sie sehen, wessen Wartezeit es ist. Die schnelle Variante ist, den Zeitstempel des Netzbereitschaftsereignisses und den Zeitstempel des ersten Versuchs danach zu notieren.

Bestätigen Sie außerdem, dass direkter Datenverkehr während der Wartezeit weiterhin blockiert ist, denn eine schnellere Wiederverbindung, die Datenverkehr leakt, ist keine Verbesserung.

Was festzuhalten ist

Notieren Sie, welcher Timer geändert wurde, von welchem Wert auf welchen, und wie die Erholung danach aussah. Notieren Sie auch die Client-Version, denn Standardwerte verschieben sich zwischen Releases, und ein undokumentiertes sehr niedriges Timeout wird die nächste Person verwirren, die das Profil liest.

Diese Aufzeichnung macht das nächste Software-Upgrade zu einem Vergleich statt zu einem Experiment.