Pourquoi RADIUS voit une adresse IP au lieu du nom d’utilisateur VPN

strongSwan peut placer l’identité IKE dans RADIUS User-Name avant tout échange EAP. Décidez qui demande l’identité du compte, puis corrélez une tentative.

Un client Windows IKEv2 se connecte, et la requête RADIUS arrive avec une adresse là où devrait se trouver le nom du compte. Rien n’a encore échoué, et c’est justement ce qui perturbe : la passerelle signale l’identité que le client a présentée au niveau IKE. Le nom d’utilisateur attendu par votre backend peut provenir d’un échange EAP distinct qui n’a pas encore eu lieu. Décidez qui le demande avant de modifier le compte.

Deux identités voyagent dans une seule connexion

Deux noms peuvent apparaître dans une même connexion. L’identité IKE identifie le pair lors de la configuration du tunnel, et le greffon eap-radius la copie d’abord dans RADIUS User-Name. L’identité EAP est une autre valeur, utilisée pour authentifier l’utilisateur, et elle peut ne jamais être envoyée si personne ne la demande.

C’est pourquoi le journal RADIUS peut afficher une adresse alors que le compte existe et que le mot de passe est correct. On interroge le backend sur la mauvaise couche. L’attribut RADIUS n’est que le transport du nom choisi.

Demandez à la passerelle de solliciter une identité EAP

Une configuration prise en charge fait demander l’identité EAP par la passerelle avant de confier l’authentification à RADIUS. Dans la section d’authentification distante de la connexion, réglez la méthode sur eap-radius et demandez explicitement l’identité EAP. Le fragment ci-dessous appartient à un bloc de connexion existant, pas à un fichier séparé. Vérifiez la connexion et le backend de configuration avant de copier la syntaxe d’un autre déploiement.

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

Ainsi, le backend reçoit l’identité fournie par le client lors de l’échange EAP au lieu de l’adresse IKE. Rien d’autre ne change dans la connexion.

Ou laissez RADIUS lancer l’échange EAP

L’autre configuration place le premier mouvement du côté de RADIUS. Le greffon peut envoyer une indication EAP-Start au lieu d’attendre une réponse d’identité initiale, ce qui permet au serveur de piloter l’échange. C’est une configuration au niveau du greffon, elle touche donc toutes les connexions qui l’utilisent.

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

Choisissez une configuration avec l’exploitant RADIUS plutôt que d’activer les deux en espérant. Elles décrivent des flux de travail différents, et un serveur qui s’attend à initier ne gérera pas forcément une passerelle qui commence la conversation. La documentation du greffon décrit les deux, y compris l’identité portée par chaque étape.

Suivez une tentative dans les deux journaux

Corrélez une seule tentative dans les deux journaux. Observez l’identité IKE, puis si un échange EAP-Identity a lieu, puis le nom que reçoit l’étape d’authentification. Un backend qui rejette l’adresse avant l’échange EAP peut arrêter le processus avant que l’identité visée ne soit jamais visible.

journalctl -u strongswan -f

Conservez le format exact du nom d’utilisateur attendu par le système d’identité, préfixe de domaine compris. N’inventez jamais un compte à partir d’une valeur en forme d’adresse et ne désactivez jamais l’authentification pour satisfaire une règle de politique. Une identité EAP est un nom déclaré, et la méthode doit encore le prouver. Inscrivez le nom obtenu dans le dossier de test pour que la tentative suivante parte d’un état connu.

Si le flux corrigé atteint le bon compte et est encore rejeté, la preuve suivante est la méthode EAP et la politique du backend, pas l’identité. Répéter une réinitialisation de mot de passe ne peut pas réparer une valeur choisie à une couche de protocole antérieure.

Articles similaires