Perché RADIUS vede un indirizzo IP invece del nome utente VPN

strongSwan può inserire l’identità IKE in RADIUS User-Name prima di qualsiasi scambio EAP. Decidete chi richiede l’identità dell’account, poi correlate un tentativo.

Un client Windows IKEv2 si connette e la richiesta RADIUS arriva con un indirizzo dove dovrebbe esserci il nome dell’account. Non è ancora fallito nulla, ed è proprio questo a confondere: il gateway segnala l’identità che il client ha presentato al livello IKE. Il nome utente che il vostro backend vuole può provenire da uno scambio EAP separato che non è ancora avvenuto. Decidete chi lo richiede prima di modificare l’account.

Due identità viaggiano in una sola connessione

In una connessione possono comparire due nomi. L’identità IKE identifica il peer durante la configurazione del tunnel, e il plugin eap-radius la copia inizialmente in RADIUS User-Name. L’identità EAP è un valore diverso, usato per autenticare l’utente, e potrebbe non essere mai inviata se nessuno la richiede.

Per questo il registro RADIUS può mostrare un indirizzo mentre l’account esiste e la password è corretta. Si sta chiedendo al backend il livello sbagliato. L’attributo RADIUS è solo il trasporto per il nome che è stato scelto.

Chiedete al gateway di richiedere un’identità EAP

Una configurazione supportata fa sì che il gateway richieda l’identità EAP prima di consegnare l’autenticazione a RADIUS. Nella sezione di autenticazione remota della connessione, impostate il metodo su eap-radius e richiedete esplicitamente l’identità EAP. Il frammento sotto appartiene dentro un blocco di connessione esistente, non in un file a sé. Verificate la connessione e il backend di configurazione prima di copiare la sintassi da un’altra distribuzione.

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

Con questo, il backend riceve l’identità che il client fornisce nello scambio EAP invece dell’indirizzo IKE. Nient’altro della connessione cambia.

Oppure lasciate che RADIUS avvii lo scambio EAP

L’altra configurazione mette la prima mossa dalla parte di RADIUS. Il plugin può inviare un’indicazione EAP-Start invece di attendere una risposta di identità iniziale, il che consente al server di guidare lo scambio. È configurazione a livello di plugin, quindi influisce su ogni connessione che lo usa.

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

Scegliete una configurazione con l’operatore RADIUS invece di abilitarle entrambe e sperare. Descrivono flussi di lavoro diversi, e un server che si aspetta di iniziare non gestirà necessariamente un gateway che apre la conversazione. La documentazione del plugin descrive entrambe, inclusa quale identità porta ogni passo.

Seguite un tentativo in entrambi i registri

Correlate un singolo tentativo in entrambi i registri. Osservate l’identità IKE, poi se avviene uno scambio EAP-Identity, poi quale nome riceve il passo di autenticazione. Un backend che rifiuta l’indirizzo prima dello scambio EAP può fermare il processo prima che l’identità prevista venga mai vista.

journalctl -u strongswan -f

Mantenete il formato esatto del nome utente atteso dal sistema di identità, incluso il prefisso di dominio. Non inventate mai un account da un valore a forma di indirizzo e non disattivate mai l’autenticazione per soddisfare una regola di policy. Un’identità EAP è un nome dichiarato, e il metodo deve comunque dimostrarlo. Scrivete il nome risultante nel record di test così che il tentativo successivo parta da uno stato noto.

Se il flusso corretto raggiunge l’account giusto ed è ancora rifiutato, la prova successiva è il metodo EAP e la policy del backend, non l’identità. Ripetere un ripristino della password non può riparare un valore scelto a un livello di protocollo precedente.

Articoli correlati