L2TP verbindet, aber die PPP-Aushandlung scheitert: welche Phase?

Der IPsec-Tunnel kommt zustande, der Client zeigt einen geschützten Peer, und dann stirbt die Verbindung, bevor irgendetwas das private Subnetz erreicht. Diese Lücke ist PPP bei seiner eigenen Arbeit: Link-Optionen, Benutzerauthentifizierung und Adressvergabe geschehen alle erst, nachdem der verschlüsselte Tunnel existiert. Nichts an einem erfolgreichen Austausch der ersten Phase liefert ein Passwort oder eine innere Adresse. Lesen Sie die Phasen der Reihe nach, und der Fehler benennt sich meist selbst.

Der Tunnel ist nur die erste Schicht

L2TP trägt PPP-Rahmen in einem IPsec-geschützten Tunnel, was bedeutet, dass zwei unabhängige Aushandlungen gelingen müssen, bevor ein Paket geroutet werden kann. Die äußere beweist, dass sich beide Seiten über Schlüssel und Identitäten einig sind. Die innere entscheidet über Link-Parameter, ob der Benutzer sich authentifiziert und welche Adresse der Client erhält.

Ein Fehler innerhalb von PPP sieht in jedem Client, der nur eine Statusleuchte zeigt, wie ein defekter Tunnel aus. Behandelt man ihn als Tunnelproblem, führt das zu neuer Schlüsselaushandlung, Neustarts von Diensten und schließlich zum Austausch eines gemeinsamen Geheimnisses, das nie falsch war. Die nützliche Unterscheidung ist billig: Wenn der Peer-Austausch abgeschlossen ist und der Client zu einer Benutzernamenabfrage oder einer Authentifizierungsphase übergeht, ist der Tunnel in Ordnung. Alles nach diesem Punkt gehört zu PPP.

Lesen Sie die letzte Phase, die erfolgreich war

Gehen Sie das Protokoll vorwärts durch und halten Sie bei der ersten Phase an, die nicht abgeschlossen wurde. Zuerst kommt LCP, dann die Authentifizierung, dann IPCP für die IPv4-Parameter.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Ein LCP-Timeout bedeutet, dass sich die beiden Enden nie über grundlegende Link-Optionen geeinigt haben, was ein nicht passendes Profil oder ein blockiertes inneres Protokoll ist und kein schlechtes Passwort. Eine ausdrückliche Authentifizierungsablehnung ist der umgekehrte Fall: Der Link kam hoch und eine Seite wies die Zugangsdaten zurück. Ein IPCP-Timeout nach erfolgreicher Authentifizierung deutet auf Adresspools oder Serverrichtlinien hin. Jeder dieser Fälle hat einen anderen Verantwortlichen und eine andere Reparatur, deshalb ist die Phase wichtiger als der endgültige Fehlertext.

Bewahren Sie den Protokollauszug zusammen mit dem Phasennamen im Ticket auf. Ein eingefügter Schwanz ohne die Phasengrenze lädt den nächsten Leser zum Raten ein, und Raten kostet hier eine Stunde.

Einigkeit zwischen Client und Server

Beide Enden müssen dieselbe Authentifizierungsmethode akzeptieren, und ein gespeichertes Profil kann eine anfordern, die der Server im letzten Quartal abgeschafft hat. Verwaltete Installationen verbergen außerdem die Serverseite, wo der Ablehnungsgrund meist beim Benutzer statt beim Gerät erfasst wird.

Aktivieren Sie eine unterstützte Methode statt jeder Altoption, weil ein Client, der fünf Methoden anbietet, verschleiert, welche fehlgeschlagen ist. Fragen Sie den Administrator nach der Richtlinie auf der Serverseite und der genauen Ablehnung, was nicht verlangt, dass jemand ein Passwort veröffentlicht. Eine Altmethode, die aktiviert wird, um einen Client zu retten, breitet sich gern auf jedes Profil aus, das die Datei kopiert.

Prüfen Sie die Adresse, nicht die Anmeldung

Eine abgeschlossene Anmeldung ist keine nutzbare Sitzung. IPCP handelt die innere Adresse aus, und ein erschöpfter Pool oder eine Richtlinie, die den Client ablehnt, kann trotzdem einen verbundenen Tunnel ohne Ziele zum Routen hinterlassen.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Prüfen Sie zuerst die innere Adresse, dann die Route und den Resolver für die Ressource, die Sie wirklich brauchen. Eine innere Adresse ist nicht der öffentliche Ausgang, den eine Website meldet, und die Verwechslung schickt Leute auf die Suche nach einem Leck, das es nicht gibt. Testen Sie die private Ressource über die Adresse, bevor Sie über den Namen testen, damit ein DNS-Fehler nicht für einen Routingfehler gehalten wird.

Schreiben Sie die Phase, die Methode und die Adresse in eine Notiz und datieren Sie sie. Wenn dasselbe Konto in einem Monat erneut scheitert, ist diese Notiz der Unterschied zwischen einer Fünf-Minuten-Prüfung und einer neuen Untersuchung. Fehler in verschiedenen Phasen sind verschiedene Vorfälle, auch wenn der Client nur einen Dialog zeigt.