Warum eine VPN-Wiederverbindung erneut Anmeldedaten verlangt

Ein Tunnel, der stundenlang funktionierte, verlangt in dem Moment ein Passwort, in dem das Notebook aufwacht, und an der Konfiguration hat sich nichts geändert. Geändert hat sich der Zustand der Anmeldedaten, die die Wiederverbindung wiederverwenden wollte. Drei Arten von Material bestimmen das, und nur eine davon übersteht eine beliebige Lücke.

Lesen Sie, welche davon der Client angefordert hat, denn die drei laufen nach unterschiedlichen Uhren ab und scheitern mit unterschiedlichen Meldungen.

Drei Arten wiederverwendbaren Materials

Ein zwischengespeichertes Passwort ist ein Geheimnis, das der Client hält, und es bleibt gültig, bis das Konto es ändert. Ein Sitzungstoken wird vom Server nach einer erfolgreichen Anmeldung ausgestellt, trägt seine eigene Lebensdauer und kann jederzeit widerrufen werden. Ein TLS-Sitzungsticket oder eine IKE-Sicherheitsassoziation ist Protokollzustand, billig fortzusetzen und völlig unabhängig von Ihrem Passwort. Jedes wird von einer anderen Komponente ausgestellt, und jedes läuft zu seinen eigenen Bedingungen ab.

Das erste übersteht einen Neustart, das zweite übersteht meist einen Ruhezustand, und das dritte übersteht einen Netzwerkwechsel möglicherweise gar nicht. Verwechslung führt zur falschen Lösung, etwa zum Zurücksetzen eines Passworts, das nie abgelehnt wurde.

Die Aufforderung selbst ist die Diagnose. Ein Browserfenster oder ein Zweitfaktor-Code bedeutet, dass der Server eine interaktive Authentifizierung verlangt hat, während ein stilles Scheitern ohne Aufforderung bedeutet, dass der Client nie weit genug kam, um gefragt zu werden.

Schlüsselerneuerung ist keine erneute Authentifizierung

Eine Schlüsselerneuerung ersetzt Schlüssel und behält die authentifizierte Identität, weshalb sie auf einem gesunden Tunnel regelmäßig still stattfindet. Eine erneute Authentifizierung wiederholt die Identitätsprüfung selbst, und das ist das Ereignis, das Sie braucht. IKEv2 trennt beides ausdrücklich, und ein Peer kann in einem konfigurierten Intervall eine vollständige erneute Authentifizierung verlangen, unabhängig davon, wie viele Schlüsselerneuerungen dazwischen lagen. Von außen sehen beide Ereignisse gleich aus, bis man liest, welches das Protokoll nennt.

OpenVPN verhält sich in seiner eigenen Terminologie genauso: Ein Neuverhandlungsintervall frischt den Datenkanal auf, und ein Authentifizierungstoken kann an den Client zurückgegeben werden, um bei der nächsten Verbindung eine vollständige Anmeldung zu vermeiden. Dieses Token hat eine Lebensdauer, und der Server entscheidet, ob er es erneut akzeptiert.

Eine Wiederverbindung nach acht Stunden kann also scheitern, wo eine Wiederverbindung nach acht Minuten gelang, ohne jede Konfigurationsänderung auf beiden Seiten. Das ist die ganze Erklärung für eine Aufforderung, die erst nach dem Mittagessen erscheint.

Wenn der Client die neue Herausforderung nicht abschließen kann

Eine Richtlinie, die einen Browserschritt verlangt, scheitert an einem Client, der keinen anzeigen kann. Headless-Server, Startskripte und alte Profile, die für reine Passwortauthentifizierung gebaut wurden, stoßen alle an diese Wand, und der Fehler erscheint oft als allgemeiner Timeout statt als Authentifizierungsfehler.

Geräte- und Netzwerkwechsel können ebenfalls in ein Auswertungsfenster der Richtlinie fallen, sodass ein Wechsel von Wi-Fi zu einem Hotspot mit einer Prüfung zusammenfällt, die ohnehin stattgefunden hätte. Die Koinzidenz lässt das Netzwerk schuldig aussehen, während der Timer die Ursache ist.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

Die erste Zeile zeigt Neuverhandlungs- und Authentifizierungsereignisse im eigenen Protokoll des Clients, und die zweite zeigt die Sicherheitsassoziationen, die ein strongSwan-Peer derzeit hält. Vergleichen Sie die Zeitstempel mit dem Moment, in dem die Aufforderung erschien; eine Übereinstimmung bestätigt den Timer und nicht das Netzwerk.

Was zu melden ist und was nicht abgeschaltet werden sollte

Wenn eine manuelle Anmeldung gelingt und die automatische Wiederverwendung durchgängig scheitert, sagen Sie dem Betreiber genau das. Es benennt die Komponente: den Wiederverwendungspfad, nicht die Anmeldedaten. Nennen Sie die Uhrzeit des Fehlers, das verwendete Konto und die Art der Aufforderung, die Sie gesehen haben.

Deaktivieren Sie nicht den zweiten Faktor, überspringen Sie nicht die Zertifikatsprüfung und kleben Sie keine Anmeldedaten in ein Skript, um die Wiederverbindung still zu machen. Jedes davon entfernt die Prüfung, für die die Richtlinie existiert, und jedes verwandelt eine Anmeldeaufforderung in einen Vorfall.

Fragen Sie stattdessen nach dem unterstützten Ablauf: einen Client, der die Herausforderung abschließen kann, eine Token-Lebensdauer, die zum Arbeitstag passt, oder ein genehmigtes nicht-interaktives Profil für die Maschine, die nicht fragen kann. Das sind alles Konfigurationsentscheidungen, die jemand genehmigen kann, was eine Notlösung nicht ist.