L2TP-time-out op Ubuntu 22.04: de xl2tpd-tunnelfout

De desktop toont een verbinding die bezig is, IPsec meldt succes en de PPP-interface verschijnt nooit. In syslog herhaalt hetzelfde tunnelnummer zich tot de poging een time-out krijgt op UDP 1701. Voordat u de vooraf gedeelde sleutel of de serverconfiguratie bewerkt, herken deze vorm: op Ubuntu 22.04 is het meestal een pakketregressie in xl2tpd, en de server was al die tijd correct.

Wat het herhalende syslog-paar u vertelt

Een mislukkende sessie drukt met regelmatige tussenpozen een paar regels af: de daemon vindt geen tunnel voor een inkomend controlebenicht en dumpt daarna de call- en tunnel-ID's die hij kreeg. Later bereikt de herhaalteller zijn grens en wordt de verbinding gesloten met een time-out op poort 1701. Adressen en ID's zijn toevallig; de vorm is wat telt. IKE voltooide, L2TP-controleverkeer kwam aan, en de daemon kon het niet koppelen aan een tunnel die hij al had gemaakt.

De fout zit dus tussen L2TP-controle en PPP. Over het geheim, de PPP-opties of het externe subnet is nog niets getest.

Bevestig dat IPsec echt is gelukt

Twee controles scheiden dit van een inloggegevensprobleem, en beide horen vóór elke pakketwijziging.

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

De statusuitvoer noemt de verbinding en de staat ervan, en een opgezette tunnel betekent dat fase één en fase twee zijn voltooid. Een logregel over een ontbrekende gedeelde sleutel wijst alleen op het geheim, dus stop en herstel dat eerst. Wanneer IPsec is opgezet en de L2TP-time-out nog steeds verschijnt, blijft de daemon de verdachte. Bewaar de exacte regels van één poging in plaats van een hele dag herhalingen.

Controleer de xl2tpd-build, niet de releasenaam

Ubuntu's jammy-build van xl2tpd 1.3.16 schakelde link-time-optimalisatie in, wat het parsen van de tunnel-ID in het SCCRP-antwoord van de server brak. De daemon gooit dan controlepakketten weg voor een tunnel die hij zelf heeft gemaakt. De versiestring telt meer dan de distributienaam.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Het gecorrigeerde pakket is 1.3.16-1ubuntu0.1, dus een build zonder dat achtervoegsel is ouder dan de correctie. De beleidsuitvoer toont welke kandidaat een upgrade zou installeren, en de hold-lijst verklaart waarom een correctie niet is aangekomen. Waar het pakket beschikbaar is, voert u de upgrade uit en verbindt u opnieuw via het normale profiel in plaats van bestanden met de hand te bewerken. Bouw geen modules opnieuw en wijzig het geheim niet zolang de oude build nog is geïnstalleerd.

Controleer PPP na de wijziging

Een geslaagde upgrade wordt bewezen op de laag die kapot was. Controleer of PPP omhoogkwam, niet alleen of het pictogram veranderde.

ip -4 addr show ppp0
ip route | grep ppp

De interfacelijst hoort een lokaal adres en een peeradres te tonen, en de routetabel hoort de prefixen van de tunnel te dragen. Syslog hoort te tonen dat de tunnel is geaccepteerd en dat pppd beide adressen meldt, zonder herhaalde regels over tunnel niet gevonden. Als PPP actief is en verkeer nog steeds faalt, kijk dan vervolgens naar routing of MTU, want de L2TP-fase heeft zijn werk gedaan. Noteer de werkende pakketversie in de machinenotities, zodat een toekomstige herinstallatie de kapotte build niet terugzet.

Waar het gecorrigeerde pakket niet beschikbaar is, zijn de gedocumenteerde alternatieven een lokale bronbuild van 1.3.16 of 1.3.17, een overstap naar kl2tpd of een vastgezette downgrade. Elk brengt onderhoudskosten met zich mee die het waard zijn om op te schrijven.