L2TP stricat pe Ubuntu 24.04: xl2tpd sau demonul go-l2tp?

Ubuntu 24.04 a înlocuit în liniște demonul din spatele pluginului L2TP al NetworkManager. Calea mai veche folosea xl2tpd; pachetul mai nou aduce o implementare în Go care creează un demon numit kl2tpd. Pluginul pornește ce este instalat, așa că actualizarea poate înlocui demonul fără să atingă profilul sau acreditările. Aceasta este întreaga defecțiune: un mesaj de control pe care noul demon nu îl recunoaște.

Pluginul coordonează IPsec, L2TP și PPP, apoi predă interfața rezultată către NetworkManager. Nu implementează el însuși L2TP.

Pluginul este un coordonator, nu un demon

network-manager-l2tp rulează ajutorul IPsec, un demon L2TP și PPP și conectează interfața la gestionarea conexiunilor din desktop. Ani de zile demonul a fost xl2tpd, iar fiecare tutorial care menționa configurația lui moștenea această presupunere. Ulterior, împachetarea Debian a acceptat oricare dintre cele două implementări, iar 24.04 instalează varianta Go, care oferă kl2tpd. Niciun câmp din profil nu reține ce demon rula anterior, așa că înlocuirea rămâne invizibilă până când un mesaj este respins.

O mașină cu ambele pachete poate totuși să nu ruleze ce vă așteptați. Alegerea este decizia pluginului, nu a ghidului pe care l-ați urmat.

Citiți etapa înainte de a alege o reparare

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

Corelați o singură încercare între ajutoare în loc să vă bazați pe notificarea desktopului. Acea interogare arată unde s-a oprit secvența, iar dpkg -l arată ce implementare este instalată. O defecțiune care apare după stabilirea partenerului IPsec și care menționează un mesaj de control sau un atribut necunoscut indică demonul. O defecțiune înainte ca tunelul să existe înseamnă că demonul nu a fost niciodată atins.

O nepotrivire a cheii prepartajate se termină la etapa IPsec și numește partenerul. Problema acreditărilor PPP apare după ce tunelul este ridicat și de obicei poartă o respingere CHAP sau MS-CHAP lizibilă. Ambele sunt vizibile în aceeași interogare, și sunt probleme diferite.

Două căi, și ele nu se amestecă

sudo apt install xl2tpd
sudo apt purge go-l2tp

Acea pereche instalează xl2tpd și apoi elimină demonul Go, lăsând pluginul să aleagă implementarea al cărei dialect îl vorbește gateway-ul. Ordinea contează: pluginul depinde de una sau de cealaltă implementare, așa că eliminarea mai întâi a pachetului Go ia pluginul cu ea. A doua cale păstrează demonul Go și trece la o construcție mai nouă care înțelege mesajul, ceea ce înseamnă de obicei un PPA al întreținătorului în locul versiunii din arhivă. Într-o flotă administrată, fixarea unui PPA este mai ușor de justificat decât învățarea utilizatorilor să elimine pachete.

Nu combinați cele două într-o singură modificare. O defecțiune ulterioară vă lasă atunci incapabil să spuneți care jumătate a ajutat, iar o actualizare viitoare poate readuce pachetul pe care tocmai l-ați eliminat.

Puneți în tichet binarul demonului, versiunea lui și mesajul exact. Nimeni nu poate reproduce un raport care spune doar că L2TP s-a stricat după lansare, în timp ce un atribut numit plus o versiune de pachet le oferă un punct de plecare.

Trei lucruri care nu este

Nu este o problemă de profil, deoarece același profil funcționa pe 22.04 cu același gateway. Nu este o rută lipsă și nici o modificare de firewall, pentru că acelea eșuează altundeva cu dovezi diferite. Reinstalarea pluginului nu îl repară nici ea, deoarece același demon este ales din nou. Descrierea utilă numește demonul și mesajul pe care l-a respins.

O corecție pe partea gateway-ului este celălalt rezultat legitim. Firmware-ul care nu mai trimite atributul supraviețuiește fiecărei actualizări a clientului, în timp ce un pachet fixat supraviețuiește următoarei versiuni de distribuție doar dacă cineva își amintește de ce este fixat.

Comparați cele două căi după costul de întreținere, nu după viteză. Ambele pot funcționa; doar una elimină nepotrivirea de dialect.