L2TP в Ubuntu 24.04 е счупен: xl2tpd или демон go-l2tp?

Ubuntu 24.04 тихо смени демона зад добавката L2TP на NetworkManager. Старият път използваше xl2tpd; по-новата пакетна опаковка внася реализация на Go, която създава демон с име kl2tpd. Добавката стартира това, което е инсталирано, така че надграждането може да смени демона, без да пипа профила или идентификационните данни. Това е цялата повреда: контролно съобщение, което новият демон не разпознава.

Добавката координира IPsec, L2TP и PPP, после предава получения интерфейс на NetworkManager. Тя не реализира L2TP сама.

Добавката е координатор, не демон

network-manager-l2tp стартира помощника за IPsec, демон за L2TP и PPP и свързва интерфейса с управлението на връзките на работния плот. С години демонът беше xl2tpd и всяко ръководство, което споменаваше конфигурацията му, наследяваше това допускане. По-късно пакетирането на Debian прие всяка от двете реализации, а 24.04 инсталира Go варианта, който предоставя kl2tpd. Никое поле в профила не записва кой демон е работил преди, затова замяната остава невидима, докато съобщение не бъде отказано.

Машина с двата пакета може все още да не стартира това, което очаквате. Изборът е решение на добавката, а не на ръководството, което сте следвали.

Прочетете етапа, преди да изберете поправяне

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

Свържете един опит през помощниците, вместо да се доверявате на известието на работния плот. Тази заявка показва къде е спряла последователността, а dpkg -l показва коя реализация е инсталирана. Повреда, която се появява след установяване на IPsec партньора и споменава контролно съобщение или неразпознат атрибут, сочи към демона. Повреда преди тунелът да съществува означава, че демонът никога не е бил достигнат.

Несъответствието на предварително споделен ключ завършва на етапа IPsec и посочва партньора. Проблемът с идентификационните данни за PPP се появява, след като тунелът е вдигнат, и обикновено носи четим отказ CHAP или MS-CHAP. И двете се виждат в една и съща заявка и са различни проблеми.

Два пътя и те не се смесват

sudo apt install xl2tpd
sudo apt purge go-l2tp

Тази двойка поставя xl2tpd и после премахва Go демона, оставяйки добавката да избере реализацията, чийто диалект говори шлюзът. Редът е важен: добавката зависи от едната или другата реализация, затова премахването на Go пакета първо събаря и добавката. Вторият път запазва Go демона и преминава към по-нова сборка, която разбира съобщението, а това обикновено значи PPA на поддръжник, а не версията от архива. В управляван парк закрепването на PPA е по-лесно за оправдаване от ученето на потребителите да премахват пакети.

Не съчетавайте двете в една промяна. По-късна повреда тогава ви оставя без възможност да кажете коя половина е помогнала, а бъдещо надграждане може да върне пакета, който току-що премахнахте.

Сложете в заявката двоичния файл на демона, версията му и точното съобщение. Никой не може да възпроизведе доклад, който казва само, че L2TP се е счупил след изданието, докато посочен атрибут плюс версия на пакет им дава откъде да започнат.

Три неща, които това не е

Това не е проблем на профила, тъй като същият профил работеше на 22.04 със същия шлюз. Не е липсващ маршрут или промяна в защитната стена, защото тези се провалят другаде с различни доказателства. Преинсталирането на добавката също не го поправя, тъй като същият демон се избира отново. Полезното описание посочва демона и съобщението, което е отказал.

Поправка от страната на шлюза е другият законен изход. Фърмуер, който спира да изпраща атрибута, оцелява при всяко надграждане на клиента, докато закрепен пакет оцелява следващото издание на дистрибуцията само ако някой помни защо е закрепен.

Сравнете двата пътя по цена на поддръжка, а не по скорост. И двата могат да работят; само един премахва несъответствието на диалекта.