L2TP på Ubuntu 24.04 är trasigt: xl2tpd eller go-l2tp-demon?

Ubuntu 24.04 bytte tyst ut demonen bakom NetworkManagers L2TP-insticksmodul. Den äldre vägen använde xl2tpd; den nyare paketeringen drar in en Go-implementering som skapar en demon med namnet kl2tpd. Insticksmodulen startar den som är installerad, så uppgraderingen kan byta ut demonen utan att röra profilen eller inloggningsuppgifterna. Det är hela felet: ett kontrollmeddelande som den nya demonen inte känner igen.

Insticksmodulen samordnar IPsec, L2TP och PPP och lämnar sedan över gränssnittet till NetworkManager. Den implementerar inte L2TP själv.

Insticksmodulen är en samordnare, inte en demon

network-manager-l2tp kör IPsec-hjälparen, en L2TP-demon och PPP och kopplar gränssnittet till skrivbordets anslutningshantering. I åratal var demonen xl2tpd, och varje guide som nämnde dess konfiguration ärvde det antagandet. Debian-paketeringen accepterade senare vilken som helst av de två implementationerna, och 24.04 installerar Go-versionen, som tillhandahåller kl2tpd. Inget fält i profilen registrerar vilken demon som kördes tidigare, så bytet förblir osynligt tills ett meddelande avvisas.

En maskin med båda paketen kör kanske fortfarande inte den du förväntar dig. Valet är insticksmodulens beslut, inte guiden du följde.

Läs steget innan du väljer en reparation

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd _COMM=charon _COMM=pluto

Korrelera ett försök över hjälparna i stället för att lita på skrivbordsaviseringen. Den frågan visar var sekvensen stannade, och dpkg -l visar vilken implementation som är installerad. Ett fel som dyker upp efter att IPsec-peer-en upprättats, och som nämner ett kontrollmeddelande eller ett okänt attribut, pekar på demonen. Ett fel innan tunneln finns betyder att demonen aldrig nåddes.

Ett avvikande fördelat nyckelvärde slutar i IPsec-steget och namnger peer-en. PPP-inloggningsproblem visar sig när tunneln är uppe och bär vanligtvis en läsbar CHAP- eller MS-CHAP-avvisning. Båda syns i samma fråga, och det är olika problem.

Två vägar, och de blandas inte

sudo apt install xl2tpd
sudo apt purge go-l2tp

Det paret sätter xl2tpd på plats och tar sedan bort Go-demonen, så insticksmodulen väljer den implementation vars dialekt gatewayen talar. Ordningen spelar roll: insticksmodulen är beroende av den ena eller den andra implementationen, så tas Go-paketet bort först drar det med sig insticksmodulen. Den andra vägen behåller Go-demonen och går över till ett nyare bygge som förstår meddelandet, vilket oftast betyder en maintainer-PPA i stället för arkivversionen. I en hanterad flotta är det lättare att motivera att en PPA pinnas än att lära användarna att ta bort paket.

Kombinera inte de två i en enda ändring. Ett senare fel låter dig då inte säga vilken halva som hjälpte, och en framtida uppgradering kan återställa paketet du just tog bort.

Sätt demonens binärfil, versionen och det exakta meddelandet i ärendet. Ingen kan återskapa en rapport som bara säger att L2TP gick sönder efter släppet, medan ett namngivet attribut plus en paketversion ger dem en utgångspunkt.

Tre saker det inte är

Det är inte ett profilproblem, eftersom samma profil fungerade på 22.04 mot samma gateway. Det är inte en saknad rutt eller en brandväggsändring, eftersom de misslyckas någon annanstans med andra bevis. Att installera om insticksmodulen reparerar det inte heller, eftersom samma demon väljs igen. Den användbara beskrivningen namnger demonen och meddelandet den avvisade.

En rättelse på gateway-sidan är det andra legitima utfallet. Firmware som slutar skicka attributet överlever varje klientuppgradering, medan ett pinnat paket bara överlever nästa distributionssläpp om någon minns varför det är pinnat.

Jämför de två vägarna på underhållskostnad i stället för hastighet. Båda kan fungera; bara en tar bort dialektavvikelsen.