Welche VPN-Stufe versagt hat: IPsec, L2TP-Kontrolle oder PPP-Authentifizierung

Sie haben das Passwort geändert, und nichts hat sich bewegt, weil der Fehler nie in PPP lag. L2TP/IPsec meldet einen Verbindungsfehler für fünf sehr unterschiedliche Übergaben, und jede Übergabe hat ihre eigene Reparatur. Arbeiten Sie rückwärts: Finden Sie die letzte Stufe, die geklappt hat, und ändern Sie nur, was danach kommt. Die Reihenfolge unten entscheidet auch, welche Belege Sie zuerst sammeln.

Beantworten Sie vier Fragen der Reihe nach

Erzwingen Sie einen frischen Versuch, denn manche Clients zeigen den vorigen Fehler weiter, bis das Profil getrennt und neu verbunden wird. Antworten Sie dann: Gab es eine IPsec-Sicherheitsassoziation, erschienen eine L2TP-Kontrollverbindung und ein Call, erreichte PPP ein Authentifizierungsurteil, und hat IPCP dem Client eine Adresse gegeben? Das erste Nein ist die Stufe, die Sie reparieren. Alles danach ist ungetestet, ein abgelehnter Benutzername beweist also nichts, wenn nie eine Assoziation bestand.

Gleichen Sie die Uhren an beiden Enden ab, bevor Sie vergleichen. Ein Wiederholungsversuch, der IPsec bereinigte und bei PPP scheiterte, sieht wie ein einzelner Fehler aus, wenn der Client nur die letzte Meldung zeigt und das Serverlog noch den früheren Versuch enthält. Lesen Sie nach Zeitstempel, nicht nach der lautesten Zeile.

Wenn Sie nur den Screenshot des Nutzers haben, verlassen Sie sich auf die billigste Trennung: ein falscher vorab geteilter Schlüssel und ein xl2tpd, der nie antwortet, erzeugen denselben Text im Windows-Dialog, doch das eine braucht ein Geheimnis, das an beiden Enden geändert wird, und das andere einen gestarteten Daemon oder eine Firewallregel auf dem Server selbst. Ein Gerät dazwischen kann das innere 1701 nicht verwerfen, sobald IPsec im Transportmodus es eingewickelt hat, suchen Sie also nicht nach einem Pfadfilter, den es nicht gibt.

Was jede Schicht tatsächlich besitzt

IPsec schützt Pakete zwischen den beiden Peers; L2TP trägt eine PPP-Sitzung innerhalb dieses geschützten Pfads, weshalb RFC 3193 den Transportmodus statt eines eigenen Tunnels vorschreibt. Das Client-Label sagt L2TP, also wirken Tunnel und Anmeldung wie ein einziger Mechanismus. Sie sind es nicht: Die L2TP-Kontrollverbindung authentifiziert die Tunnelendpunkte, wo eine Bereitstellung es einschaltet, und PPP authentifiziert den Benutzer getrennt mit CHAP, PAP oder MS-CHAPv2 nach Serverrichtlinie.

Diese Trennung erklärt die beiden Geheimnisse, die Menschen ständig verwechseln. Ein vorab geteilter Schlüssel authentifiziert die IPsec-Peers. Benutzername und Passwort identifizieren den Benutzer gegenüber PPP. Das Windows-Shared Secret auf einem Profil neu einzutippen, das mit Zertifikaten authentifiziert, ändert auf der fehlschlagenden Stufe nichts, und das PPP-Passwort zu bearbeiten kann keinen fehlenden geschützten Kanal liefern. Dieselbe Zurückhaltung gilt für die Identitätsprüfung: Schalten Sie Peer-Identität oder Zertifikatsprüfung nicht ab, um einen Tunnel zu bekommen, denn dann verbindet sich der Pfad, nicht der Peer.

Auch die Authentifizierung ist nicht das Ende von PPP. Nachdem der Benutzer akzeptiert ist, verhandelt IPCP die Clientadresse sowie die DNS- und WINS-Optionen, die der Server herausgeben will. Ein Client kann CHAP oder MS-CHAPv2 bestehen und trotzdem ohne Adresse enden, was ein Fehler innerhalb von PPP und kein Routingproblem ist. Einfaches L2TP ohne IPsec bleibt gültig und ungeschützt, eine erfolgreiche Verbindung beweist also nie, dass der Verkehr geschützt ist; prüfen Sie, was der Server erzwingt, nicht das Label des Clients.

Entscheiden Sie nach der ersten fehlenden Stufe

Lesen Sie die Tabelle nach dem ersten fehlenden Punkt, von links nach rechts. Die rechte Spalte ist die einzige Arbeit, die sich in diesem Moment lohnt; alles links davon ist bereits bewiesen, und es erneut zu testen verbrennt das Ausfallfenster, ohne Information hinzuzufügen.

Drei Zeilen verdienen eine Warnung. Die 1701-Zeile ist, wo Windows-Clients hinter NAT gewöhnlich landen: Die Assoziation wird fertig, dann kommt nichts an, und die Kapselung ist die Ursache, nicht ein schlechtes Passwort. Die IPCP-Zeile ist die, die fälschlich als Routenproblem gelesen wird, weil Windows eine fehlende Adresse in Fehler 720 verpackt und das Taskleisten-Symbol nur sagt, die Verbindung sei fehlgeschlagen; dieser Fehler liegt nach der Authentifizierung und vor dem Routing. Die letzte Zeile ist überhaupt kein IPsec-Fehler, obwohl das Symbol getrennt meldet.

Befehle, die die Schichten trennen

