strongSwan EAP : l’identité IKE face au nom AAA attendu

Un client strongSwan EAP peut valider deux noms de serveur. remote.id couvre la passerelle IKE et local.aaa_id le serveur EAP ; ce ne sont pas les mêmes champs.

L’authentification EAP sur IKEv2 peut demander à un client de valider deux noms de serveur différents dans une même connexion. La passerelle qui termine IKE présente une identité, et le backend EAP qui termine l’échange TLS interne peut en présenter une autre. Dans strongSwan, ils vivent dans des blocs de configuration différents, et un nom placé dans le mauvais bloc produit un échec qui ressemble à un problème de certificat. C’est la lecture de la validation qui a échoué qui indique quel bloc modifier.

Une connexion, deux identités de serveur

La première identité appartient à l’échange IKE. Le client compose une adresse et attend que le pair prouve une identité précise, généralement le nom du certificat de la passerelle.

La seconde appartient à EAP. Avec PEAP ou TTLS, le client construit un tunnel TLS vers le serveur d’authentification à l’intérieur de l’IKE SA, et ce serveur interne présente son propre certificat. Quand le backend est un hôte distinct, son nom diffère de celui de la passerelle. Un client qui ne vérifie que le premier nom accepte ce que le second affirme. Et un client configuré avec un seul nom aux deux endroits échoue dès que les deux diffèrent réellement.

Les deux noms viennent de la configuration de l’opérateur, non du certificat qui fait disparaître l’erreur. Demander les détails du déploiement à l’opérateur est plus rapide que de deviner deux noms d’hôte.

Quel champ appartient à quelle couche

Dans swanctl, l’adresse et l’identité IKE sont des réglages distincts, et l’identité EAP en est un troisième.

L’adresse distante choisit où vont les paquets, et l’identité distante indique ce que le pair doit prouver. L’attente EAP s’écrit sous le bloc local, parce qu’elle décrit l’échange EAP de ce client et non le comportement IKE du pair. C’est précisément cet emplacement qui est mal lu. Le nom se trouve dans la configuration du client tout en décrivant un serveur, et c’est exactement pourquoi il semble mal placé.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Ce fragment n’est pas une connexion complète ; le matériel de confiance, les identifiants et les stratégies des connexions enfants doivent encore être présents. Le copier tel quel dans un fichier de travail remplacerait des réglages dont vous avez encore besoin.

Pourquoi aaa_id vit sous local

Le bloc local décrit ce que fait cette extrémité pendant l’authentification, y compris la méthode qu’elle utilisera et l’identité qu’elle attend de l’autre extrémité pour cette méthode. Rien n’y affirme que le serveur AAA tourne sur la même machine.

La valeur par défaut rend le piège plus tranchant. Quand aucune valeur explicite n’est définie, l’identité AAA attendue suit l’identité distante, si bien qu’un déploiement à un seul nom fonctionne et masque la distinction. Une valeur explicite ne compte que lorsque le déploiement EAP se termine réellement ailleurs. La fixer à un autre nom sans cette raison crée un échec que l’opérateur ne peut pas reproduire. Lisez le déploiement avant d’inventer un second nom.

Gardez la valeur identique à ce qu’affirme réellement le certificat du backend, y compris la forme du nom. Un point final ou un joker qui ne couvre pas l’hôte suffit à faire échouer la vérification.

Des interfaces qui ne peuvent pas exprimer la séparation

Un profil NetworkManager n’est pas la même interface de configuration que swanctl. Le greffon derrière expose un ensemble plus étroit de contrôles d’identité, et ceux qui existent dépendent de la version installée.

Cela compte quand le déploiement a réellement besoin de deux noms. Un champ étiqueté identité du serveur peut configurer une couche et pas l’autre, si bien qu’un profil peut sembler correct et échouer malgré tout à la vérification interne. Vérifiez ce que prend en charge le greffon installé avant de supposer que le profil peut exprimer cette disposition. S’il ne le peut pas, le choix revient à l’opérateur : un autre chemin de provisionnement, ou une conception corrigée de l’identité du serveur. Affaiblir PEAP ou accepter n’importe quel nom change la stratégie d’authentification au lieu de la corriger.

L’alternative n’est pas à inventer sur le client. Demandez la disposition prise en charge par écrit, puis conservez cette réponse avec le profil.

Distinguez une incohérence d’identité d’un certificat expiré

Une incohérence de nom et un certificat expiré sont des échecs différents, et le journal les distingue. Lisez le message avant de décider quel champ changer.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Définir l’identité AAA prévue ne renouvelle pas un certificat et n’établit pas la confiance dans son émetteur, et renouveler un certificat ne corrige pas un nom attendu erroné. Lisez quelle validation a échoué avant de modifier un autre champ d’identité. Rechargez ensuite la configuration et confirmez que la connexion chargée affiche la valeur définie, car un fichier modifié qui n’a jamais été chargé ne change rien. Notez les deux noms et leurs couches dans les notes de déploiement.

Articles similaires