eapol_test sur un VPN : l'échange RADIUS a-t-il besoin de la couche 2 ?

Demandez un port de commutateur de laboratoire pour exécuter eapol_test et vous avez probablement mal lu l'outil. Le pair et le client RADIUS vivent tous deux dans ce seul binaire, donc la seule conversation qui quitte la machine est l'échange RADIUS lui-même. Un tunnel routé entre l'hôte de test et le serveur d'authentification constitue toute l'exigence réseau. Le chemin physique 802.1X est autre chose qu'il vous faudra peut-être encore tester, et ce n'est pas celui-ci.

Pourquoi le nom pousse à chercher un port de commutateur

EAPOL est le format de trame qu'un supplicant et un commutateur utilisent sur un LAN, et l'outil emprunte le nom parce qu'il a grandi dans ce monde. Ce qui est livré est un programme de test qui porte la machine à états du pair et le client RADIUS dans un seul processus, donc les deux moitiés d'une conversation 802.1X ne se rencontrent jamais sur un câble. Le nom est de l'histoire, pas une exigence de topologie.

Les gens demandent encore le port parce que le programme repose sur le comportement d'un authentificateur, et cela sonne comme du matériel. Sa colle reproduit la machine à états de l'authentificateur, donc un test se termine sans aucun point d'accès dans la salle ; le binaire compilé lie le pair EAP de wpa_supplicant au client RADIUS de hostapd. Retirer le commutateur retire le saut EAPOL, pas la logique d'authentification. Ce qui reste est un échange client-serveur entre deux hôtes IP.

Suivez un échange RADIUS saut par saut

Suivez une seule tentative et le chemin est court. Le pair à l'intérieur de eapol_test produit une EAP-Response pour la méthode que vous avez configurée, et le client RADIUS du même processus la place dans une Access-Request, portant la charge utile dans des attributs EAP-Message à côté d'un Message-Authenticator. Ce datagramme est adressé au serveur sur le port UDP 1812 et quitte l'hôte comme n'importe quel autre paquet IP, et c'est là qu'intervient le tunnel. Le serveur l'évalue selon sa politique et ses modules de méthodes, puis répond par Access-Challenge, Access-Accept ou Access-Reject.

eapol_test -c peap-mschapv2.conf -a 198.51.100.20 -p 1812 \
  -s REPLACE_WITH_RADIUS_SECRET -t 30

Le binaire prend l'adresse du serveur, le port et le secret partagé sur la ligne de commande, et la méthode et les identifiants dans un bloc de configuration de style wpa_supplicant. Rien dans cet appel ne dépend d'une adjacence de couche 2 : -a est atteint par routage, et un VPN qui le route suffit. Si le tunnel abandonne le datagramme, le test échoue exactement comme face à un serveur injoignable sur un LAN plat.

Le binaire et la politique du serveur sont des listes différentes

Deux listes indépendantes décident si une méthode peut passer, et les confondre coûte une journée. La première liste est compilée dans le binaire : la configuration de compilation choisit quelles méthodes EAP existent, donc une compilation sans une méthode ne peut pas la négocier quoi que le serveur autorise. La seconde liste vit sur le serveur, où la politique dit lesquelles des méthodes prises en charge cette classe de clients peut utiliser. Un passage exige une intersection, et aucune liste ne peut combler un manque dans l'autre.

Vérifiez cette première liste avant d'accuser le serveur. Cherchez le nom de la méthode dans le binaire installé ou lisez la configuration de compilation dont il provient. Si la méthode est absente, recompilez plutôt que de modifier la politique RADIUS ; si elle est présente et que l'échange échoue encore, le problème s'est déplacé vers les identifiants, la politique ou la confiance dans le certificat.

Ce qu'un passage ne couvre toujours pas

Une exécution réussie prouve une méthode, pour un jeu d'identifiants, contre une politique RADIUS, sur un chemin réseau. Elle n'exerce ni la radio du point d'accès, ni le traitement EAPOL d'un commutateur, ni l'attribution de VLAN qui suit l'authentification, ni la façon dont un concentrateur VPN s'intègre au même serveur. Ces composants n'ont jamais été sur le chemin testé. Traitez le résultat comme une preuve bornée et dites quelle borne il couvre lorsque vous le rapportez.

L'enregistrement utile est ce que le serveur et le processus ont observé chacun : quelle méthode a été négociée, où l'échange s'est arrêté et ce que le serveur a journalisé. Gardez les secrets partagés et les clés privées hors de cet enregistrement.

Liste de contrôle avant de citer le résultat

Avant que quiconque traite la sortie comme une approbation, confirmez quatre choses. La compilation inclut la méthode testée, le point de terminaison RADIUS et le secret partagé appartiennent à l'environnement testé, la politique du serveur admet cette identité de test, et le chemin réseau est de la même classe que celui qu'utilisent les clients de production. Nommez ensuite ce que l'exécution n'a pas touché : point d'accès, commutateur, VLAN et intégration du concentrateur ont chacun besoin de leur propre ligne dans le plan de test.

Deux tests avec deux responsables valent mieux qu'une approbation ambiguë. L'exécution de eapol_test répond à la question de la méthode et du serveur ; le service d'accès répond à la question de l'application.