Por qué RADIUS ve una dirección IP en lugar del nombre de usuario VPN

strongSwan puede poner la identidad IKE en RADIUS User-Name antes de cualquier intercambio EAP. Decida quién pide la identidad de la cuenta y luego correlacione un intento.

Un cliente Windows IKEv2 se conecta y la solicitud RADIUS llega con una dirección donde debería estar el nombre de la cuenta. Todavía no ha fallado nada, y eso es lo confuso: la puerta de enlace informa de la identidad que el cliente presentó en la capa IKE. El nombre de usuario que quiere su backend puede venir de un intercambio EAP aparte que aún no ha ocurrido. Decida quién lo pide antes de cambiar la cuenta.

Dos identidades viajan en una conexión

En una conexión pueden aparecer dos nombres. La identidad IKE identifica al par durante la configuración del túnel, y el complemento eap-radius la copia inicialmente en RADIUS User-Name. La identidad EAP es un valor distinto, usado para autenticar al usuario, y puede que nunca se envíe si nadie la pide.

Por eso el registro RADIUS puede mostrar una dirección mientras la cuenta existe y la contraseña es correcta. Se está preguntando al backend por la capa equivocada. El atributo RADIUS es solo el transporte del nombre que se haya elegido.

Pida a la puerta de enlace que solicite una identidad EAP

Una disposición admitida hace que la puerta de enlace solicite la identidad EAP antes de entregar la autenticación a RADIUS. En la sección de autenticación remota de la conexión, ponga el método en eap-radius y solicite la identidad EAP de forma explícita. El fragmento de abajo pertenece dentro de un bloque de conexión existente, no en un archivo propio. Confirme la conexión y el backend de configuración antes de copiar la sintaxis de otro despliegue.

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

Con eso, el backend recibe la identidad que el cliente proporciona en el intercambio EAP en lugar de la dirección IKE. Nada más de la conexión cambia.

O deje que RADIUS inicie el intercambio EAP

La otra disposición pone el primer movimiento del lado de RADIUS. El complemento puede enviar una indicación EAP-Start en lugar de esperar una respuesta de identidad inicial, lo que permite que el servidor dirija el intercambio. Es configuración a nivel de complemento, así que afecta a todas las conexiones que lo usan.

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

Elija una disposición con el operador de RADIUS en lugar de activar las dos y esperar. Describen flujos de trabajo distintos, y un servidor que espera iniciar no necesariamente manejará una puerta de enlace que empieza la conversación. La documentación del complemento describe ambas, incluida qué identidad lleva cada paso.

Siga un intento en ambos registros

Correlacione un solo intento en ambos registros. Observe la identidad IKE, luego si se produce un intercambio EAP-Identity, y después qué nombre recibe el paso de autenticación. Un backend que rechaza la dirección antes del intercambio EAP puede detener el proceso antes de que se vea nunca la identidad que pretende.

journalctl -u strongswan -f

Mantenga el formato exacto del nombre de usuario que espera el sistema de identidad, incluido el prefijo de dominio. Nunca invente una cuenta a partir de un valor con forma de dirección y nunca desactive la autenticación para cumplir una regla de política. Una identidad EAP es un nombre declarado, y el método todavía tiene que demostrarlo. Escriba el nombre resultante en el registro de pruebas para que el siguiente intento empiece desde un estado conocido.

Si el flujo corregido llega a la cuenta correcta y aún se rechaza, la siguiente evidencia es el método EAP y la política del backend, no la identidad. Repetir un restablecimiento de contraseña no puede reparar un valor elegido en una capa de protocolo anterior.

Artículos relacionados