L2TP w Ubuntu 24.04 nie działa: xl2tpd czy demon go-l2tp?

Ubuntu 24.04 po cichu podmienił demona stojącego za wtyczką L2TP NetworkManagera. Starsza ścieżka używała xl2tpd; nowsze pakowanie wnosi implementację w Go, która tworzy demona o nazwie kl2tpd. Wtyczka uruchamia ten, który jest zainstalowany, więc aktualizacja może podmienić demona bez ruszania profilu ani danych logowania. To cała usterka: komunikat sterujący, którego nowy demon nie rozpoznaje.

Wtyczka koordynuje IPsec, L2TP i PPP, a następnie przekazuje powstały interfejs NetworkManagerowi. Sama nie implementuje L2TP.

Wtyczka jest koordynatorem, nie demonem

network-manager-l2tp uruchamia pomocnika IPsec, demona L2TP i PPP oraz podłącza interfejs do zarządzania połączeniami pulpitu. Przez lata demonem był xl2tpd, a każdy poradnik wspominający jego konfigurację dziedziczył to założenie. Później pakowanie Debiana zaakceptowało którąkolwiek z dwóch implementacji, a 24.04 instaluje wersję w Go, która dostarcza kl2tpd. Żadne pole profilu nie zapisuje, który demon działał wcześniej, więc podmiana pozostaje niewidoczna, dopóki komunikat nie zostanie odrzucony.

Maszyna z oboma pakietami może nadal nie uruchomić tego, czego oczekujesz. Wybór jest decyzją wtyczki, a nie poradnika, którego przestrzegałeś.

Przeczytaj etap, zanim wybierzesz naprawę

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

Skoreluj jedną próbę między pomocnikami zamiast ufać powiadomieniu pulpitu. To zapytanie pokazuje, gdzie zatrzymała się sekwencja, a dpkg -l pokazuje, która implementacja jest zainstalowana. Błąd, który pojawia się po zestawieniu peera IPsec i wspomina komunikat sterujący lub nieznany atrybut, wskazuje na demona. Błąd przed powstaniem tunelu oznacza, że demon nigdy nie został osiągnięty.

Niezgodność wstępnie współdzielonego klucza kończy się na etapie IPsec i wskazuje peera. Problem z poświadczeniami PPP pojawia się, gdy tunel stoi, i zwykle niesie czytelne odrzucenie CHAP lub MS-CHAP. Oba są widoczne w tym samym zapytaniu i są to różne problemy.

Dwie ścieżki i one się nie mieszają

sudo apt install xl2tpd
sudo apt purge go-l2tp

Ta para umieszcza xl2tpd, a następnie usuwa demona Go, pozwalając wtyczce wybrać implementację, której dialektem mówi brama. Kolejność ma znaczenie: wtyczka zależy od jednej lub drugiej implementacji, więc usunięcie najpierw pakietu Go pociąga za sobą także wtyczkę. Druga ścieżka zatrzymuje demona Go i przechodzi na nowszy build, który rozumie komunikat, co zwykle oznacza PPA opiekuna zamiast wersji z archiwum. W zarządzanej flocie łatwiej uzasadnić przypięcie PPA niż uczenie użytkowników usuwania pakietów.

Nie łącz obu w jednej zmianie. Późniejszy błąd nie pozwoli wtedy powiedzieć, która połowa pomogła, a przyszła aktualizacja może przywrócić właśnie usunięty pakiet.

Umieść w zgłoszeniu plik binarny demona, jego wersję i dokładny komunikat. Nikt nie odtworzy raportu, który mówi tylko, że L2TP zepsuł się po wydaniu, podczas gdy nazwany atrybut i wersja pakietu dają punkt zaczepienia.

Trzy rzeczy, którymi to nie jest

To nie problem profilu, bo ten sam profil działał na 22.04 z tą samą bramą. To nie brakująca trasa ani zmiana firewalla, bo te zawodzą gdzie indziej z innymi dowodami. Ponowna instalacja wtyczki też tego nie naprawia, bo wybierany jest znowu ten sam demon. Przydatny opis nazywa demona i komunikat, który odrzucił.

Naprawa po stronie bramy to drugi uprawniony wynik. Firmware, który przestaje wysyłać atrybut, przetrwa każdą aktualizację klienta, natomiast przypięty pakiet przetrwa kolejne wydanie dystrybucji tylko wtedy, gdy ktoś pamięta, dlaczego jest przypięty.

Porównaj obie ścieżki pod kątem kosztu utrzymania, a nie szybkości. Obie mogą działać; tylko jedna usuwa niezgodność dialektu.