L2TP/IPsec scheitert: IPsec, Tunnel-Authentifizierung oder PPP-Anmeldung trennen

In einer einzigen L2TP/IPsec-Verbindung authentifizieren sich drei Dinge, und nur eines davon betrifft die Person, die sich einwählt. IPsec weist die Tunnelendpunkte aus, die L2TP-Kontrollverbindung kann die Gegenstellen mit ihrem eigenen Geheimnis erneut ausweisen, und danach weist PPP das Benutzerkonto innerhalb der Sitzung aus. Ein Fehler auf jeder Stufe sieht im Client-Dialog wie ein allgemeiner Anmeldefehler aus und im Serverlog völlig anders. Arbeiten Sie die Stufen der Reihe nach ab und halten Sie bei der ersten an, die scheitert, denn jede Stufe unter einer ungeprüften ist ebenfalls ungeprüft.

Drei Authentifizierungsstufen, drei verschiedene Identitäten

IPsec weist nach, wem die Endpunkte gehören, mit einem vorab geteilten Schlüssel oder einem Zertifikat. Diese Identität gehört Maschinen oder Gateways, niemals dem Menschen an der Tastatur. Wenn sich die Gegenstellen auf dieser Stufe nicht einigen können, wird überhaupt kein L2TP-Paket ausgetauscht.

Die L2TP-Kontrollverbindung kann einen zweiten, getrennten Challenge-Response-Austausch hinzufügen, der von einem gemeinsamen Geheimnis angetrieben wird, das beide Enden besitzen müssen.

RFC 2661 macht diese Authentifizierung der Kontrollverbindung optional, was erklärt, warum derselbe Fehler auf zwei Servern verschiedene Symptome erzeugt. Eine Bereitstellung, die nie ein Tunnelgeheimnis eingerichtet hat, überspringt die Stufe ganz; eine, die es nur auf einer Seite eingerichtet hat, scheitert, bevor PPP überhaupt angeboten wird. Danach authentifiziert PPP den Benutzer mit PAP, CHAP oder MSCHAPv2 und übergibt den Namen an einen Kontospeicher, der lokal, in chap-secrets oder auf RADIUS liegen kann. Ein falsches Passwort an dieser Stelle hinterlässt trotzdem einen funktionierenden Tunnel und eine gescheiterte Sitzung.

Lesen Sie den Haltepunkt, bevor Sie eine Konfiguration ändern

Beginnen Sie mit ipsec --version, damit Sie wissen, ob die Statusausgabe zu strongSwan oder zu Libreswan gehört. Lesen Sie dann das Serverlog, nicht den Client-Dialog, denn der Server protokolliert, welche Stufe abgelehnt hat.

Eine Zeile entscheidet meist das Ticket: eine Beschwerde über IKE oder über die Vorschläge ist Stufe eins, eine Meldung der Kontrollverbindung ist Stufe zwei, und eine Ablehnung der PPP-Methode oder des Kontos ist Stufe drei. Kopieren Sie diese Zeile mit dem Zeitstempel ins Ticket. Raten von der Clientseite aus verschwendet das einzige Beweisstück, das Sie bereits haben.

Halten Sie Schlüsselmaterial und Passwörter aus dieser Einfügung heraus; der Stufenname lenkt die Arbeit, und ein durchgesickerter vorab geteilter Schlüssel öffnet das Ticket mit schlimmeren Folgen erneut.

Schritt eins: hat IPsec eine Assoziation?

Führen Sie ipsec statusall auf strongSwan oder ipsec whack --status auf Libreswan aus und suchen Sie eine aufgebaute Child-Assoziation mit Zählern ungleich null. ip xfrm state zeigt die Sicht des Kernels auf beiden. Ein installiertes SA-Paar mit steigenden Zählern bedeutet, dass Stufe eins erledigt ist und Sie weitermachen können.

