Ein Fehler, drei Geheimnisse: Welche VPN-Zugangsdaten sind gescheitert?
Der Client zeigt für jede Stufe einen Fehler. Lesen Sie die Assoziation, den Benutzeraustausch und die Methode, bevor Sie ein Passwort zurücksetzen, das niemand geprüft hat.
„Authentifizierung fehlgeschlagen“ kann auf ein Serverzertifikat, einen vorab geteilten Maschinenschlüssel oder ein Benutzerpasswort zeigen. Welches gemeint ist, hängt vom Protokoll ab, denn jedes Protokoll definiert einen anderen Satz von Geheimnissen. Setzen Sie das falsche zurück, bleibt der Fehler unverändert. Der Ausweg besteht darin, zuerst festzustellen, wie viele Nachweise das Protokoll verlangt, bevor Sie irgendetwas ändern.
Zwei Nachweise in entgegengesetzte Richtungen
Ein Tunnel muss beantworten, ob er das richtige Gateway erreicht hat, und getrennt davon, wer der Benutzer ist. Der Gateway-Nachweis liegt auf Maschinenebene: ein Serverzertifikat, ein vorab geteilter Schlüssel oder ein statischer öffentlicher Schlüssel. Der Benutzernachweis liegt auf Personenebene: ein Passwort, ein Token, ein Clientzertifikat oder gar nichts. Das sind entgegengesetzte Vertrauensrichtungen, und sie verbrauchen unterschiedliches Material.
IKEv2 führt den Gateway-Nachweis innerhalb von IKE_AUTH aus und lässt bei Verwendung von EAP danach den Benutzernachweis in einem separaten Austausch folgen. Die IKEv2-Spezifikation hält beides als getrennte Abschnitte, was ein starker Hinweis darauf ist, wo Sie nachsehen sollten, wenn eine Nachricht beide Runden abdeckt.
Lesen Sie die Stufe, nicht die Meldung
Der Client zeigt eine einzige Fehlerzeichenkette, egal welche Stufe gescheitert ist, also trägt die Zeichenkette selbst fast keine Information. Information trägt der Zustand, den Sie auf jeder Stufe prüfen können: ob eine Assoziation existiert, ob ein Benutzeraustausch begonnen hat und ob der Client die Methode angeboten hat, die das Gateway wollte. Die Tabelle ordnet die Stufen genau so, statt nach Protokollnamen.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Nur die zweite Zeile handelt von Zugangsdaten, die ein Benutzer erneut eingeben kann. Die anderen drei sind Konfigurationstatsachen, und genau diese Diskrepanz ist der Grund, warum so viele dieser Berichte mit einem Passwort-Reset enden, der nichts ändert. Lesen Sie die Zeile, die zu Ihrem Befund passt, bevor Sie ein Feld anfassen.
Ein Protokoll mit zwei Geheimnissen zeigt seine Karten
L2TP über IPsec macht die Anzahl sichtbar, weil die beiden Prüfungen in verschiedenen Prozessen ablaufen. Die IPsec-Schicht muss zuerst mit einem vorab geteilten Schlüssel oder einem Zertifikat hochkommen, und erst dann versucht PPP darin eine Benutzeranmeldung.
Ist das Maschinengeheimnis falsch, entsteht keine Assoziation und die Benutzerdaten werden nie versucht. Ist das Maschinengeheimnis richtig und das Benutzergeheimnis falsch, existiert die Assoziation, und PPP weist die Anmeldung zurück, nachdem der Tunnel bereits steht. Beide erzeugen dieselbe Meldung auf dem Bildschirm, aus zwei verschiedenen Ereignissen.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerEine leere Assoziationsliste schließt die Benutzerebene sofort aus, also prüfen Sie sie vor dem Passwort. Eine bestehende Assoziation mit wiederholten PPP-Fehlern zeigt in die andere Richtung, auf die Benutzerebene oder auf das Authentifizierungsprotokoll darin. Keine der beiden Schlussfolgerungen ist aus dem Fehlertext des Clients zu gewinnen.
Wovon reine Passwortanmeldung tatsächlich abhängt
Zugang nur mit Passwort ist für L2TP, PPTP, SSTP und IKEv2 mit EAP üblich. WireGuard hat diese Option überhaupt nicht, weil seine Gegenstellen Schlüssel und keine Benutzer sind. Bei OpenVPN ergibt sich die Antwort aus der Clientzertifikat-Anforderung des Servers: Ein Gateway, das Zertifikat und Passwort zugleich verlangt, weist einen Client mit nur einem Passwort weiterhin zurück, egal was in das Feld getippt wird.
Welche Komponente Sie brauchen, folgt aus derselben Antwort. Eine Passwortanmeldung unter IKEv2 verlangt einen Client, der EAP spricht, während eine Zertifikatsanmeldung den privaten Schlüssel des Clients und die Kette des Servers braucht. Installieren Sie die falsche, liest sich das Scheitern wie ein Zugangsdatenfehler, obwohl die Authentifizierungsmethode selbst fehlt.
Ändern Sie eine Sache, dann testen Sie erneut
Stellen Sie zuerst drei Tatsachen fest: welches Protokoll läuft, wie viele Geheimnisse es definiert und welche davon zur Maschine und nicht zum Benutzer gehören. Maschinen scheitern auf der ersten Stufe, Menschen auf der zweiten, und die Verwechslung beider ist das ganze Problem.
Ändern Sie dann genau eine Sache und testen Sie erneut vom selben Client. Diese Disziplin macht aus einem verwirrenden Fehlschlag eine Korrektur, die Sie der nächsten Person beschreiben können, und das ist nützlicher als eine funktionierende Verbindung, die niemand erklären kann.