L2TP NO_PROPOSAL_CHOSEN: która faza właściwie zawiodła?
Powiadomienie mówi, że propozycja została odrzucona, a nie która. Przeczytaj dziennik backendu, aby ustalić fazę, a potem porównaj zestawy z tym, kto zarządza bramą.
NO_PROPOSAL_CHOSEN pojawia się, zanim sprawdzona zostanie jakakolwiek nazwa użytkownika PPP, co jest użytecznym faktem i zarazem powodem, dla którego komunikat wprowadza w błąd. Informuje, że jedna strona odrzuciła propozycję; nie informuje, który parametr się nie zgadzał, i nic nie mówi o tym, czy odrzucenie nastąpiło podczas budowania asociacji IKE, czy później podczas negocjacji ochrony ruchu. Za tymi dwiema możliwościami stoją dwie różne poprawki, a tylko jedna z nich dotyczy pola wyboru PFS, po które ludzie sięgają najpierw.
Jeden komunikat, dwa zestawy propozycji
Układ IKEv1 L2TP/IPsec obejmuje dwie następujące po sobie negocjacje. Faza 1 buduje asociację bezpieczeństwa IKE z algorytmu szyfrowania, algorytmu integralności i grupy Diffie-Hellman. Faza 2 negocjuje następnie, jak będzie chroniony ruch, a wymóg PFS należy do tej drugiej rozmowy.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Ponieważ fazy następują po sobie, miejsce awarii mówi, którą listę porównywać. W tym tkwi cała wartość diagnostyczna komunikatu i warto ją wydobyć, zanim dotknie się jakiegokolwiek ustawienia.
Dlaczego pole wyboru PFS nie naprawi fazy 1
Wyłączenie PFS zmienia właściwość fazy 2. Jeśli strony nigdy nie uzgodniły fazy 1, rozmowa ESP w ogóle się nie odbywa, więc pole wyboru nie ma żadnego wpływu na odrzucenie, i dlatego jego przełączenie daje ten sam błąd z innym znacznikiem czasu.
Odwrotny błąd jest równie częsty. Udana asociacja IKE nie dowodzi, że propozycja ESP jest akceptowalna, i na pewno nie dowodzi, że grupa fazy 2 się zgadza. Ustanowiony tunel zarządzania traktuj jako dowód wyłącznie o fazie 1. Ludzie czytają zieloną linię jako „tunel działa”, a potem spędzają godzinę na niewłaściwej fazie, bo nic im nie powiedziało, że druga negocjacja się nie zaczęła.
Przeczytaj dziennik, zanim wybierzesz algorytmy
Zbierz komunikaty bezpośrednio poprzedzające odrzucenie z backendu, który faktycznie obsługuje połączenie, i skoreluj je z tą samą próbą. Bez tej korelacji czytasz historię innego połączenia i wyciągasz z niej wnioski.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanNa podstawie tych wierszy odpowiedz na dwa pytania: czy powstała asociacja fazy 1 i która wymiana zawiodła. Te dwie odpowiedzi zawężają poszukiwania do jednej listy atrybutów. Goły komunikat bez otaczającego kontekstu tego nie potrafi, choćby kuszące było wypróbować propozycję z wątku na forum. Kopiowanie działającego ciągu z maszyny z innym backendem zwykle zastępuje jedno odrzucenie innym, nieco później.
Składnia backendu nie podróżuje
Zapisz wersję NetworkManager-l2tp i wersję backendu IPsec, zanim cokolwiek porównasz. Libreswan i strongSwan nie dzielą składni propozycji ani identycznych zestawów algorytmów, więc ciąg działający w jednym jest błędem składni w drugim. Zainstalowany backend może też odmówić IKEv1 zgodnie z polityką, a wtedy żadna propozycja nigdy nie zostanie przyjęta.
README projektu dokumentuje te różnice między backendami i utrzymuje pola fazy 1 i fazy 2 osobno. Czytaj go jako dokumentację struktury, a nie jako zaproszenie do włączenia każdego historycznego szyfru i słabej grupy, bo połączenie, które udaje się tylko w ten sposób, nie jest połączeniem, o którego zbudowanie proszono.
Uzgodnij zestaw, a potem zweryfikuj etapy
Zapytaj operatora bramy, które zestawy IKE i ESP są obsługiwane i zatwierdzone, a potem porównaj tę odpowiedź z rzeczywistymi propozycjami klienta, a nie z jego plikiem konfiguracji. Jeśli spór dotyczy konkretnie PFS fazy 2, ustal obsługiwaną grupę albo wyraźnie zatwierdzoną politykę bez PFS. Nie wnioskuj polityki z nazwy błędu.
Gdy jedyne pokrycie wymaga kryptografii, której organizacja już nie akceptuje, decyzja należy do bramy albo do migracji protokołu. Poszerzanie ciągu klienta, aż coś wynegocjuje, to sposób na dostarczenie znanej słabości z zielonym znacznikiem obok.
Po poprawieniu rzeczywistej niezgodności potwierdź ustanowienie IPsec, zanim zbadaj L2TP i PPP, i traktuj każde późniejsze odrzucenie uwierzytelnienia jako należące do następnego etapu. Następnie sprawdź odnawianie w zatwierdzonym procesie testowym, bo ustanowienie pierwszej asociacji nic nie mówi o reszcie jej życia.