NO_PROPOSAL_CHOSEN w L2TP? Najpierw zeskanuj bramę

Klient L2TP/IPsec, który zawodzi przed monitem o nazwę użytkownika, nigdy nie uzgodnił fazy 1. Zeskanuj zbiór propozycji bramy zamiast wklejać łańcuchy szyfrujące.

Monit o nazwę użytkownika nigdy się nie pojawia, a klient zgłasza NO_PROPOSAL_CHOSEN. W tym momencie dane logowania i klucz wstępnie współdzielony są nieistotne, ponieważ obie strony nie uzgodniły, jak chronić fazę 1. Większość ludzi reaguje wklejeniem łańcucha szyfrującego znalezionego w internecie. Skanowanie bramy odpowiada na to samo pytanie z dowodami i zajmuje mniej więcej tyle samo czasu.

Co wyklucza komunikat

Odrzucenie następuje w trybie głównym, przed jakąkolwiek wymianą L2TP lub PPP, więc tunel i baza użytkowników nie zostały odpytane. Faza 1 negocjuje szyfrowanie, integralność i grupę Diffie-Hellmana. Faza 2 negocjuje propozycję ESP dla danych. Awarii fazy 1 nie da się naprawić przez zmianę ustawienia PFS w fazie 2, a ukończone skojarzenie IKE nie dowodzi, że propozycja ESP pasuje.

Zapisz backend, zanim zmienisz składnię: ipsec --version. libreswan i strongSwan akceptują różne zapisy propozycji dla tych samych algorytmów.

Następnie odczytaj odrzucenie w kontekście za pomocą journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Zeskanuj bramę, aby poznać jej zestaw transformacji

Skaner pyta bramę bezpośrednio, jakie transformacje będzie negocjować. Najpierw zatrzymaj lokalną usługę IPsec, aby próba nie konkurowała z twoim klientem, a następnie odczytaj wiersze SA. Traktuj listę jako dowód dotyczący drugiej strony, a nie jako menu do włączenia w całości.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Starsze urządzenia często oferują 3DES, SHA1 i MODP1024, ponieważ były to wartości domyślne w chwili wysyłki produktu i nikt ich nie przejrzał. Zachowaj surowe wyjście skanowania, bo jest to jedyny zapis tego, co druga strona oferowała tego dnia. Jeśli to najsilniejsze dostępne pokrycie, właściwa eskalacja prowadzi do właściciela bramy, a nie do konfiguracji klienta, która ponownie włącza słabą kryptografię dla wszystkich.

Dopasuj pokrycie, nie wyłączając bezpieczeństwa

Wprowadź tylko te transformacje, które występują zarówno w skanie, jak i w twojej polityce. Poniższy przykład odzwierciedla bramę oferującą w fazie 1 3DES, SHA1 i MODP1024. Zwróć uwagę na zastrzeżenie dotyczące backendu: libreswan 4.x nie kompiluje grupy modp1024, więc dotyczy to strongSwana lub kompilacji libreswana ze wsparciem DH2. Sprawdź wersję, zanim uznasz, że klient jest zepsuty.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Wykrzyknik na końcu przypina pojedynczą propozycję. Użyj go, aby wyizolować test, a potem usuń, żeby brama mogła później wynegocjować coś silniejszego.

Sprawdź demon i port przed ponowną próbą

NetworkManager-l2tp uruchamia własną instancję xl2tpd. Jeśli usługa systemowa ma już port UDP 1701, klient przechodzi na efemeryczny port źródłowy, co dopuszcza RFC 3193, a niektóre serwery po cichu odrzucają. Sprawdź właściciela gniazda przed następną próbą.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Nieaktualne wygenerowane sekrety to kolejna cicha przyczyna. Pliki w /etc/ipsec.d/ nazwane od starego połączenia mogą przeżyć profil, który je utworzył, więc usuń te, do których nic nie odwołuje się, i spróbuj ponownie.

Na koniec sprawdź, skąd pochodzi porada. Plik ipsec.conf napisany dla IKEv1 XAuth opisuje inny typ VPN, a jego propozycja nie jest jedynym wierszem, który będzie błędny w profilu L2TP. Zapisz wprowadzony zestaw transformacji obok profilu, żeby następna osoba nie powtarzała sondy.

Powiązane artykuły