Por que o RADIUS vê um endereço IP em vez do nome de usuário VPN

O strongSwan pode colocar a identidade IKE no RADIUS User-Name antes de qualquer troca EAP. Decida quem solicita a identidade da conta e depois correlacione uma tentativa.

Um cliente Windows IKEv2 se conecta, e a solicitação RADIUS chega com um endereço onde deveria estar o nome da conta. Nada falhou ainda, e é justamente isso que confunde: o gateway informa a identidade que o cliente apresentou na camada IKE. O nome de usuário que seu backend quer pode vir de uma troca EAP separada que ainda não aconteceu. Decida quem o solicita antes de alterar a conta.

Duas identidades viajam em uma conexão

Dois nomes podem aparecer em uma conexão. A identidade IKE identifica o par durante a configuração do túnel, e o plugin eap-radius inicialmente a copia para RADIUS User-Name. A identidade EAP é um valor diferente, usado para autenticar o usuário, e pode nunca ser enviada se ninguém a solicitar.

Por isso o log do RADIUS pode mostrar um endereço enquanto a conta existe e a senha está correta. O backend está sendo questionado sobre a camada errada. O atributo RADIUS é apenas o transporte do nome escolhido.

Peça ao gateway para solicitar uma identidade EAP

Uma configuração suportada faz o gateway solicitar a identidade EAP antes de entregar a autenticação ao RADIUS. Na seção de autenticação remota da conexão, defina o método como eap-radius e solicite a identidade EAP explicitamente. O fragmento abaixo pertence a um bloco de conexão existente, não a um arquivo próprio. Confirme a conexão e o backend de configuração antes de copiar a sintaxe de outra implantação.

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

Com isso, o backend recebe a identidade que o cliente fornece na troca EAP em vez do endereço IKE. Nada mais na conexão muda.

Ou deixe o RADIUS iniciar a troca EAP

A outra configuração coloca o primeiro movimento do lado do RADIUS. O plugin pode enviar uma indicação EAP-Start em vez de esperar uma resposta de identidade inicial, o que permite ao servidor conduzir a troca. É configuração no nível do plugin, então afeta todas as conexões que o usam.

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

Escolha uma configuração com o operador do RADIUS em vez de ativar as duas e torcer. Elas descrevem fluxos de trabalho diferentes, e um servidor que espera iniciar não necessariamente lidará com um gateway que começa a conversa. A documentação do plugin descreve ambas, incluindo qual identidade cada etapa carrega.

Acompanhe uma tentativa nos dois logs

Correlacione uma única tentativa nos dois logs. Observe a identidade IKE, depois se ocorre uma troca EAP-Identity, e depois qual nome a etapa de autenticação recebe. Um backend que rejeita o endereço antes da troca EAP pode parar o processo antes que a identidade pretendida seja vista.

journalctl -u strongswan -f

Mantenha o formato exato do nome de usuário esperado pelo sistema de identidade, incluindo o prefixo de domínio. Nunca invente uma conta a partir de um valor em forma de endereço e nunca desative a autenticação para cumprir uma regra de política. Uma identidade EAP é um nome declarado, e o método ainda precisa prová-lo. Escreva o nome resultante no registro de teste para que a próxima tentativa comece de um estado conhecido.

Se o fluxo corrigido alcançar a conta correta e ainda for rejeitado, a próxima evidência é o método EAP e a política do backend, não a identidade. Repetir uma redefinição de senha não pode reparar um valor escolhido em uma camada de protocolo anterior.

Artigos relacionados