L2TP-Zeitüberschreitung unter Ubuntu 22.04: der xl2tpd-Tunnelfehler

Der Desktop zeigt eine laufende Verbindung, IPsec meldet Erfolg, und die PPP-Schnittstelle erscheint nie. Im Syslog wiederholt sich dieselbe Tunnelnummer, bis der Versuch bei UDP 1701 in eine Zeitüberschreitung läuft. Bevor Sie den vorab geteilten Schlüssel oder die Serverkonfiguration bearbeiten, erkennen Sie diese Form: Unter Ubuntu 22.04 ist es meist eine Paketregression in xl2tpd, und der Server war die ganze Zeit korrekt.

Was das wiederkehrende Syslog-Paar Ihnen sagt

Eine fehlschlagende Sitzung druckt in regelmäßigen Abständen ein Paar Zeilen: Der Daemon findet keinen Tunnel für eine eingehende Kontrollnachricht und gibt danach die Call- und Tunnel-IDs aus, die er erhalten hat. Später erreicht der Wiederholungszähler seine Grenze, und die Verbindung wird mit einer Zeitüberschreitung an Port 1701 geschlossen. Adressen und IDs sind nebensächlich; die Form zählt. IKE wurde abgeschlossen, L2TP-Kontrollverkehr kam an, und der Daemon konnte ihn keinem Tunnel zuordnen, den er bereits erstellt hatte.

Der Fehler liegt also zwischen L2TP-Kontrolle und PPP. Vom Geheimnis, den PPP-Optionen oder dem entfernten Subnetz wurde noch nichts geprüft.

Bestätigen Sie, dass IPsec wirklich erfolgreich war

Zwei Prüfungen trennen dies von einem Anmeldedatenproblem, und beide gehören vor jede Paketänderung.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

Die Statusausgabe listet die Verbindung und ihren Zustand, und ein aufgebauter Tunnel bedeutet, dass Phase eins und Phase zwei abgeschlossen sind. Eine Logzeile über einen fehlenden geteilten Schlüssel weist nur auf das Geheimnis hin, also halten Sie an und beheben Sie das zuerst. Wenn IPsec aufgebaut ist und die L2TP-Zeitüberschreitung weiterhin erscheint, bleibt der Daemon der Verdächtige. Behalten Sie die genauen Zeilen eines Versuchs statt eines ganzen Tages voller Wiederholungen.

Prüfen Sie den xl2tpd-Build, nicht den Releasenamen

Ubuntus Jammy-Build von xl2tpd 1.3.16 aktivierte Link-Time-Optimierung, was das Parsen der Tunnel-ID in der SCCRP-Antwort des Servers brach. Der Daemon verwirft dann Kontrollpakete für einen Tunnel, den er selbst erstellt hat. Die Versionszeichenfolge zählt mehr als der Distributionsname.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Das korrigierte Paket ist 1.3.16-1ubuntu0.1, ein Build ohne diesen Zusatz ist also älter als die Korrektur. Die Policy-Ausgabe zeigt, welchen Kandidaten ein Upgrade installieren würde, und die Hold-Liste erklärt, warum eine Korrektur nicht angekommen ist. Wo das Paket verfügbar ist, aktualisieren Sie es und verbinden Sie sich über das normale Profil neu, statt Dateien von Hand zu bearbeiten. Bauen Sie keine Module neu und ändern Sie das Geheimnis nicht, solange der alte Build noch installiert ist.

Prüfen Sie PPP nach der Änderung

Ein erfolgreiches Upgrade zeigt sich auf der Schicht, die defekt war. Prüfen Sie, ob PPP hochkam, und nicht nur, ob sich das Symbol geändert hat.

ip -4 addr show ppp0
ip route | grep ppp

Die Schnittstellenliste sollte eine lokale und eine Peer-Adresse zeigen, und die Routentabelle sollte die Präfixe des Tunnels führen. Das Syslog sollte den angenommenen Tunnel und pppd mit beiden Adressen zeigen, ohne wiederholte Zeilen über einen nicht gefundenen Tunnel. Wenn PPP läuft und der Verkehr weiterhin scheitert, schauen Sie als Nächstes auf Routing oder MTU, denn die L2TP-Stufe hat ihre Aufgabe erledigt. Notieren Sie die funktionierende Paketversion in den Maschinennotizen, damit eine künftige Neuinstallation nicht den defekten Build wiederherstellt.

Wo das korrigierte Paket nicht verfügbar ist, sind die dokumentierten Alternativen ein lokaler Quellbau von 1.3.16 oder 1.3.17, ein Wechsel zu kl2tpd oder ein festgeschriebenes Downgrade. Jede bringt Wartungskosten mit sich, die es wert sind, notiert zu werden.