Sitzungszeitgeber und Anmeldetoken der VPN laufen getrennt ab

Ein VPN-Abbruch kann aus Gründen geschehen, die vom Client aus identisch aussehen und unter der Oberfläche nichts gemeinsam haben: die Tunnelsitzung endete, ein Inaktivitätstimer schlug zu, oder ein Anmeldenachweis, den der Client wiederverwendete, wurde ungültig. Jeder Grund hat einen anderen Verantwortlichen und eine andere Lösung. Gerade die Fehlerfolge im Moment des Abbruchs unterscheidet sie, und sie ist meist eine einzige Zeile.

Drei Uhren laufen gegen einen Tunnel, und nur eine davon ist der Tunnel.

Drei verschiedene Uhren an einem Tunnel

Die Sitzungsuhr gehört dem Gateway: eine maximale Verbindungsdauer, ein Inaktivitäts-Timeout oder beides, und sie beendet den Tunnel, sobald eines davon erreicht ist. Die Token-Uhr gehört dem Anmeldesystem, und sie entscheidet, wie lange ein Nachweis ohne einen Menschen erneut vorgelegt werden kann. Die Pfaduhr gehört dem NAT oder der Firewall zwischen Client und Gateway, und sie lässt Zuordnungen für Ströme ablaufen, die sie als beendet ansieht. Alle drei erzeugen eine Trennung, und keine erzeugt dieselbe Logzeile.

Nur die erste ist ein VPN-Konzept. Die anderen beiden stammen aus Identität und Netzwerk, und sie werden routinemäßig damit verwechselt.

Wie das Token tatsächlich wiederverwendet wird

OpenVPN-Server können nach der ersten Anmeldung ein Anmeldetoken ausstellen, sodass eine Neuverhandlung des Steuerkanals den Benutzer nicht erneut nach Zugangsdaten fragt. Der Client legt dieses Token weiterhin vor, und der Server entscheidet, wie lange es annehmbar bleibt. Ist die Lebensdauer des Tokens kürzer als das Neuverhandlungsintervall, scheitert die nächste Neuverhandlung, und der Client meldet einen Anmeldefehler statt eines Timeouts. Deshalb funktioniert dasselbe Profil eine Stunde lang und scheitert dann an einem festen Punkt.

Das Neuverhandlungsintervall ist eine eigene Einstellung. Eine Änderung verschiebt, wann das Token vorgelegt wird, nicht wie lange es lebt.

Wie jeder Ablauf vom Client aus aussieht

Ein Sitzungs-Timeout kommt meist als saubere Trennung mit serverseitigem Grund, oft nach einer vorhersehbaren Dauer und ohne angehängten Anmeldefehler. Ein Inaktivitäts-Timeout sieht wie Stille aus: der Tunnel befördert keinen Verkehr mehr, dann gibt das Keepalive auf. Ein Token-Ablauf kommt als AUTH_FAILED mitten in einer Sitzung, die eine Sekunde zuvor noch lief.

Lesen Sie die Zeile und schauen Sie dann auf die Uhr. Eine Dauer, die zu einem konfigurierten Wert passt, ist kein Zufall.

Warum ein gespeichertes Passwort nicht hilft

Ein zwischengespeichertes Passwort beantwortet eine Abfrage nach einem Passwort. Es verlängert keine Token-Lebensdauer und erfüllt keine Abfrage nach einem zweiten Faktor oder einer Gerätezustandsprüfung. Häufigere Wiederholungen, kürzere Verbindungs-Timeouts oder ein erneuter Import des Profils ändern nichts daran, wie lange das Identitätssystem den Nachweis akzeptiert.

Die dauerhaften Korrekturen sind die richtige Lebensdauer am richtigen Objekt oder ein Client-Ablauf, der die geforderte Abfrage ohne einen Menschen abschließen kann.

Was zu dokumentieren und zu testen ist

Notieren Sie alle drei Werte: die Sitzungs- und Inaktivitätslimits des Gateways, die Lebensdauer des Tokens und den kürzesten relevanten Zuordnungs-Timeout auf dem Pfad. Testen Sie dann jeden Ablauf gezielt, indem Sie einen Wert verkürzen, beobachten, was der Client meldet, und ihn wiederherstellen. Bestätigen Sie, was der Benutzer an jeder Grenze tun muss, denn ein vollständiger Login jede Stunde ist eine Grundsatzentscheidung, die jemand bewusst hätte treffen sollen.

Ein Abbruch, der ganz ohne Anmeldeereignis kommt, gehört zum Pfad oder zum Inaktivitätstimer, und das ist eine andere Untersuchung mit anderen Beweisen.