Auf einem Linux-Server mit strongSwan listet swanctl --list-sas etablierte Assoziationen mit ihrer Peer-Identität, und ipsec statusall deckt ältere strongSwan- und libreswan-Hosts ab. Darunter zeigt ip xfrm state die tatsächlichen Assoziationen des Kernels, während ss -lunp | grep 1701 beweist, wo xl2tpd gebunden ist. Starten Sie xl2tpd -D im Vordergrund, um Kontrollverbindungen und Calls zu sehen, und schalten Sie pppd-Debug in /etc/ppp/options.xl2tpd ein, um die angebotene Methode und die Antwort zu sehen.

Sobald die Logs eine erfolgreiche Authentifizierung zeigen, ist die nächste Frage, ob IPCP abgeschlossen wurde. Prüfen Sie, ob ip range im Abschnitt [lns default] von /etc/xl2tpd/xl2tpd.conf noch freie Adressen hat und ob /etc/ppp/options.xl2tpd tatsächlich ms-dns und ms-wins enthält, wenn der Client sie erwartet. Ein erschöpfter Pool und eine fehlende DNS-Option sehen auf der Leitung unterschiedlich aus: Ersterer lässt den Client ohne Adresse und mit 720 zurück, letztere gibt eine Adresse, aber keinen Resolver, sodass Namen scheitern, während Pings auf rohe Adressen funktionieren. Keines von beiden wird durch erneutes Eingeben des Passworts repariert.

Auf dem Client schreibt das NetworkManager-L2TP-Plugin das pppd-Gespräch ins Journal, sodass journalctl -u NetworkManager -b gewöhnlich Tunnel steht, Authentifizierung abgelehnt von gar kein Tunnel trennt. Unter Windows meldet Get-VpnConnection die tatsächlichen Authentifizierungseinstellungen des Profils, und die RasClient-Ereignisse unter Application in der Ereignisanzeige benennen die fehlerhafte Komponente. Wenn der Dialog zu vage ist, aktivieren Sie netsh ras set tracing * enable.

Aufzeichnungen brauchen eine Vorsicht. Im Transportmodus von IPsec ist das innere UDP 1701 verschlüsselt, eine Aufzeichnung an der Außenschnittstelle zeigt also ESP, oder UDP 4500 unter NAT-T, und gar kein L2TP. Fehlendes 1701 in einer Aufzeichnung ist zu erwarten und kein Beweis für einen blockierten Port; beobachten Sie, ob sich die ESP- oder 4500-Zähler bewegen.

NAT, MTU und Routen: wo der Stack Sie täuscht

NAT bricht Annahmen, bevor irgendetwas authentifiziert ist. ESP ist sein eigenes IP-Protokoll, ein übersetzendes Gerät verwirft es also, sofern die Peers nicht kapseln; genau das liefert UDP 4500. Auf einem Windows-Server, der selbst hinter einem Heimrouter oder einem Cloud-NAT-Gateway steht, scheitert die IPsec-Stufe mit Fehler 789, bis AssumeUDPEncapsulationContextOnSendRule unter dem PolicyAgent-Schlüssel auf 2 gesetzt und der Rechner neu gestartet wird, und der Fehler bleibt von einem geschlossenen Port ununterscheidbar. Clients hinter NAT sind einfacher: Mit einer öffentlichen Adresse auf dem Server trägt sie NAT-T auf UDP 4500, und dieser Wert ist nicht beteiligt.

Sobald PPP steht, imitiert eine MTU mit schwarzem Loch einen toten Tunnel: Kleine Pakete kommen durch, ein TLS-Handshake oder ein Seitenaufruf hängt, und der Client zeigt vielleicht weiterhin verbunden. Senken Sie die MTU der Schnittstelle oder klemmen Sie MSS am Gateway, bevor Sie den Server beschuldigen. Split-Tunnel-Routing ist der andere Betrüger; ein Subnetz mit falscher Maske lässt den Tunnel gesund und eine Anwendung unerreichbar. Ein privater Hostname fügt einen eigenen Hopp hinzu: Verlässt die Abfrage den lokalen Resolver, scheitert der Name, bevor irgendeine Route getestet wird.

Checkliste, bevor Sie Anmeldedaten anfassen

Arbeiten Sie die Liste der Reihe nach ab und halten Sie beim ersten fehlschlagenden Punkt an. Jeder Schritt ist billig, und jeder schließt eine ganze Klasse von Änderungen aus.

1. Bestätigen Sie, dass die Assoziation an beiden Enden existiert, abgeglichen über die Peer-Identität statt über ein Verbunden-Label.
2. Bestätigen Sie, dass UDP 1701 xl2tpd erreicht; eine Assoziation ohne Call ist Ihr Fehler.
3. Lesen Sie das PPP-Urteil und, wenn authentifiziert wurde, das IPCP-Ergebnis, bevor Sie annehmen, das Passwort sei falsch.
4. Erst jetzt geben Sie Anmeldedaten erneut in dem Format ein, das der Server erwartet, denn ein Domänenpräfix ändert das Konto.
5. Scheitert es weiterhin, zeichnen Sie beide Enden mit abgeglichenen Zeitstempeln auf und vergleichen Sie Stufe für Stufe.

Beim zweiten Schritt zu stoppen bedeutet ein Pfad- oder Kapselungsproblem, und keine Passwortänderung bewegt es. Beim dritten Schritt zu stoppen bedeutet, dass das Log bereits die Methode oder den Adresspool nennt, der zu reparieren ist. So oder so ist die nächste Änderung eine, die Sie begründen können, und Sie hören auf, durch Einstellungen zu kreisen, die nie beteiligt waren.