Klient Windows IKEv2 se připojí a požadavek RADIUS dorazí s adresou tam, kde má být jméno účtu. Zatím nic neselhalo, a právě to mate: brána hlásí identitu, kterou klient předložil na vrstvě IKE. Uživatelské jméno, které váš backend chce, může pocházet ze samostatné výměny EAP, která ještě neproběhla. Rozhodněte, kdo o něj požádá, než účet změníte.

Dvě identity cestují v jednom spojení

V jednom spojení se mohou objevit dvě jména. Identita IKE identifikuje protějšek při nastavování tunelu a plugin eap-radius ji nejprve zkopíruje do RADIUS User-Name. Identita EAP je jiná hodnota, používá se k ověření uživatele, a pokud ji nikdo nevyžádá, nemusí být nikdy odeslána.

Proto může protokol RADIUS zobrazovat adresu, i když účet existuje a heslo je správné. Backend se ptá na špatnou vrstvu. Atribut RADIUS je pouze přenosem pro zvolené jméno.

Požádejte bránu, aby si vyžádala identitu EAP

Jedno podporované uspořádání nechává bránu vyžádat identitu EAP, než předá ověřování protokolu RADIUS. V části pro vzdálené ověřování spojení nastavte metodu na eap-radius a výslovně si vyžádejte identitu EAP. Následující fragment patří dovnitř existujícího bloku spojení, ne do vlastního souboru. Potvrďte spojení a konfigurační backend, než zkopírujete syntaxi z jiného nasazení.

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

S tím backend dostane identitu, kterou klient poskytuje ve výměně EAP, místo adresy IKE. Nic jiného na spojení se nemění.

Nebo nechte RADIUS zahájit výměnu EAP

Druhé uspořádání nechává první tah na straně RADIUS. Plugin může odeslat indikaci EAP-Start místo čekání na počáteční odpověď s identitou, což serveru umožní výměnu řídit. Jde o konfiguraci na úrovni pluginu, takže ovlivňuje každé spojení, které plugin používá.

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

Vyberte jedno uspořádání s operátorem RADIUS, místo abyste povolili obojí a doufali. Popisují různé pracovní postupy a server, který očekává, že začne, si nemusí poradit s bránou, která zahajuje konverzaci. Dokumentace pluginu popisuje obojí, včetně toho, kterou identitu nese každý krok.

Sledujte jeden pokus v obou protokolech

Porovnejte jeden pokus v obou protokolech. Sledujte identitu IKE, pak zda proběhne výměna EAP-Identity, a pak jaké jméno obdrží krok ověřování. Backend, který adresu odmítne před výměnou EAP, může proces zastavit dřív, než se zamýšlená identita vůbec objeví.

journalctl -u strongswan -f

Zachovejte přesný formát uživatelského jména, který systém identit očekává, včetně prefixu domény. Nikdy nevymýšlejte účet z hodnoty ve tvaru adresy a nikdy nevypínejte ověřování, abyste splnili pravidlo zásad. Identita EAP je tvrzené jméno a metoda ho stále musí prokázat. Výsledné jméno zapište do testovacího záznamu, aby další pokus začal ze známého stavu.

Pokud opravený tok dosáhne správného účtu a je stále odmítán, dalším důkazem je metoda EAP a zásady backendu, ne identita. Opakované resetování hesla nemůže opravit hodnotu zvolenou na dřívější vrstvě protokolu.

Související články