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 со истата порта. Тоа не е ниту маршрута што недостасува ниту промена на огнениот ѕид, бидејќи тие не успеваат на друго место со други докази. Преинсталирањето на приклучокот исто така не го поправа, бидејќи повторно се избира истиот демон. Корисниот опис го именува демонот и пораката што ја одбил.

Поправка на страната на портата е другиот легитимен исход. Фирмверот што престанува да го праќа атрибутот преживува секое надградување на клиентот, додека закачен пакет преживува следното издание на дистрибуцијата само ако некој се сеќава зошто е закачен.

Споредете ги двата патеки по трошок за одржување, а не по брзина. Двата можат да работат; само едниот ја отстранува неусогласеноста на дијалектот.