Limit czasu L2TP w Ubuntu 22.04: błąd tunelu xl2tpd

Pulpit pokazuje połączenie w toku, IPsec zgłasza sukces, a interfejs PPP nigdy się nie pojawia. W syslogu ten sam numer tunelu powtarza się, aż próba zakończy się przekroczeniem limitu czasu na UDP 1701. Zanim zaczniesz edytować klucz współdzielony lub konfigurację serwera, rozpoznaj ten kształt: w Ubuntu 22.04 to zwykle regresja pakietu w xl2tpd, a serwer przez cały czas był poprawny.

Co mówi ci powtarzająca się para linii w syslogu

Nieudana sesja wypisuje co pewien czas dwie linie: demon nie znajduje tunelu dla przychodzącego komunikatu kontrolnego, a potem zrzuca identyfikatory połączenia i tunelu, które otrzymał. Później licznik ponownych prób osiąga limit i połączenie zamyka się przekroczeniem limitu czasu na porcie 1701. Adresy i identyfikatory są przypadkowe; liczy się kształt. IKE zakończyło się, ruch kontrolny L2TP dotarł, a demon nie zdołał przypisać go do tunelu, który już utworzył.

Usterka leży więc między kontrolą L2TP a PPP. Nic o tajnym kluczu, opcjach PPP ani zdalnej podsieci nie zostało jeszcze sprawdzone.

Potwierdź, że IPsec naprawdę się powiodło

Dwie kontrole oddzielają to od problemu z poświadczeniami i obie należą przed jakąkolwiek zmianą pakietu.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

Wyjście stanu wymienia połączenie i jego stan, a ustanowiony tunel oznacza, że pierwsza i druga faza się zakończyły. Wiersz dziennika o brakującym kluczu współdzielonym wskazuje wyłącznie na tajny klucz, więc zatrzymaj się i najpierw to napraw. Gdy IPsec jest ustanowiony, a limit czasu L2TP nadal się pojawia, demon pozostaje podejrzanym. Zachowaj dokładne linie z jednej próby zamiast całego dnia ponownych prób.

Sprawdź kompilację xl2tpd, nie nazwę wydania

Kompilacja jammy xl2tpd 1.3.16 w Ubuntu włączyła optymalizację czasu konsolidacji, co zepsuło analizę identyfikatora tunelu w odpowiedzi SCCRP serwera. Demon odrzuca wtedy pakiety kontrolne dla tunelu, który sam utworzył. Ciąg wersji liczy się bardziej niż nazwa dystrybucji.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Poprawiony pakiet to 1.3.16-1ubuntu0.1, więc kompilacja bez tego przyrostka jest starsza niż poprawka. Wyjście polityki pokazuje, którego kandydata zainstalowałaby aktualizacja, a lista wstrzymanych wyjaśnia, dlaczego poprawka nie dotarła. Tam, gdzie pakiet jest dostępny, zaktualizuj go i połącz się ponownie przez zwykły profil, zamiast edytować pliki ręcznie. Nie przebudowuj modułów i nie zmieniaj tajnego klucza, dopóki stara kompilacja jest zainstalowana.

Sprawdź PPP po zmianie

Skuteczną aktualizację potwierdza się na warstwie, która była zepsuta. Sprawdź, czy PPP wstało, a nie tylko czy zmieniła się ikona.

ip -4 addr show ppp0
ip route | grep ppp

Lista interfejsów powinna pokazywać adres lokalny i adres peera, a tabela tras powinna zawierać prefiksy tunelu. Syslog powinien pokazywać przyjęty tunel i pppd zgłaszający oba adresy, bez powtarzających się wierszy o nieznalezionym tunelu. Jeśli PPP działa, a ruch nadal zawodzi, spójrz następnie na trasowanie lub MTU, bo etap L2TP zakończył swoją pracę. Zapisz działającą wersję pakietu w notatkach maszyny, aby przyszła reinstalacja nie przywróciła zepsutej kompilacji.

Tam, gdzie poprawiony pakiet nie jest dostępny, udokumentowane alternatywy to lokalna kompilacja ze źródeł 1.3.16 lub 1.3.17, przejście na kl2tpd albo przypięty downgrade. Każda niesie koszt utrzymania, który warto zapisać.