L2TP/IPsec nie działa: rozdziel IPsec, uwierzytelnianie tunelu i logowanie PPP

Trzy rzeczy uwierzytelniają się wewnątrz jednego połączenia L2TP/IPsec, a tylko jedna z nich dotyczy osoby wybierającej numer. IPsec dowodzi punktów końcowych tunelu, połączenie sterujące L2TP może ponownie dowieść partnerów własnym sekretem, a PPP dowodzi konta użytkownika wewnątrz sesji. Awaria na każdym etapie wygląda w oknie klienta jak ogólny błąd logowania, a w dzienniku serwera wygląda zupełnie inaczej. Przechodź przez etapy po kolei i zatrzymaj się na pierwszym, który zawiedzie, ponieważ każdy etap poniżej nieprzetestowanego też jest nieprzetestowany.

Trzy etapy uwierzytelniania, trzy różne tożsamości

IPsec dowodzi, kto jest właścicielem punktów końcowych, używając wcześniej udostępnionego klucza lub certyfikatu. Ta tożsamość należy do maszyn lub bram, nigdy do człowieka przy klawiaturze. Gdy partnerzy nie potrafią się porozumieć na tym etapie, nie wymienia się w ogóle żadnego pakietu L2TP.

Połączenie sterujące L2TP może dodać drugą, osobną wymianę wyzwanie-odpowiedź, sterowaną wspólnym sekretem, który muszą mieć oba końce.

RFC 2661 czyni to uwierzytelnianie połączenia sterującego opcjonalnym, co wyjaśnia, dlaczego ten sam błąd daje różne objawy na dwóch serwerach. Wdrożenie, które nigdy nie skonfigurowało sekretu tunelu, całkowicie pomija ten etap; to, które skonfigurowało go tylko po jednej stronie, zawodzi, zanim PPP zostanie w ogóle zaproponowane. PPP uwierzytelnia następnie użytkownika za pomocą PAP, CHAP lub MSCHAPv2 i przekazuje nazwę do magazynu kont, który może być lokalny, w chap-secrets lub w RADIUS. Błędne hasło w tym miejscu nadal pozostawia działający tunel i nieudaną sesję.

Przeczytaj miejsce zatrzymania, zanim zmienisz konfigurację

Zacznij od ipsec --version, aby wiedzieć, czy wynik stanu należy do strongSwan, czy do Libreswan. Następnie czytaj dziennik serwera, a nie okno klienta, ponieważ serwer zapisuje, który etap odmówił.

Jedna linia zwykle rozstrzyga zgłoszenie: skarga na IKE lub propozycje to etap pierwszy, komunikat o połączeniu sterującym to etap drugi, a odrzucenie metody PPP lub konta to etap trzeci. Skopiuj tę linię do zgłoszenia ze znacznikiem czasu. Zgadywanie po stronie klienta marnuje jedyny dowód, który już masz.

Trzymaj materiał kluczowy i hasła poza tym wklejeniem; nazwa etapu kieruje pracą, a ujawniony wcześniej udostępniony klucz ponownie otwiera zgłoszenie z gorszymi skutkami.

Etap pierwszy: czy IPsec ma asocjację?

Uruchom ipsec statusall na strongSwan lub ipsec whack --status na Libreswan i szukaj ustanowionej asocjacji podrzędnej z niezerowymi licznikami. ip xfrm state pokazuje widok jądra na obu. Zainstalowana para SA z rosnącymi licznikami oznacza, że etap pierwszy jest gotowy i możesz iść dalej.

Całkowity brak asocjacji wskazuje na adres partnera, zestaw propozycji lub wcześniej udostępniony klucz, a czasem na urządzenie, które przepisuje UDP 500, ale porzuca UDP 4500. Asocjacja, która się ustanawia i znika po kilku sekundach, to zwykle niezgodność czasu życia między końcami, a nie problem z poświadczeniami. Sprawdź, czy obie strony wymieniają te same propozycje szyfrowania i skrótu, zanim cokolwiek wpiszesz ponownie. Jeśli nie, żaden klucz nigdy nie zadziała.

Zatrzymaj się, dopóki brakuje asocjacji. Edycja opcji PPP w tym miejscu niczego nie zmienia i ukrywa prawdziwą usterkę przed następną osobą.

Etap drugi: czy połączenie sterujące L2TP się uwierzytelniło?

Gdy IPsec działa, obserwuj demona L2TP w poszukiwaniu połączenia sterującego, które osiąga stan ustanowiony, ponieważ PPP nie może się wcześniej rozpocząć. Odmowa na połączeniu sterującym oznacza, że sekret tunelu różni się między końcami albo jeden koniec wymaga sekretu, którego drugi nigdy nie wysyła. Klienci często pokazują jedno pole z etykietą shared secret, a należy ono zwykle do IPsec, a nie do L2TP. Wypełnienie go nie konfiguruje sekretu tunelu, a wyczyszczenie go nie wyłącza.

Jeśli żadna strona nie skonfigurowała sekretu tunelu, pomiń ten etap i potraktuj awarię połączenia sterującego jako problem osiągalności. Potwierdź, że UDP 1701 dociera do demona i że oba końce zgadzają się co do tej samej enkapsulacji. Reguła zapory napisana dla jednego z tych dwóch warunków to częsta przyczyna połączenia, które otwiera się tylko do połowy.

Tylko sesja, która zaczyna negocjować PPP, naprawdę przeszła etap tunelu.

Etap trzeci: czy PPP odrzuca konto?

Awaria PPP wygląda inaczej z zewnątrz: tunel jest ustanowiony, sesja się zaczyna, a demon rejestruje awarię metody uwierzytelniania lub odrzucenie konta. Przeczytaj metodę nazwaną w tym komunikacie. PAP i CHAP zawodzą z różnych powodów, a serwer, który odrzuca jedną, odrzuci klienta oferującego tylko tę jedną.

Na serwerze Linux sprawdź plik opcji, który demon przekazuje PPP, zwykle /etc/ppp/options.xl2tpd, i potwierdź, które metody są akceptowane i gdzie rozwiązywane są konta. Nazwa, która istnieje w RADIUS, ale nie w lokalnym pliku sekretów, zawodzi czysto i wygląda jak błędne hasło. Następnie sprawdź, czy klient oferuje metodę akceptowaną przez serwer, a nie silniejszą, której serwer odmawia negocjować. Zmiana wcześniej udostępnionego klucza, aby naprawić ten etap, marnuje popołudnie i niczego nie zmienia.

Gdy sesja w końcu wstaje, przydział adresów, DNS i trasy nie zostały jeszcze sprawdzone, i każdy zawodzi cicho na swój sposób. Trzymaj trzy warstwy osobno w notatkach: poprawny klucz z błędnym kontem zawsze zawodzi, a naprawa jednej warstwy nigdy nie naprawia innej.