Odrzucony PSK w L2TP/IPsec: najpierw okno dialogowe, potem pliki

Wklejasz wstępnie współdzielony klucz z wiadomości administratora do okna dialogowego NetworkManagera, zaznaczasz pole, aby go pokazać, i zgadza się co do znaku. Połączenie i tak kończy się błędem uwierzytelniania, zanim tunel wstanie. Gdy zobaczyłem to pierwszy raz, pomyślałem, że klucz jest błędny; nie był. O tym, co demon naprawdę czyta, decydują dwie inne rzeczy: plik tajemnic, który wtyczka zapisuje dla tego połączenia, oraz to, czy wartość przeszła przez okno bez zmian.

Poniższa droga śledzi klucz od pola do pliku i właśnie ta kolejność mówi, gdzie go zgubiono. Zrób to na maszynie, która zawodzi, a nie na tej, która działa, bo różnicą między nimi jest zwykle układ plików, a nie klucz.

Zacznij od okna dialogowego, ale nie ufaj polu

Otwórz kartę IPsec połączenia i wpisz klucz ponownie zamiast go wklejać. Klucz skopiowany z wiadomości czatu, PDF-a lub menedżera haseł może przyjść ze znakiem nowej linii na końcu, którego pole nie pokazuje, a widoczne znaki nadal wyglądają poprawnie.

Kliknij kontrolkę pokazywania hasła i spójrz na koniec łańcucha, nie na środek. Jeśli kursor zostawia pustą linię pod tekstem, usuń ją i wpisz ponownie ostatni znak. Ta jedna poprawka rozwiązuje zaskakującą część takich zgłoszeń i kosztuje mniej niż czytanie jakiegokolwiek logu.

Jeśli klucz pochodzi z systemu zgłoszeń, który łamie długie linie, poproś o niego kanałem, który nie łamie. Porównaj długości z administratorem, zamiast oglądać dwa łańcuchy obok siebie; znak zgubiony w miejscu łamania jest niewidoczny w foncie proporcjonalnym.

Śledź klucz do /etc/ipsec.d

Wtyczka nigdy nie przekazuje PSK demonowi IPsec jako argumentu w wierszu poleceń. Zamiast tego zapisuje wartość w pliku tajemnic i dba o to, aby demon włączył ten plik, dodając wiersz include do /etc/ipsec.secrets, jeśli go nie ma. To, co trzyma okno dialogowe, jest wejściem dla wygenerowanego pliku, a nie wartością w użyciu.

Wypisz, co istnieje, zanim cokolwiek zmienisz:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Starsze wersje wtyczki zapisywały jeden plik na połączenie, nazwany od UUID połączenia, na przykład /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Usunięcie profilu w aplecie nie usuwa tego pliku wiarygodnie. Jeśli stary plik z poprzedniego serwera wciąż leży na dysku i wciąż jest włączany, demon może wybrać tajemnicę należącą do profilu, którego już nie używasz, i połączenie zawodzi, choć widoczne pole jest poprawne.

Zrozum, co zmiana w 1.2.12 zrobiła z aktualizacjami

Wtyczka w wersji 1.2.12 zastąpiła pliki tajemnic dla każdego połączenia jednym współdzielonym plikiem, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Aktualizacja nie sprząta starszych plików według UUID, a istniejący wiersz include /etc/ipsec.d/*.secrets nadal je włącza. Wersja 1.2.16 zmieniła obsługę domyślnych propozycji, nie układ tajemnic.

Ta historia wyjaśnia, dlaczego dwie maszyny z wyglądającym tak samo profilem zachowują się różnie. Klucz jest identyczny; zbiór plików, które włącza demon, nie. Gdy usuwasz osierocony plik, odsuń go na bok zamiast kasować, potwierdź połączenie i skasuj go dopiero, gdy stan roboczy jest zapisany. Zmiana nazwy zachowuje starą wartość do odzyskania, jeśli okaże się, że usterka jest gdzie indziej.

Oddziel znaki, których format przechowywania nie pomieści

Dokumentacja strongSwan dotycząca łańcucha współdzielonej tajemnicy mówi, że wartość nie może zawierać znaku nowej linii ani cudzysłowu. Klucz wklejony z dokumentu może nieść jedno z nich bez żadnej widocznej różnicy w zwykłym oknie dialogowym.

Od 1.2.12 przechowywana wartość nie jest zwykłym tekstem. Wtyczka koduje PSK w base64, zanim dotrze on do pliku, a informacje o wydaniu podają to kodowanie jako powód, dla którego cudzysłów jest teraz dopuszczalny w kluczu. Cudzysłów wpisany w polu jest więc przedstawialny; to samo nie dotyczy każdego znaku sterującego.

Długość to inne ograniczenie. W oprogramowaniu L2TP/IPsec nie ma uniwersalnego minimum: niektóre klienty przyjmują klucze krótsze niż dwadzieścia znaków, a niektóre bramy wymuszają minimum. Jeśli krótki klucz zostanie odrzucony, reguła należy do polityki serwera albo do walidacji tego klienta, i podniesienie czegoś lokalnie tego nie zmieni.

Przeczytaj, która warstwa uwierzytelniania zawiodła

Najpierw uruchom ipsec --version, ponieważ strongSwan i Libreswan używają innych nazw plików i składni, a rada dla jednego może zaszkodzić drugiemu. Potem odczytaj etap awarii z komunikatu klienta lub logu demona: skarga na wstępnie współdzielony klucz to inne zdarzenie niż odrzucona nazwa użytkownika i hasło.

PSK uwierzytelnia końce tunelu. Nazwa użytkownika i hasło uwierzytelniają osobę wewnątrz L2TP, a PPP zajmuje się nimi po podniesieniu asocjacji IPsec. Poprawny PSK z błędnym kontem nadal zawodzi, a zmiana konta nie naprawi klucza, którego demon nigdy nie odczytał poprawnie.

Zamykając zgłoszenie, zapisz wszystkie cztery rzeczy: wersję wtyczki, używany plik tajemnic, to, czy klucz wpisano ponownie czy wklejono, oraz warstwę wymienioną w błędzie. Wtedy ktoś, kto później powtórzy tę drogę, może od razu przejść do różnicy między maszyną działającą a zawodzącą.