Ubuntu 24.04 se L2TP is stukkend: xl2tpd of go-l2tp-daemon?

Ubuntu 24.04 het stilweg die daemon agter NetworkManager se L2TP-inprop vervang. Die ouer pad het xl2tpd gebruik; die nuwer pakket trek ’n Go-implementering in wat ’n daemon met die naam kl2tpd lewer. Die inprop begin enigeen wat geïnstalleer is, so die opgradering kan die daemon vervang sonder om aan jou profiel of geloofsbriewe te raak. Dit is die hele fout: ’n beheerboodskap wat die nuwe daemon nie herken nie.

Die inprop koördineer IPsec, L2TP en PPP en gee dan die resulterende koppelvlak aan NetworkManager. Dit implementeer nie self L2TP nie.

Die inprop is ’n koördineerder, nie ’n daemon nie

network-manager-l2tp hardloop die IPsec-hulpprogram, ’n L2TP-daemon en PPP, en bedraad die koppelvlak in die lessenaar se verbindingsbestuur in. Vir jare was die daemon xl2tpd, en elke handleiding wat sy konfigurasie noem, het daardie aanname geërf. Debian se pakkettering het later enige van die twee implementerings aanvaar, en 24.04 installeer die Go-een, wat kl2tpd verskaf. Geen veld in die profiel teken aan watter daemon voorheen geloop het nie, so die vervanging bly onsigbaar tot ’n boodskap geweier word.

’n Masjien met albei pakkette teenwoordig loop dalk steeds nie die een wat jy verwag nie. Die keuse is die inprop se besluit eerder as die gids wat jy gevolg het.

Lees die fase voordat jy ’n herstel kies

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

Korreleer ’n enkele poging oor die hulpprogramme eerder as om die lessenaar se kennisgewing te vertrou. Daardie navraag wys waar die reeks gestop het, en dpkg -l wys watter implementering geïnstalleer is. ’n Fout wat verskyn nadat die IPsec-eweknie gevestig is, en wat ’n beheerboodskap of ’n onbekende eienskap noem, wys na die daemon. ’n Fout voordat die tonnel bestaan, beteken die daemon is nooit bereik nie.

’n Verskil in die vooraf-gedeelde sleutel eindig by die IPsec-fase en noem die eweknie. PPP-geloofsbriewe se probleme verskyn sodra die tonnel op is en dra gewoonlik ’n leesbare CHAP- of MS-CHAP-weiering. Albei is in dieselfde navraag sigbaar, en dit is verskillende probleme.

Twee roetes, en hulle meng nie

sudo apt install xl2tpd
sudo apt purge go-l2tp

Daardie paar plaas xl2tpd en verwyder dan die Go-daemon, wat die inprop laat kies watter implementering se dialek die poort verstaan. Orde maak saak: die inprop hang van die een of die ander implementering af, so om die Go-pakket eerste te verwyder neem die inprop saam. Die tweede roete hou die Go-daemon en skuif na ’n nuwer bou wat die boodskap verstaan, wat gewoonlik ’n instandhouer se PPA beteken eerder as die argiefweergawe. Oor ’n bestuurde vloot is dit makliker om ’n PPA vas te pen as om gebruikers te leer om pakkette te verwyder.

Moenie die twee in een verandering kombineer nie. ’n Latere fout laat jou dan nie sê watter helfte gehelp het nie, en ’n toekomstige opgradering kan die pakket wat jy pas verwyder het, terugbring.

Sit die daemon-lêer, sy weergawe en die presiese boodskap in die kaartjie. Niemand kan ’n verslag reprodujeer wat net sê dat L2TP ná die vrystelling gebreek het nie, terwyl ’n genoemde eienskap plus ’n pakketweergawe vir hulle ’n beginpunt gee.

Drie dinge wat dit nie is nie

Dit is nie ’n profielprobleem nie, want dieselfde profiel het op 22.04 teen dieselfde poort gewerk. Dit is nie ’n ontbrekende roete of ’n firewall-verandering nie, want dié misluk elders met ander bewyse. Om die inprop te herinstalleer herstel dit ook nie, want dieselfde daemon word weer gekies. Die nuttige beskrywing noem die daemon en die boodskap wat hy verwerp het.

’n Herstel aan die poort se kant is die ander wettige uitkoms. Fermware wat ophou om die eienskap te stuur, oorleef elke kliënt-opgradering, terwyl ’n vasgepen pakket die volgende verspreidingsvrystelling net oorleef as iemand onthou waarom dit vasgepen is.

Vergelyk die twee roetes op instandhoudingskoste eerder as spoed. Albei kan werk; net een verwyder die dialekverskil.