Pusty dziennik debugowania L2TP? Błąd prawdopodobnie jest w journalu

Uruchamiasz program pomocniczy L2TP z debugowaniem, patrzysz na terminal, a on zatrzymuje się bez niczego użytecznego na ekranie. To nie jest zepsuta flaga debugowania. Połączenie NetworkManager L2TP to cztery współpracujące procesy, i tylko niektóre z nich piszą do terminala, który obserwujesz. Reszta dowodów jest w journalu, o jeden filtr dalej.

Cztery procesy, dwa miejsca docelowe logu

Połączenie zaczyna się od IPsec, który w zależności od instalacji to libreswan albo strongSwan. Potem tunel prowadzi demon L2TP, tradycyjnie xl2tpd, a w niektórych kompilacjach kl2tpd. Na końcu pppd zajmuje się uwierzytelnianiem i adresacją wewnątrz niego.

Usługa pomocnicza koordynuje te części i wypisuje własny postęp. Demon IPsec i pppd zwykle raportują przez journal systemowy, dlatego terminal pokazuje nieudane połączenie, podczas gdy przyczyna leży w pliku, którego nie otworzyłeś.

Ten podział wyjaśnia też, dlaczego błąd PSK i błąd hasła wyglądają z pulpitu tak samo: oba dają ogólne rozłączenie, a etap, który zawiódł, widać tylko w wyjściu każdego procesu. To jest cały powód, dla którego journal ma tu znaczenie. Jeden ogólny komunikat na pulpicie, czterech możliwych autorów za nim.

Zbierz jedną próbę, potem przeczytaj kolejność

Odtwórz raz, ze znanym profilem i znanym czasem, a potem czytaj wąskie okno zamiast całego rozruchu. Powtarzanie prób przy zmianie ustawień zmienia log w mieszankę, której nie da się zinterpretować.

Te polecenia wybierają procesy uczestniczące w bieżącym rozruchu, a ścieżkę wtyczki warto potwierdzić w swojej dystrybucji:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Powtórzone pola w jednym wywołaniu wybierają sumę tych procesów, co zachowuje kolejność w czasie. W systemie opartym na Debianie równoważne zapytanie to dpkg -L; chodzi o to, aby znaleźć, gdzie program pomocniczy naprawdę mieszka, zanim spróbujesz uruchomić go ręcznie.

Trzy warunki decydują o następnym kroku

Przeczytaj pierwszy nieudany etap, a potem wybierz odpowiednio. Jeśli IPsec zgłasza błąd propozycji lub uwierzytelnienia drugiej strony, tunel nigdy nie powstał, a zmiana hasła PPP nie może pomóc.

Jeśli tunel powstał, a pppd odrzucił logowanie, wspólny sekret był już w porządku, a problem z poświadczeniami jest o warstwę wyżej. Jeśli pppd wynegocjował adres, a błąd pojawia się później, oba działają, a pozostały problem to routing, DNS lub własna polityka serwera.

Te trzy gałęzie obejmują prawie każde ogólne rozłączenie, i decyduje o nich to, który proces zapisał ostatni błąd, a nie to, który komunikat o błędzie wygląda najbardziej alarmująco.

Warto też potwierdzić, który backend IPsec jest zainstalowany, zanim dotkniesz ustawienia debugowania. Opcja logowania napisana dla strongSwan nic nie robi, gdy działa libreswan, a połączenie nadal będzie zawodzić w tym samym miejscu, gdy edytujesz plik, którego nikt nie czyta.

Tryb debugowania zostawia pliki

Pierwotny przepływ debugowania uruchamia usługę ręcznie z flagą debugowania, a ten tryb może pozostawić wygenerowane pliki konfiguracji czasu wykonania na miejscu, gdy połączenie się kończy.

Te pliki zawierają materiał uwierzytelniający: klucz wstępnie współdzielony, poświadczenia albo oba. Wygenerowana konfiguracja skopiowana do okna czatu to ujawnienie poświadczeń, a nie wyciąg z logu. Usuń linie z sekretami, zanim cokolwiek udostępnisz, i usuń katalog, gdy dochodzenie się skończy. Traktuj je jak sekrety, wyciągnij konkretne linie potrzebne do raportu i usuń je później, zamiast wklejać katalog do zgłoszenia.

Ręczna instancja też musi być uzgodniona z normalną. Uruchomienie kopii debugowania, gdy usługa już posiada wtyczkę, daje dwóch właścicieli i log, który miesza oba, co jest gorsze niż brak jakiegokolwiek wyjścia debugowania.

Potem przywróć normalny program pomocniczy

Gdy dochodzenie się skończy, zatrzymaj ręczną instancję, usuń zachowane pliki czasu wykonania i połącz się ponownie normalną ścieżką, aby następna osoba zobaczyła konfigurację zgodną z rzeczywistością.

Następnie sprawdź wynik w warstwie, która zawiodła, a nie przy ikonie pulpitu:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Sesja, która się uwierzytelnia, otrzymuje adres i jest routowana do zamierzonego celu, to wynik, który debugowałeś. Cichy terminal podczas nieudanej próby mówi ci tylko gdzie wyjście nie zostało zapisane.