L2TP op Ubuntu 24.04 kapot: xl2tpd of go-l2tp-daemon?

Ubuntu 24.04 heeft stilletjes de daemon achter de L2TP-plugin van NetworkManager vervangen. Het oudere pad gebruikte xl2tpd; de nieuwere pakkettering haalt een Go-implementatie binnen die een daemon met de naam kl2tpd maakt. De plugin start wat er geïnstalleerd is, dus de upgrade kan de daemon vervangen zonder je profiel of inloggegevens aan te raken. Dat is de hele storing: een besturingsbericht dat de nieuwe daemon niet herkent.

De plugin coördineert IPsec, L2TP en PPP en geeft de resulterende interface daarna aan NetworkManager. Hij implementeert L2TP niet zelf.

De plugin is een coördinator, geen daemon

network-manager-l2tp start de IPsec-hulp, een L2TP-daemon en PPP en koppelt de interface aan het verbindingsbeheer van de desktop. Jarenlang was de daemon xl2tpd, en elke handleiding die de configuratie noemde, erfde die aanname. De Debian-pakkettering accepteerde later beide implementaties, en 24.04 installeert de Go-versie, die kl2tpd levert. Geen enkel veld in het profiel legt vast welke daemon eerder liep, dus de verwisseling blijft onzichtbaar tot een bericht wordt geweigerd.

Een machine met beide pakketten draait misschien nog steeds niet degene die je verwacht. De keuze is een beslissing van de plugin, niet van de handleiding die je volgde.

Lees de fase voordat je een reparatie kiest

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

Correleer één poging over de hulpprogramma's in plaats van de bureaubladmelding te vertrouwen. Die query laat zien waar de reeks stopte, en dpkg -l laat zien welke implementatie is geïnstalleerd. Een fout die verschijnt nadat de IPsec-peer is opgezet en die een besturingsbericht of een onbekend attribuut noemt, wijst naar de daemon. Een fout voordat de tunnel bestaat betekent dat de daemon nooit is bereikt.

Een verschil in de vooraf gedeelde sleutel eindigt bij de IPsec-fase en noemt de peer. Een PPP-inlogprobleem verschijnt zodra de tunnel staat en draagt meestal een leesbare CHAP- of MS-CHAP-afwijzing. Beide zijn in dezelfde query zichtbaar, en het zijn verschillende problemen.

Twee routes, en ze mengen niet

sudo apt install xl2tpd
sudo apt purge go-l2tp

Dat paar zet xl2tpd neer en verwijdert daarna de Go-daemon, zodat de plugin de implementatie kiest waarvan de gateway het dialect spreekt. De volgorde is belangrijk: de plugin hangt van de ene of de andere implementatie af, dus eerst het Go-pakket verwijderen haalt de plugin mee onderuit. De tweede route houdt de Go-daemon en stapt over op een nieuwere build die het bericht begrijpt, wat meestal een PPA van een beheerder betekent in plaats van de archiefversie. In een beheerde vloot is een PPA vastpinnen makkelijker te verantwoorden dan gebruikers leren pakketten te verwijderen.

Combineer de twee niet in één wijziging. Een latere fout laat je dan niet zeggen welk deel hielp, en een toekomstige upgrade kan het pakket terugzetten dat je net verwijderde.

Zet de binary van de daemon, de versie en het exacte bericht in de ticket. Niemand kan een rapport reproduceren dat alleen zegt dat L2TP na de release kapot was, terwijl een genoemd attribuut plus een pakketversie hen een beginpunt geeft.

Drie dingen die het niet is

Het is geen profielprobleem, want hetzelfde profiel werkte op 22.04 met dezelfde gateway. Het is geen ontbrekende route of firewallwijziging, want die falen elders met ander bewijs. De plugin opnieuw installeren repareert het ook niet, omdat dezelfde daemon weer wordt gekozen. De bruikbare beschrijving noemt de daemon en het bericht dat hij weigerde.

Een oplossing aan de gateway-kant is de andere legitieme uitkomst. Firmware die het attribuut niet meer stuurt, overleeft elke clientupgrade, terwijl een vastgepind pakket de volgende distributierelease alleen overleeft als iemand zich herinnert waarom het vastgepind is.

Vergelijk de twee routes op onderhoudskosten in plaats van snelheid. Beide kunnen werken; alleen één haalt de dialectafwijking weg.