Klient Windows IKEv2 łączy się, a żądanie RADIUS przychodzi z adresem tam, gdzie powinna być nazwa konta. Nic jeszcze nie zawiodło i właśnie to dezorientuje: brama zgłasza tożsamość, którą klient przedstawił na warstwie IKE. Nazwa użytkownika, której chce twój backend, może pochodzić z osobnej wymiany EAP, która jeszcze nie nastąpiła. Zdecyduj, kto o nią prosi, zanim zmienisz konto.

Dwie tożsamości podróżują w jednym połączeniu

W jednym połączeniu mogą pojawić się dwie nazwy. Tożsamość IKE identyfikuje partnera podczas konfiguracji tunelu, a wtyczka eap-radius początkowo kopiuje ją do RADIUS User-Name. Tożsamość EAP to inna wartość, używana do uwierzytelniania użytkownika, i może nigdy nie zostać wysłana, jeśli nikt o nią nie poprosi.

Dlatego dziennik RADIUS może pokazywać adres, choć konto istnieje, a hasło jest poprawne. Backend jest pytany o niewłaściwą warstwę. Atrybut RADIUS jest tylko transportem dla wybranej nazwy.

Poproś bramę o zażądanie tożsamości EAP

Jedno obsługiwane ustawienie pozwala bramie zażądać tożsamości EAP przed przekazaniem uwierzytelniania do RADIUS. W sekcji uwierzytelniania zdalnego połączenia ustaw metodę na eap-radius i wyraźnie zażądaj tożsamości EAP. Poniższy fragment należy do istniejącego bloku połączenia, a nie do osobnego pliku. Potwierdź połączenie i backend konfiguracji, zanim skopiujesz składnię z innego wdrożenia.

remote {
    auth = eap-radius
    eap_id = %any
}

Dzięki temu backend otrzymuje tożsamość, którą klient podaje w wymianie EAP, zamiast adresu IKE. Nic innego w połączeniu się nie zmienia.

Albo pozwól RADIUS rozpocząć wymianę EAP

Drugie ustawienie zostawia pierwszy ruch po stronie RADIUS. Wtyczka może wysłać sygnał EAP-Start zamiast czekać na początkową odpowiedź tożsamości, co pozwala serwerowi prowadzić wymianę. To konfiguracja na poziomie wtyczki, więc wpływa na każde połączenie, które jej używa.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Wybierz jedno ustawienie razem z operatorem RADIUS, zamiast włączać oba i mieć nadzieję. Opisują różne przepływy pracy, a serwer, który oczekuje, że zacznie, niekoniecznie poradzi sobie z bramą rozpoczynającą rozmowę. Dokumentacja wtyczki opisuje oba, w tym tożsamość przenoszoną przez każdy krok.

Prześledź jedną próbę w obu dziennikach

Skoreluj jedną próbę w obu dziennikach. Obserwuj tożsamość IKE, potem czy następuje wymiana EAP-Identity, a potem jaką nazwę otrzymuje krok uwierzytelniania. Backend, który odrzuca adres przed wymianą EAP, może zatrzymać proces, zanim zamierzona tożsamość w ogóle się pojawi.

journalctl -u strongswan -f

Zachowaj dokładny format nazwy użytkownika oczekiwany przez system tożsamości, wraz z prefiksem domeny. Nigdy nie wymyślaj konta z wartości w kształcie adresu i nigdy nie wyłączaj uwierzytelniania, aby spełnić regułę polityki. Tożsamość EAP to zadeklarowana nazwa, a metoda nadal musi ją udowodnić. Zapisz wynikową nazwę w rekordzie testowym, aby następna próba zaczęła się od znanego stanu.

Jeśli poprawiony przepływ dociera do właściwego konta i nadal jest odrzucany, kolejnym dowodem jest metoda EAP i polityka backendu, a nie tożsamość. Powtarzanie resetu hasła nie naprawi wartości wybranej na wcześniejszej warstwie protokołu.

Powiązane artykuły