L2TP łączy się, ale negocjacja PPP zawodzi: która faza?

Tunel IPsec zostaje nawiązany, klient pokazuje chronionego peera, a potem połączenie pada, zanim cokolwiek dotrze do prywatnej podsieci. Ta luka to PPP wykonujący własną pracę: opcje łącza, uwierzytelnianie użytkownika i przydział adresu dzieją się już po tym, jak zaszyfrowany tunel istnieje. Nic w udanej wymianie pierwszej fazy nie daje hasła ani adresu wewnętrznego. Czytaj fazy po kolei, a błąd zwykle nazywa się sam.

Tunel to tylko pierwsza warstwa

L2TP przenosi ramki PPP w tunelu chronionym przez IPsec, co oznacza, że przed trasowaniem pakietu muszą powieść się dwie niezależne negocjacje. Zewnętrzna dowodzi, że oba końce zgadzają się co do kluczy i tożsamości. Wewnętrzna decyduje o parametrach łącza, o tym, czy użytkownik się uwierzytelnia i jaki adres dostaje klient.

Awaria wewnątrz PPP wygląda jak zepsuty tunel w każdym kliencie, który pokazuje tylko jedną lampkę stanu. Traktowanie jej jako problemu tunelu prowadzi do ponownego generowania kluczy, restartu usług i w końcu do wymiany współdzielonego sekretu, który nigdy nie był błędny. Użyteczne rozróżnienie jest tanie: jeśli wymiana z peerem się zakończyła, a klient przeszedł do pytania o nazwę użytkownika lub etapu uwierzytelniania, tunel jest w porządku. Wszystko po tym punkcie należy do PPP.

Przeczytaj ostatnią fazę, która się powiodła

Przejdź dziennik do przodu i zatrzymaj się na pierwszej fazie, która się nie zakończyła. Najpierw przychodzi LCP, potem uwierzytelnianie, potem IPCP dla parametrów IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Przekroczenie czasu LCP oznacza, że oba końce nigdy nie uzgodniły podstawowych opcji łącza, co jest niedopasowaniem profilu lub zablokowanym protokołem wewnętrznym, a nie złym hasłem. Jawne odrzucenie uwierzytelniania to odwrotny przypadek: łącze się podniosło, a jedna strona odrzuciła dane logowania. Przekroczenie czasu IPCP po udanym uwierzytelnieniu wskazuje na pule adresów lub politykę serwera. Każdy z tych przypadków ma innego właściciela i inną naprawę, dlatego faza jest ważniejsza niż końcowy tekst błędu.

Zachowaj wyciąg z dziennika razem z nazwą fazy w zgłoszeniu. Wklejony ogon bez granicy fazy zaprasza następnego czytelnika do zgadywania, a zgadywanie kosztuje tu godzinę.

Zgoda między klientem a serwerem

Oba końce muszą akceptować tę samą metodę uwierzytelniania, a zapisany profil może żądać takiej, którą serwer wycofał w poprzednim kwartale. Wdrożenia zarządzane ukrywają też stronę serwera, gdzie powód odrzucenia jest zwykle zapisywany przy użytkowniku, a nie przy urządzeniu.

Włącz jedną obsługiwaną metodę zamiast każdej starej opcji, ponieważ klient oferujący pięć metod zasłania, która zawiodła. Poproś administratora o politykę po stronie serwera i dokładne odrzucenie, co nie wymaga, by ktokolwiek publikował hasło. Stara metoda włączona, by uratować jednego klienta, ma zwyczaj rozprzestrzeniać się na każdy profil, który kopiuje plik.

Sprawdź adres, nie logowanie

Zakończone logowanie nie jest użyteczną sesją. IPCP negocjuje adres wewnętrzny, a wyczerpana pula lub polityka odmawiająca klientowi nadal mogą zostawić podłączony tunel bez niczego do trasowania.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Najpierw sprawdź adres wewnętrzny, potem trasę i resolver dla zasobu, którego naprawdę potrzebujesz. Adres wewnętrzny to nie publiczne wyjście, które podaje strona, i mylenie obu wysyła ludzi na polowanie na wyciek, którego nie ma. Testuj zasób prywatny po adresie, zanim przetestujesz go po nazwie, żeby awaria DNS nie została wzięta za awarię trasowania.

Zapisz fazę, metodę i adres w jednej notatce i opatrz ją datą. Jeśli to samo konto zawiedzie ponownie w ciągu miesiąca, ta notatka jest różnicą między pięciominutowym sprawdzeniem a nowym dochodzeniem. Awarie w różnych fazach to różne incydenty, nawet gdy klient pokazuje jedno okno.