L2TP ohne IPsec unter Linux: xl2tpd, pppd und NAT

Reines L2TP ist PPP in einem Umschlag, und sonst nichts. Es trägt Ihre Frames; es verschlüsselt sie nicht und es weist nicht nach, wer am anderen Ende sitzt, weshalb fast jede Bereitstellung IPsec darunter schiebt. Ehrliche Gründe für die nackte Variante gibt es weiterhin: ein Laborplatz, ein Migrationsschritt oder eine Strecke, die ohnehin schon in einem anderen geschützten Pfad liegt.

Wenn Sie es dennoch tun, schreiben Sie diesen Vorbehalt in die Designnotiz und lassen Sie ihn dort. Was folgt, ist der Betriebsweg, den ich auf Hosts aus der Debian- und der RHEL-Familie nutze: welche Datei wofür zuständig ist, die MTU, die den klassischen Hänger verhindert, und die Weiterleitungsregeln, die den Tunnel sinnvoll machen.

Drei Dateien teilen die Arbeit

xl2tpd beendet die Steuerverbindung und übergibt jede Sitzung an einen PPP-Daemon, daher verteilt sich die Konfiguration auf zwei Programme, die niemals die Dateien des jeweils anderen lesen. Der Listener liegt in /etc/xl2tpd/xl2tpd.conf, innerhalb eines Abschnitts [lns default], der den Adresspool mit ip range, das Serverende mit local ip und die Übergabe an PPP mit pppoptfile benennt. Schalten Sie require authentication = yes ein, lassen Sie length bit und flow bit aktiviert und wählen Sie einen Pool, den sonst nichts auf dem Host bereits nutzt.

Die PPP-Richtlinie gehört in die Datei, die diese Option nennt, normalerweise /etc/ppp/options.xl2tpd: auth, Ablehnungen für pap, chap und mschap, require-mschap-v2, eine MTU und MRU von 1460 sowie eine DNS-Adresse, die der Client nach dem Verbindungsaufbau erreichen kann. Die Zugangsdaten stehen wieder in einer dritten Datei, /etc/ppp/chap-secrets, wo das zweite Feld zum Namen des LNS-Abschnitts passen muss und das vierte Feld eine bestimmte Adresse aus dem Pool festlegen kann.

Warum der Tunnel sich verbindet und dann hängt

Ein 1500-Byte-Ethernet-Frame passt nicht in einen Pfad, der bereits Bytes für seine eigenen Header verbraucht. Der äußere IPv4-Header kostet 20, UDP kostet 8 und der L2TP-Header etwa 12, was 1460 für PPP und seine Nutzlast lässt. Genau diese kleinere Zahl in PPP anzukündigen verhindert, dass große Pakete fragmentiert oder irgendwo in der Mitte stillschweigend verworfen werden.

Das Symptom ist ein Tunnel, der gesund aussieht, bis echter Verkehr ankommt: Pings und Steuernachrichten gehen durch, eine Dateikopie hängt, nichts im Protokoll erklärt es. Senken Sie MTU und MRU gemeinsam auf beiden Seiten. Nur den Client anzupassen verwandelt einen harten Hänger meist in einen zeitweiligen, der sich schlechter diagnostizieren lässt.

Ein Port trägt zwei Gespräche

UDP 1701 liegt unter beiden Hälften des Protokolls, und diese eine Tatsache bricht mehr Firewallregeln als jeder andere Teil des Aufbaus. Zuerst kommen eine Start-Control-Connection-Anfrage und ihre Antwort; die danach folgende Sitzungsanfrage und ihre Bestätigung etablieren nichts weiter als das Kennungspaar. Danach übernimmt PPP, mit Verbindungssteuerung, dann Authentifizierung, dann IP-Control-Protocol zur Adressaushandlung. Jede Stufe hat ihr eigenes Vokabular im Protokoll, und keine von ihnen meldet sich als L2TP-Fehler.

Ein Mitschnitt in genau dieser Reihenfolge zu lesen sagt Ihnen, welche Stufe gescheitert ist, und ein PPP-Authentifizierungsfehler lässt sich nicht durch Bearbeiten von xl2tpd reparieren. Der gemeinsame Port erklärt einen weiteren häufigen Fehler: Eine Regel, die nur die ersten Pakete eines Flusses erlaubt, lässt die Sitzung entstehen und blockiert dann die Übertragung. Erlauben Sie 1701 für das gesamte Gespräch, in beide Richtungen.

Den Tunnel nützlich machen: Weiterleitung und NAT

Eine Sitzung allein erreicht nur den Server. Für den Internetzugang der Clients braucht es Weiterleitung, eine NAT-Regel für den Pool auf dem Uplink und DNS, das der Client nach dem Verbindungsaufbau tatsächlich abfragen kann. Der Pool muss außerdem vom LAN-Bereich entfernt bleiben, sonst werden Antworten an die Clients lokal zugestellt, statt zurück in den Tunnel geschoben zu werden.

Aktivieren Sie auf dem Server die Weiterleitung mit sysctl -w net.ipv4.ip_forward=1, übersetzen Sie den Pool mit iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE und akzeptieren Sie dann ausgehenden Tunnelverkehr mit einer FORWARD-Regel für -i ppp0 -o eth0 sowie Rückverkehr mit der Spiegelregel plus -m state --state RELATED,ESTABLISHED. Machen Sie diese Regeln über Neustarts hinweg dauerhaft, denn ein Server, der ohne sie zurückkommt, sieht genau wie eine kaputte L2TP-Konfiguration aus.

Das eigene LAN des Servers zu erreichen ist eine andere Aufgabe: Fügen Sie eine Rückroute für den Pool auf dem LAN-Router hinzu oder Proxy-ARP auf dem Server. Clients hinter NAT zu verstecken, wenn etwas im LAN sie direkt adressieren muss, plant nur eine zweite Debugging-Sitzung für später ein.

Was der nackte Stapel nicht tut und wie man prüft

Kein Teil dieses Stapels verschlüsselt die PPP-Frames, und nichts darin authentifiziert die Gegenseite als den Server, den Sie tatsächlich gewählt haben. MS-CHAPv2 schützt den Austausch der Zugangsdaten zwar vor einem Zuhörer, der nur mithört, doch ein Angreifer im Pfad kann die Sitzung dennoch stören. Der native Windows-Client bietet L2TP nur in Kombination mit IPsec an, planen Sie also Linux, Router-Firmware und Drittanbieter-Clients als Ihre Gegenstellen ein. Behandeln Sie die nackte Konfiguration als diagnostische Zwischenstufe, niemals als Ort zum Anhalten.

Prüfen Sie in fester Reihenfolge: Starten Sie xl2tpd -D im Vordergrund, beobachten Sie das Journal für die PPP-Stufe, lesen Sie die zugewiesene Adresse aus ip addr an beiden Enden und zeichnen Sie dann UDP 1701 auf, um zu bestätigen, dass Daten fließen, nachdem die Sitzung steht. Wenn alle vier zusammenpassen und der Verkehr trotzdem scheitert, liegt der Fehler in Routing, NAT oder MTU und nicht in L2TP selbst.