EAP via une passerelle VPN : qui termine la méthode

Les tickets de support décrivent un échec de connexion VPN et une politique RADIUS qui exige une méthode plus forte comme s'il s'agissait du même problème, et ce n'est pas le cas. La passerelle accepte un identifiant et le transmet, ou bien elle porte une conversation EAP entre le client et le serveur d'authentification. Ce qui se produit décide si un changement côté serveur peut corriger quoi que ce soit. Lisez l'échange avant de modifier le groupe de serveurs.

Deux chemins d'authentification qui se ressemblent dans un journal

Dans le premier chemin, la passerelle VPN collecte un nom d'utilisateur et un mot de passe et envoie une RADIUS Access-Request avec un attribut de mot de passe. Le serveur d'authentification la compare à son magasin et répond acceptation ou rejet. Le client n'exécute jamais de méthode EAP, car rien ne le lui a demandé.

Dans le second chemin, le client et le serveur d'authentification exécutent la méthode EAP de bout en bout, et la passerelle transmet les attributs EAP-Message entre eux. La passerelle termine toujours la conversation RADIUS externe, mais la logique de la méthode réside aux deux extrémités.

Les deux chemins produisent une ligne de journal indiquant que l'authentification a échoué. Seul le second peut dépendre de la méthode EAP préférée du serveur, et seul le premier de la façon dont la passerelle lit le mot de passe. Les traiter comme interchangeables, c'est ainsi que les équipes passent une journée à changer des groupes de serveurs pour un client qui n'allait jamais parler PEAP.

Où la méthode s'exécute réellement

RFC 3579 définit le dispositif de transit : le NAS porte les paquets EAP dans des attributs RADIUS et n'a pas besoin de code spécifique à chaque type EAP. C'est pourquoi une passerelle peut prendre en charge PEAP et EAP-TLS sans implémenter ni l'un ni l'autre.

Une passerelle qui soumet un mot de passe ne transporte pas PEAP, même si le backend accepterait PEAP d'un autre client. Activer PEAP dans la politique du serveur n'ajoute pas de méthode à un client qui n'en a jamais proposé.

Les paramètres d'authentification PPP appartiennent au service PPP. Ils ne reconfiguent pas silencieusement chaque chemin IPsec ou XAuth ancien qui utilise le même serveur AAA, donc un changement qui fonctionne pour un type d'accès peut laisser l'autre intact.

Ce que le NAS doit prendre en charge

Le transit déplace l'exigence du code de méthode vers la prise en charge du transport. La passerelle doit pouvoir porter EAP sur son protocole VPN, et le client RADIUS qui y tourne doit pouvoir envoyer et recevoir des attributs EAP-Message des tailles concernées.

Pour IKEv2, EAP fait partie d'un flux d'authentification défini, et les contrôles d'identité et de confiance du serveur viennent de ce flux. Une étiquette PEAP empruntée à un déploiement 802.1X ne se transfère pas automatiquement, car la négociation autour d'elle diffère.

Le côté client a aussi des exigences. Il doit être configuré pour la méthode, faire confiance au certificat serveur que la méthode présente et disposer d'identifiants que la méthode peut utiliser. Une méthode à certificat sans certificat client échoue avant que RADIUS ne voie quoi que ce soit, ce qui est un problème de provisionnement et non de politique serveur.

Lisez une tentative avant de changer la politique

Capturez une seule tentative approuvée sur la passerelle et sur le serveur d'authentification. Cherchez des attributs EAP-Message dans la requête RADIUS. Leur présence indique que le chemin de transit est utilisé ; leur absence oriente vers un échange d'identifiants.

Sur une passerelle Linux, une capture sur le port RADIUS montre quels attributs sont sur le fil :

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Comparez ensuite le point de rejet. Un échec sur la passerelle avant tout paquet RADIUS signifie que le client et la passerelle ne s'accordaient pas sur la méthode. Un rejet RADIUS portant des attributs EAP signifie que les extrémités ont exécuté la méthode et que l'une d'elles a refusé le résultat.

Planifiez la migration comme un seul changement de bout en bout

Changer de méthode signifie changer ensemble la configuration du client, la prise en charge du transport sur la passerelle, la politique de méthode du serveur et le magasin d'identifiants. Faites-le dans cet ordre et gardez un chemin fonctionnel jusqu'à ce que le nouveau soit prouvé. Un changement côté serveur seul est une conjecture, et il casse généralement les clients qui fonctionnaient. Préparez le changement sur une identité de test avant de toucher au groupe.

Notez la combinaison qui fonctionne : protocole VPN, transport EAP, méthode du pair, méthode du serveur, type d'identifiant et contrôle d'identité du serveur.

Gardez l'AAA de connexion administrative séparé de l'authentification VPN, sauf si la tâche inclut explicitement les deux. Un changement destiné à l'accès distant ne doit pas vous retirer la capacité de gérer l'équipement qui le termine.