Wymiana IKEv2 działa, potem uwierzytelnianie zawodzi: gdzie szukać

Klient, który otrzymuje odpowiedź IKEv2, udowodnił, że brama jest osiągalna, że obie strony mogą wynegocjować propozycję i że wstępna wymiana kluczy została zakończona. Nie udowodnił jednak, że ktokolwiek został uwierzytelniony. Następna wymiana przenosi tożsamości, certyfikaty lub EAP i właśnie tam połączenie zwykle się zatrzymuje. Odczytanie, która z tych kontroli zawiodła, to cała diagnoza, a sam komunikat błędu rzadko to mówi.

Kontrola 1: czytaj etap, nie komunikat

Odrzucenie może pochodzić z trzech miejsc: klienta odrzucającego tożsamość serwera, bramy odrzucającej dowód klienta oraz zewnętrznej usługi uwierzytelniania odrzucającej konto.

Każde tworzy inną linię dziennika na innej maszynie i każde ma inne rozwiązanie. Odrzucenie certyfikatu serwera po stronie klienta to problem zaufania lub nazewnictwa na kliencie; odrzucenie certyfikatu klienta po stronie bramy to problem zaufania na bramie; błąd EAP to problem konta lub zaplecza. Komunikat, który widzisz, jest zwykle podsumowaniem klienta jednego z tych przypadków, dlatego dziennik bramy jest tak samo ważny jak dziennik klienta.

Kontrola 2: która tożsamość została sprawdzona

Klient może odrzucić certyfikat serwera lub oczekiwaną tożsamość, zanim zostaną podane jakiekolwiek dane uwierzytelniające użytkownika, a działający adres serwera nie zastępuje tej kontroli. Identyfikator oczekiwany przez klienta musi odpowiadać temu, co przedstawia brama, co jest faktem konfiguracji, a nie faktem sieci.

W terminologii strongSwan to rightid na kliencie i własna tożsamość bramy po drugiej stronie, a niezgodność kończy się niepowodzeniem, zanim w ogóle omówi się EAP.

Brama może osobno odrzucić certyfikat klienta, jego dowód klucza lub uwierzytelnienie konta, a te trzy nie są wymienne. Zresetowanie hasła użytkownika nie odnawia certyfikatu urządzenia, a ponowna instalacja certyfikatu urządzenia nie naprawia błędnej tożsamości serwera. Przy błędach certyfikatów sprawdź najpierw zegar, potem łańcuch zaufania, a na końcu oczekiwany identyfikator; klient, którego zegar odbiega o kilka minut, nie przechodzi kontroli ważności, która wygląda jak błąd zaufania. swanctl --list-certs na obu końcach pokazuje, co każda strona naprawdę posiada.

Kontrola 3: jeśli EAP wchodzi w grę

Klient i serwer muszą uzgodnić obsługiwaną metodę, a zaplecze musi zaakceptować podaną tożsamość.

Nazwa użytkownika może wymagać przyrostka domeny lub określonego formatu konta wymaganego przez wdrożenie, a format jest udokumentowany, a nie zgadywalny. Podanie udokumentowanych pól operatora jest szybsze niż próbowanie wariantów i pozwala uniknąć drugiego problemu: powtarzane próby mogą wywołać blokadę konta, która następnie ukrywa pierwotny etap za nowym błędem. Jeśli metoda to EAP-MSCHAPv2 wobec katalogu, błąd może należeć do katalogu, a nie do VPN.

Nie testuj problemów z tożsamością, wyłączając kontrole tożsamości. To zamienia błąd diagnostyczny w niediagnostyczny i pozostawia połączenie słabsze niż wcześniej.

Kontrola 4: co się dzieje po udanym logowaniu

Gdy IKE_AUTH się zakończy, negocjacja CHILD_SA decyduje, które selektory ruchu zostaną zainstalowane, i właśnie tam połączenie może się udać, a mimo to nic nie przepuszczać.

Świeżo działające logowanie często ujawnia problem z selektorem lub trasą, który wcześniej był ukryty za błędem uwierzytelniania. Jeśli tunel wstaje, a aplikacja nadal nie dociera do celu, patrz na wynegocjowane selektory i trasy, a nie znowu na tożsamość. Zmiana ustawień tożsamości w tym momencie celuje w niewłaściwy etap i zwykle psuje działające logowanie. Potwierdź za pomocą swanctl --list-sas, który pokazuje dzieci i ich selektory osobno od IKE SA.

Kontrola 5: co przekazać wsparciu

Oczyszczona os czasu i dokładne odrzucenie są warte więcej niż pełny eksport diagnostyczny, a eksport może zawierać klucze prywatne lub dane uwierzytelniające, którymi nie powinieneś się dzielić.

Zapisz czas ze strefą czasową, wersje klienta i bramy, metodę, ciąg tożsamości, który został podany, a nie hasło, oraz dokładny etap, który go odrzucił. dokumentacja konfiguracji IKEv2 strongSwan opisuje ustawienia tożsamości i EAP, które decydują o tych wynikach, i to jest źródło, które trzeba przeczytać przed zmianą pola. Następnie zmień jedną rzecz i ponownie przetestuj nowe połączenie, ponieważ sesja w pamięci podręcznej opowie ci o starej konfiguracji.