L2TP-timeout på Ubuntu 22.04: xl2tpd-tunnelfelet

Skrivbordet visar en anslutning som pågår, IPsec rapporterar framgång och PPP-gränssnittet dyker aldrig upp. I syslog upprepas samma tunnelnummer tills försöket får timeout på UDP 1701. Innan du redigerar den fördelade nyckeln eller serverkonfigurationen, känn igen det här mönstret: på Ubuntu 22.04 är det oftast en paketregression i xl2tpd, och servern var korrekt hela tiden.

Vad det upprepade syslog-paret berättar för dig

En session som misslyckas skriver ut ett par rader med jämna mellanrum: daemonen hittar ingen tunnel för ett inkommande kontrollmeddelande och dumpar sedan de anrops- och tunnel-ID:n den fick. Senare når återförsöksräknaren sin gräns och anslutningen stängs med en timeout på port 1701. Adresser och ID:n är slumpmässiga; formen är det som spelar roll. IKE slutfördes, L2TP-kontrolltrafik anlände, och daemonen kunde inte koppla den till en tunnel som den redan hade skapat.

Felet ligger alltså mellan L2TP-kontroll och PPP. Inget om hemligheten, PPP-alternativen eller det externa subnätet har prövats ännu.

Bekräfta att IPsec verkligen lyckades

Två kontroller skiljer detta från ett inloggningsproblem, och båda hör hemma före varje paketändring.

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

Statusutmatningen listar anslutningen och dess tillstånd, och en etablerad tunnel innebär att fas ett och fas två slutfördes. En logg rad om en saknad delad nyckel pekar bara på hemligheten, så stanna och åtgärda det först. När IPsec är etablerat och L2TP-timeouten fortfarande visas är daemonen den kvarvarande misstänkta. Spara de exakta raderna från ett försök i stället för en hel dag av återförsök.

Kontrollera xl2tpd-bygget, inte utgivningsnamnet

Ubuntus jammy-bygge av xl2tpd 1.3.16 aktiverade länktidsoptimering, vilket bröt tolkningen av tunnel-ID:t i serverns SCCRP-svar. Daemonen kastar då kontrollpaket för en tunnel som den själv skapade. Versionssträngen betyder mer än distributionsnamnet.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Det korrigerade paketet är 1.3.16-1ubuntu0.1, så ett bygge utan det suffixet är äldre än korrigeringen. Policyutmatningen visar vilken kandidat en uppgradering skulle installera, och hold-listan förklarar varför en korrigering inte har kommit. Där paketet är tillgängligt, uppgradera det och återanslut via den vanliga profilen i stället för att redigera filer för hand. Bygg inte om moduler och ändra inte hemligheten medan det gamla bygget fortfarande är installerat.

Verifiera PPP efter ändringen

En lyckad uppgradering bevisas på det lager som var trasigt. Kontrollera att PPP kom upp, inte bara att ikonen ändrades.

ip -4 addr show ppp0
ip route | grep ppp

Gränssnittslistan bör visa en lokal adress och en peer-adress, och routingtabellen bör bära tunnelns prefix. Syslog bör visa att tunneln accepterades och att pppd rapporterar båda adresserna, utan upprepade rader om tunnel som inte hittas. Om PPP är uppe och trafiken fortfarande misslyckas, titta sedan på routing eller MTU, eftersom L2TP-steget har gjort sitt jobb. Anteckna den fungerande paketversionen i maskinens anteckningar, så att en framtida ominstallation inte återställer det trasiga bygget.

Där det korrigerade paketet inte är tillgängligt är de dokumenterade alternativen ett lokalt källbygge av 1.3.16 eller 1.3.17, ett byte till kl2tpd eller en fäst nedgradering. Vart och ett medför en underhållskostnad som är värd att skriva ner.