Por que RADIUS ve un enderezo IP en lugar do nome de usuario VPN

strongSwan pode pór a identidade IKE en RADIUS User-Name antes de calquera intercambio EAP. Decida quen pide a identidade da conta e despois correlacione un intento.

Un cliente Windows IKEv2 conéctase e a solicitude RADIUS chega cun enderezo onde debería estar o nome da conta. Aínda non fallou nada, e iso é o confuso: a pasarela informa de a identidade que o cliente presentou na capa IKE. O nome de usuario que quere o seu backend pode vir dun intercambio EAP separado que aínda non ocorreu. Decida quen o pide antes de cambiar a conta.

Dúas identidades viaxan nunha conexión

Nunha conexión poden aparecer dous nomes. A identidade IKE identifica o par durante a configuración do túnel, e o complemento eap-radius cópiaa inicialmente en RADIUS User-Name. A identidade EAP é un valor distinto, usado para autenticar o usuario, e pode que nunca se envíe se ninguén a pide.

Por iso o rexistro RADIUS pode mostrar un enderezo mentres a conta existe e o contrasinal é correcto. Estáselle preguntando ao backend pola capa equivocada. O atributo RADIUS só é o transporte do nome que se escollese.

Pida á pasarela que solicite unha identidade EAP

Unha disposición admitida fai que a pasarela solicite a identidade EAP antes de entregar a autenticación a RADIUS. Na sección de autenticación remota da conexión, poña o método en eap-radius e solicite a identidade EAP de forma explícita. O fragmento de abaixo pertence dentro dun bloque de conexión existente, non nun ficheiro propio. Confirme a conexión e o backend de configuración antes de copiar a sintaxe doutro despregamento.

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

Con iso, o backend recibe a identidade que o cliente fornece no intercambio EAP en lugar do enderezo IKE. Nada máis da conexión cambia.

Ou deixe que RADIUS inicie o intercambio EAP

A outra disposición pon o primeiro movemento do lado de RADIUS. O complemento pode enviar unha indicación EAP-Start en lugar de agardar unha resposta de identidade inicial, o que permite que o servidor dirixa o intercambio. É configuración a nivel de complemento, así que afecta a todas as conexións que o usan.

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

Escolla unha disposición co operador de RADIUS en lugar de activar as dúas e esperar. Describen fluxos de traballo distintos, e un servidor que espera iniciar non necesariamente xestionará unha pasarela que comeza a conversa. A documentación do complemento describe ambas, incluída que identidade leva cada paso.

Siga un intento en ambos os rexistros

Correlacione un único intento en ambos os rexistros. Observe a identidade IKE, despois se se produce un intercambio EAP-Identity, e despois que nome recibe o paso de autenticación. Un backend que rexeita o enderezo antes do intercambio EAP pode deter o proceso antes de que se vexa nunca a identidade que pretende.

journalctl -u strongswan -f

Manteña o formato exacto do nome de usuario que espera o sistema de identidade, incluído o prefixo de dominio. Nunca invente unha conta a partir dun valor con forma de enderezo nin desactive nunca a autenticación para cumprir unha regra de política. Unha identidade EAP é un nome declarado, e o método aínda ten que demostralo. Escriba o nome resultante no rexistro de probas para que o seguinte intento comece desde un estado coñecido.

Se o fluxo corrixido chega á conta correcta e aínda se rexeita, a seguinte evidencia é o método EAP e a política do backend, non a identidade. Repetir un restablecemento de contrasinal non pode reparar un valor escollido nunha capa de protocolo anterior.

Artigos relacionados