Gar keine Assoziation deutet auf die Adresse der Gegenstelle, den Vorschlagssatz oder den vorab geteilten Schlüssel hin und gelegentlich auf ein Gerät, das UDP 500 umschreibt und dabei UDP 4500 verwirft. Eine Assoziation, die aufgebaut wird und nach wenigen Sekunden wieder verschwindet, ist meist eine Lebensdauer-Abweichung zwischen den beiden Enden und kein Berechtigungsproblem. Prüfen Sie, ob beide Seiten dieselben Verschlüsselungs- und Hash-Vorschläge auflisten, bevor Sie irgendetwas neu eintippen. Wenn nicht, wird kein Schlüssel jemals funktionieren.

Halten Sie an, solange die Assoziation fehlt. PPP-Optionen an dieser Stelle zu ändern, bewirkt nichts und verbirgt den echten Fehler vor der nächsten Person.

Schritt zwei: hat sich die L2TP-Kontrollverbindung authentifiziert?

Sobald IPsec läuft, beobachten Sie den L2TP-Daemon, ob eine Kontrollverbindung einen aufgebauten Zustand erreicht, denn PPP kann vorher nicht beginnen. Eine Ablehnung auf der Kontrollverbindung bedeutet, dass sich das Tunnelgeheimnis zwischen den Enden unterscheidet oder dass ein Ende ein Geheimnis verlangt, das das andere nie sendet. Clients bieten oft ein einziges Feld mit der Bezeichnung gemeinsames Geheimnis an, und es gehört normalerweise zu IPsec und nicht zu L2TP. Es auszufüllen konfiguriert das Tunnelgeheimnis nicht, und es zu leeren deaktiviert es nicht.

Wenn auf keiner Seite ein Tunnelgeheimnis konfiguriert ist, überspringen Sie diese Stufe und behandeln Sie einen Fehler der Kontrollverbindung stattdessen als Erreichbarkeitsproblem. Bestätigen Sie, dass UDP 1701 den Daemon erreicht und dass beide Enden sich auf dieselbe Kapselung einigen. Eine Firewallregel, die für eine dieser beiden Bedingungen geschrieben wurde, ist eine häufige Ursache für eine Verbindung, die nur halb aufgeht.

Nur eine Sitzung, die beginnt, PPP auszuhandeln, hat die Tunnelstufe tatsächlich passiert.

Schritt drei: lehnt PPP das Konto ab?

Ein PPP-Fehler sieht von außen anders aus: Der Tunnel ist aufgebaut, die Sitzung beginnt, und der Daemon protokolliert einen Fehler der Authentifizierungsmethode oder eine Ablehnung des Kontos. Lesen Sie die in dieser Meldung genannte Methode. PAP und CHAP scheitern aus unterschiedlichen Gründen, und ein Server, der die eine ablehnt, wird einen Client zurückweisen, der nur diese anbietet.

Sehen Sie auf einem Linux-Server die Optionsdatei durch, die der Daemon an PPP übergibt, typischerweise /etc/ppp/options.xl2tpd, und bestätigen Sie, welche Methoden akzeptiert werden und wo Konten aufgelöst werden. Ein Name, der in RADIUS existiert, aber nicht in der lokalen Geheimnisdatei, scheitert sauber und sieht wie ein schlechtes Passwort aus. Prüfen Sie dann, ob der Client eine Methode anbietet, die der Server akzeptiert, und nicht eine stärkere, über die der Server nicht verhandeln will. Den vorab geteilten Schlüssel zu ändern, um diese Stufe zu reparieren, kostet einen Nachmittag und ändert nichts.

Wenn die Sitzung endlich hochkommt, sind Adressvergabe, DNS und Routen noch ungeprüft, und jedes davon scheitert still auf seine eigene Weise. Halten Sie die drei Schichten in Ihren Notizen getrennt: ein richtiger Schlüssel mit einem falschen Konto scheitert immer, und eine Schicht zu reparieren repariert nie eine andere.