L2TP: śmiertelny sygnał 15, NO_PROPOSAL_CHOSEN i brakujący modp1024

Połączenie zawiesza się, klient kończy działanie, a ostatnia linia na ekranie to death_handler: Fatal signal 15 received. Ta linia zgłasza przerwanie, a nie przyczynę. Jedna linia wyżej w logu IPsec prawie zawsze jest NO_PROPOSAL_CHOSEN, a para wskazuje na fazę 2 wymiany, gdzie strony porównują wybory szyfrowania i skrótu i zatrzymują się, gdy nie mają nic wspólnego. Dane logowania nie zostały na tym etapie wysłane, więc ponowne wpisanie hasła nie może zmienić wyniku.

Zwykle dwa czynniki opróżniają ten przekrój na kliencie Linux. Lokalny demon może już nie implementować grupy Diffie-Hellmana wymaganej przez profil albo profil może nieść propozycję fazy 1 w polu fazy 2. Oba zostawiają ślad w logu i żaden nie jest problemem z kontem.

Co naprawdę mówią oba komunikaty

IKE negocjuje etapami. Faza 1 buduje chroniony kanał i wybiera własne algorytmy; faza 2, czyli podrzędna SA, przenosi ruch według odrębnego zestawu. NO_PROPOSAL_CHOSEN to powiadomienie, które odpowiadający zwraca, gdy żadna z oferowanych kombinacji nie jest akceptowalna, i pojawia się jako [ HASH N(NO_PROP) ] wewnątrz wymiany INFORMATIONAL.

Sygnał 15 to inne zdarzenie: coś kazało procesowi lokalnemu się zatrzymać, a obsługujący to zapisał. Gdy obie linie pojawiają się razem, kolejność jest przyczynowa — najpierw odrzucenie, potem wyłączenie.

Przeczytaj negocjacje, zanim dotkniesz danych logowania

Podnieś poziom logowania tam, gdzie pisze demon, a potem połącz się ponownie, obserwując wyjście. Na hoście z NetworkManager wtyczka L2TP przekazuje ten poziom do backendu, a komunikaty trafiają do journala lub klasycznego pliku syslog w zależności od dystrybucji. Każde z tych poleceń pokaże wymianę: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' lub tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Linia zawierająca pluto pochodzi z libreswan, charon z strongSwan, a obie opisują ten sam stan innymi słowami. Forma warta szukania to ta, która nazywa brakującą grupę, na przykład algorithm 'modp1024' is not supported, bo zamienia niejasną awarię w konkretną.

Gdzie zniknął modp1024

Grupa 2 Diffie-Hellmana jest tak słaba, że kilka dystrybucji przestało kompilować ją do libreswan od wersji 3.30. Wtedy profil napisany lata temu albo wzięty z poradnika bramy, który wymienia tylko aes128-sha1-modp1024, żąda od lokalnego demona czegoś, czego ten zupełnie nie potrafi wykonać. Nowsze kompilacje NetworkManager-l2tp czynią ten wynik bardziej prawdopodobnym: od 1.2.16 zastępują zestaw propozycjami w stylu Windows 10 i iOS i porzucają modp1024, gdy tylko wykryty zostanie libreswan. Druga strona jest często niewinna i nadal oferuje dokładnie tę grupę, którą skonfigurowałeś.

To właśnie ta asymetria sprawia, że awaria wydaje się losowa. Starszy klient się łączy, ten sam profil na zaktualizowanym laptopie już nie, a konfiguracja serwera nigdy się nie zmieniła. Szkody powoduje rozjazd wersji.

Dwie naprawy o różnym zasięgu

Tania naprawa to zaprzestanie ręcznego wpisywania algorytmów. Wyczyść oba pola propozycji w edytorze i pozwól wtyczce wybrać zestaw akceptowany przez drugą stronę; jeśli brama obsługuje nowoczesne grupy, negocjacje kończą się bez dalszej pracy.

Druga naprawa utrzymuje dostęp do starej bramy przez instalację strongSwan, którego pakiety w większości dystrybucji nadal implementują grupę 2. To wymiana demona, więc ma koszt: sprawdź, czy inne tunele na hoście zależą od konfiguracji libreswan, zanim go usuniesz, i spodziewaj się odmów SELinux między NetworkManager a wtyczką strongSwan w Fedorze. Te odmowy pojawiają się w logu audytu, a nie w śladzie IKE, dlatego tunel może wyglądać na zepsuty zaraz po udanej instalacji. Kolejność, która działa, to najpierw dnf install strongswan, potem rpm -e libreswan.

Pasujące ciągi propozycji i pułapki wokół nich

Gdy pola trzeba wypełnić ręcznie, faza 1 i faza 2 przyjmują różne wartości. Para znana z tego, że działa wobec strony w stylu Meraki, oferuje w fazie 1 aes128-sha1-modp1024 z 3des-sha1-modp1024 za nim, obie zamknięte wykrzyknikiem, który czyni zestaw ścisłym, więc wysyłane są tylko te propozycje.

Faza 2 zwęża się wtedy do aes128-sha1 i 3des-sha1 z tym samym ścisłym znacznikiem i bez żadnego przyrostka Diffie-Hellman. Linia fazy 2 niosąca -modp1024 to wartość fazy 1 w niewłaściwym polu, a odpowiadający odrzuca ją przy każdej próbie. Skopiuj tę linię do drugiego profilu, a drugi profil zawiedzie tak samo, i tak jedna literówka staje się incydentem dla całej floty.

Inne usterki noszą to samo okno bez bycia niezgodnością propozycji. W KDE typ L2TP może być wymieniony przy zainstalowanej wtyczce, a każde połączenie natychmiast ginie, bo edytor połączeń i pomocniki czasu działania są dostarczane jako osobne pakiety. Hosty bez ekranu mogą użyć ponownie profilu z działającego pulpitu: skopiuj go z /etc/NetworkManager/system-connections/, ustaw tryb na 600, a następnie uruchom nmcli con reload. Podnieś go poleceniem nmcli con up id work-l2tp, bo naga forma wymaga UUID, i usuń każdy nieaktualny wpis ifname, inaczej menedżer odpowiada Could not find source connection, choć wszystko inne jest poprawne.

Klucz współdzielony z góry można przechowywać jako czysty tekst lub jako 0s, po którym następuje base64; obie formy działają, ale wartość musi zgadzać się z bramą bajt po bajcie, łącznie z końcowymi spacjami, które skopiowałeś razem z nią.