VPN-Authentifizierung fehlgeschlagen: Selten liegt es am Port oder am DNS

Authentifizierung fehlgeschlagen bedeutet, dass der Dienst eine Identität erhalten und abgelehnt hat, was eine engere Aussage ist, als die meisten hineinlesen. Der Port ist offen, die TLS-Sitzung hat sich möglicherweise vollständig aufgebaut, und etwas an den Anmeldedaten oder am Konto wurde zurückgewiesen. Netzwerkeinstellungen zu ändern kann das nicht beheben, und ein erneuter Versuch kann das Konto sperren. Der Fehlertext benennt bereits die Stufe, also beginnen Sie dort.

Der Fehler hat Ihnen bereits gesagt, welche Stufe gescheitert ist

Eine Verbindung, die ihren TLS-Handshake nie abschließt, hat die Authentifizierung überhaupt nicht erreicht. Eine Verbindung, die den Handshake abschließt und dann eine Zurückweisung der Anmeldedaten meldet, hat sie erreicht und ist dort gescheitert. Diese beiden Ausgänge erfordern unterschiedliche Untersuchungen, und sie werden häufig verwechselt, weil beide mit einem geschlossenen Fenster enden.

OpenVPN macht den Unterschied durch eine AUTH_FAILED-Meldung des Servers deutlich, die eine Entscheidung und kein Transportfehler ist. Eine Zeitüberschreitung der TLS-Aushandlung oder ein Zertifikatsprüfungsfehler gehört zur früheren Stufe. Lesen Sie, welche Sie haben, bevor Sie Anmeldedaten anfassen, denn ein Passwort-Reset kann keinen Handshake reparieren, und eine Firewall-Änderung kann keine abgelehnte Anmeldung reparieren. Eine Zeile im Client-Log beantwortet die Frage.

Dieselbe Logik gilt für eine Sitzung, die sich verbindet und später abbricht. Ein Fehler bei der erneuten Authentifizierung in der vierzigsten Minute ist ein anderer Defekt als eine Ablehnung bei der ersten Anmeldung, und das Intervall ist der Hinweis.

Bestätigen Sie, dass das Profil auf den richtigen Dienst zeigt

Das auf der Website eines Anbieters verwendete Konto ist nicht immer das Konto, das sein VPN-Gateway akzeptiert. Ein gespeichertes Profil kann auch noch lange auf ein altes Gateway zeigen, nachdem der Dienst umgezogen ist.

Vergleichen Sie den Endpunkt im Profil mit dem vom Betreiber veröffentlichten und prüfen Sie, welches Identitätssystem das Gateway befragt. Ein Passwort-Reset im Webportal ändert nichts, wenn sich der Tunnel gegen ein separates Verzeichnis authentifiziert. Anmeldedaten für einen fremden öffentlichen Server funktionieren auf Ihrem nicht, und ein Arbeitspasswort in einem über eine nicht vertrauenswürdige Nachricht erhaltenen Profil zu testen, ist ohnehin ein schlechter Tausch. Bestätigen Sie die Herkunft, bevor Sie etwas eingeben.

Zwei Minuten am Profil ersparen einen Tag des Ratens bei Anmeldedaten.

Das Anmeldeformat ist Teil der Anmeldedaten

Ein Benutzername kann eine E-Mail-Form, ein Domänenpräfix oder ein Verzeichnissuffix benötigen. Das Gateway vergleicht die Zeichenfolge, die es erhalten hat, also ist die Form Teil der Anmeldedaten und nicht Dekoration.

Schließen Sie dann die langweiligen Ursachen aus, bevor Sie eskalieren. Prüfen Sie das Tastaturlayout, ein durch Kopieren eingefügtes Leerzeichen am Ende und einen alten Eintrag im Passwortmanager. Bestätigen Sie nach einem Reset, dass das VPN dieselbe Identitätsquelle nutzt wie die Seite, auf der das Passwort geändert wurde. Wenn diese Angaben stimmen, hören Sie auf zu raten und fragen Sie den Betreiber, ob das Konto aktiviert und für den VPN-Zugang berechtigt ist. Das ist eine Korrektur auf der Dienstseite und keine Clienteinstellung.

openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager

Die Logzeile mit AUTH_FAILED enthält meist einen Grundcode oder eine Challenge-Zeichenfolge. Kopieren Sie sie exakt, statt sie beim Hilferuf umzuformulieren.

Zweite Faktoren haben ihren eigenen Vertrag

Das Profil kann einen Einmalkode, eine interaktive Challenge oder eine Browser-Anmeldung erwarten, die dem Client ein Token zurückgibt. Verwenden Sie den vom Betreiber unterstützten Ablauf, statt einen zu erfinden.

Hängen Sie keinen Code an das Passwort an, sofern dieses Format nicht ausdrücklich verlangt wird, denn manche Installationen verwenden ein separates Feld und andere eine Challenge-Zeichenfolge. Prüfen Sie bei zeitbasierten Codes die Uhr des Geräts, da schon wenige Minuten Abweichung jeden Code ungültig machen. Wenn die Browser-Anmeldung gelingt und der Client nie fortfährt, notieren Sie genau diesen Punkt, denn er kennzeichnet die Übergabe und nicht die Anmeldedaten. Ein weiterer Passwort-Reset hilft wahrscheinlich nicht.

Ein Sitzungslimit ist die andere häufige Ablehnung. Erlaubt das Konto eine Sitzung, kann eine zweite Anmeldung die erste beenden, und das Symptom sieht wie eine flatternde Verbindung aus und nicht wie eine Richtlinie.

Ein Zertifikat ist kein Passwort

Ein Client-Zertifikat kann ablaufen oder widerrufen werden, während das Kontopasswort völlig korrekt bleibt. Eine Passphrase für einen privaten Schlüssel ist wieder ein drittes Geheimnis, und sie schützt eine Datei und kein Konto.

Lesen Sie den Fehler, bevor Sie etwas ersetzen, und holen Sie sich dann den richtigen Ersatz beim verifizierten Betreiber. Lassen Sie die Server-Identitätsprüfung dabei eingeschaltet: ein fremdes Zertifikat zu akzeptieren oder den privaten Schlüssel eines anderen zu kopieren ist keine Reparatur, sondern ein zweiter Vorfall. Testen Sie dann die Ressource, die Sie tatsächlich brauchen, denn ein verbundener Tunnel mit einem unerreichbaren Dienst gehört zu einer anderen Untersuchung. Notieren Sie, welche Stufe gescheitert ist, damit die nächste Person nicht den ganzen Ablauf von vorn beginnt.

Wenn die Sitzung aufgebaut wird und später scheitert, notieren Sie das Intervall und alle nahen Erneuerungsereignisse. Diese Aufzeichnung trennt ein Problem der Token-Lebensdauer von einem Fehler bei der ersten Anmeldung und ist der Unterschied zwischen einer Fünf-Minuten-Korrektur und einer Woche voller Wiederholungen.