OUAHAB Karim ENSEEIHT - INPT Karim.Ouahab@etu.enseeiht.fr Rapport de Stage Comité Réseau des Universités http://www.cru.fr Monitoring du réseau eduroam français http://www.eduroam.fr 1
Sommaire Introduction 1 ) Présentation... 3 2 ) Sujet... 4 I Présentation du réseau 1 ) Présentation de RADIUS et architecture du réseau... 5 2 ) Déroulement d'une connexion... 7 3 ) Le protocole 802.1X... 9 II Démarche adoptée 1 ) Problème (cahier des charges)... 10 2 ) Propositions des autres pays membres... 11 3 ) Choix de conception... 13 III Mise en oeuvre 1 ) Le programme eapol_test... 15 2 ) Le script rad_eap_test... 17 IV Exploitation 1 ) La page web de surveillance... 20 2 ) Intégration au logiciel Nagios... 21 3 ) Mise en place de la carte dynamique... 24 Conclusion... 28 2
Introduction Ce stage se déroule au CRU (Comité Réseau des Universités) à l'université de Rennes1, dans le cadre du stage de fin de première année à l'enseeiht (département informatique et mathématiques appliqués). Le CRU est une structure de conseil et de réflexion pour la Direction de la Recherche du MJENR, la Conférence des Présidents d'universités et les établissements d'enseignement supérieur. [...] Avec l'appui de la cellule technique il soutient et organise le développement de services applicatifs utiles à la communauté universitaire. Enfin, il représente la communauté universitaire auprès des réseaux européens de l'enseignement supérieur et de la recherche. Ce stage s'effectue sous la tutelle de CLAVELEIRA Christian et CARPIER Vincent, tous deux administrateurs système et réseau et chefs de projets au CRU. L'objectif est de répondre au sujet proposé tout en respectant le cahier des charges, mais également, dans une perspective plus large, de s'intégrer aux équipes du CRU, de développer le travail en équipe, les connaissances personnelles, et de découvrir le monde de l'entreprise. 1 ) Présentation Le service eduroam s'inscrit dans le développement du projet ARREDU ( http://arredu.cru.fr ), qui est un projet français visant à mettre en place un réseau d'authentification entre des établissements agrées RENATER (Réseau National de télécommunications pour la Technologie l Enseignement et la Recherche, qui fédére les infrastructures de télécommunication pour la recherche et l éducation: http://www.renater.fr) dans lequel chaque personnel d'établissement participant pourra se connecter à partir de n'importe quel établissement du projet avec ses login et mot de passe habituels, ce réseau est basé sur le protocole RADIUS qui sera décris ci après. 3
Le projet eduroam (http://www.eduroam.org), est un projet européen dont l'objectif est de permettre à tout personnel d'établissement participant au projet (universités, écoles d'ingénieurs...), de toujours pouvoir se connecter à internet lors d'un déplacement chez un autre établissement membre d'eduroam, ce avec son log-in/mot de passe usuel. Typiquement, un chercheur en déplacement pourra donc se connecter à internet et aux éventuels services proposés par l'établissement qui l'accueil (tous ne propose pas nécessairement les mêmes services), par exemple à partir d'un point d'accès sans fil (Wi-Fi) de l'université qui l'accueille. eduroam peut être vu comme l'extension européenne d'arredu. eduroam se propose de développer cela en minimisant les coûts et les démarches de déploiement, c'est à dire en simplifiant au maximum la coordination des universités, tout en assurant un service sécurisé de qualité. De nombreux pays sont d' ores et déjà membres du projet, qui maintenant s'étend au delà de l'europe (à l'heure actuelle 26 pays européens ainsi que Taïwan et l'australie), et donc dans un futur proche de nombreux établissements de l'enseignement supérieur proposeront le service offert par eduroam. 2 ) Sujet Pour assurer le service, il faut être certain que les éléments actifs de l'infrastructure fonctionnent, et en cas de problème en un point du réseau, on doit être capable d'identifier et de localiser le problème au plus vite, mais aussi de contacter les personnes concernées. Ainsi le sujet du stage est de développer un «monitoring» du réseau eduroam français c'est à dire une surveillance en temps réel de l'état de ce dernier. En effet le CRU gère le serveur principal du réseau eduroam français, serveur par lequel transite les demandes de connexions d'un membre étranger d'eduroam en visite en France mais aussi les connexions entre les établissements français. 4
I - Présentation du réseau 1 ) Présentation de RADIUS et architecture Tout d'abord, il est nécessaire d'expliquer ce qu'est un serveur RADIUS, élément crucial de l'architecture qui va ici être présentée. Le protocole RADIUS (Remote Authentication Dial-In User Service), est un protocole d'authentification standard, défini par un certain nombre de RFC (Request For Comment). Le fonctionnement de RADIUS est basé sur un système client/serveur chargé de définir les accès d'utilisateurs distants à un réseau. Il s'agit du protocole de prédilection des fournisseurs d'accès à Internet car il est relativement standard et propose des fonctionnalités de comptabilité («accounting») permettant aux FAI de facturer précisément leurs clients. Le service RADIUS repose principalement sur un serveur (le serveur RADIUS), relié à une base d'identification (base de données, annuaire LDAP, etc.) et un client RADIUS, appelé NAS (Network Access Server), faisant office d'intermédiaire entre l'utilisateur final et le serveur. L'ensemble des transactions entre le client RADIUS et le serveur RADIUS est chiffrée et authentifiée grâce à un secret partagé. Il est à noter que le serveur RADIUS peut faire office de proxy, c'est-à-dire transmettre les requêtes du client à d'autres serveurs RADIUS: ce principe est largement utilisé dans le réseau eduroam, comme nous allons le voir maintenant. Enfin, une notion importante du protocole RADIUS est le realm, qui est utilisé pour transmettre les requêtes à un autre serveur RADIUS (le realm est un champ qui permet de savoir vers quel serveur RADIUS la requête doit être transmise), dans le cadre d'eduroam, le realm d'un serveur RADIUS d'un établissement correspond à son nom de domaine. Chaque établissement membre du projet propose des bornes d'accès pour les visiteurs en déplacement: notamment des bornes Wi-Fi et des points d'accès ethernet. De plus l'établissement dispose d'un serveur RADIUS auquel sont connectées toutes ces bornes d'accès ainsi qu'une base de données contenant toutes les informations relatives aux membres de l'établissement. 5
Chaque pays possède un serveur proxy national (là encore de type RADIUS) auquel sont connectés tous les serveurs radius des établissements de ce pays membres d'eduroam (dans le cas de la France ce serveur est au coeur du réseau RENATER et est localisé à Rennes, mais possède également un backup au CRI Strasbourg). Enfin, un serveur RADIUS principal servant également de proxy national, au TLD Top Level) du réseau, situé aux Pays Bas, sur lequel tous les serveurs RADIUS nationaux sont connectés, établi le lien entre les pays. Voici le schéma du réseau national français ARREDU connecté à eduroam: 6
2 ) Déroulement d'une connexion Supposons qu'un membre nommé Dupont de l'université de Rennes1, membre d'eduroam, se déplace à l'université de Londres, également membre d'eduroam, celuici désire se connecter _ depuis Londres _ à Internet et aux services proposé par l'université de Londres. Il se place près d'une borne Wi-Fi avec son ordinateur portable et se connecte grâce à son login et mot de passe habituels. Voici, dans les grandes lignes, le déroulement de la connexion. L'utilisateur tente de se connecter avec un login du type Dupont@univ-rennes1.fr, le serveur RADIUS de l'université de Londres ne reconnaît pas le realm qui est le nom de domaine univ-rennes1.fr, et renvoie donc la requête de connexion au serveur RADIUS national qui lui ne reconnaît pas le domaine.fr, il transmet donc à son tour la requête au serveur européen, qui lui reconnaît le domaine.fr et transmet la requête au serveur national français qui connaît à son tour le domaine univ-rennes1: l'université de Rennes1 reçoit la requête, consulte sa base de données et authentifie l'utilisateur Dupont avec son mot de passe: la demande est acceptée et la réponse du serveur RADIUS de Rennes1 effectue donc le chemin inverse. Voici la schématisation des communications RADIUS : 7
3 ) Le protocole 802.1X Le protocole 802.1X est un standard mis au point par l'ieee (Institute of Electrical and Electronics Engineers: http://www.ieee.org/). Son but est d'autoriser l'accès physique à un réseau local après authentification depuis un réseau filaire ou sans fil. Trois acteurs principaux interviennent dans ce mécanisme : Le système à authentifier (client) Le point d'accès au réseau local (commutateur, borne Wi-Fi etc.) Le serveur d'authentification Tant qu'il n'est pas authentifié, le client ne peut pas avoir accès au réseau, seuls les échanges liés au processus d'authentification sont relayés vers le serveur d'authentification par le point d'accès. Une fois authentifié, le point d'accès laisse passer le trafic lié au client (et autorise par exemple la connexion à internet). Le protocole 802.1X est un élément clef qu'il faut maîtriser dans le cadre d'une recherche de solution au sujet posé. Voici un schéma du protocole 802.1X qui agit comme un interrupteur lors de l'authentification: 8
II Démarche adoptée 1 ) Problème (cahier des charges) Il s'agit donc ici de proposer une méthode efficace et sûre de surveillance de ce réseau, tout en limitant les coûts et les manoeuvres de déploiement. Un utilisateur du service eduroam doit notamment pouvoir vérifier en temps réel que le service est disponible ou non dans l'établissement où il souhaite se déplacer, ce via une interface web ergonomique et intuitive. De plus les administrateurs du réseau doivent pouvoir vérifier l'état des connexions à tout moment, qu'il s'agisse des communications entre les serveurs RADIUS ou encore la transmission des données d'authentification à travers le réseau, et en cas de problème, le système de surveillance doit être à même de localiser la panne (dans la mesure du possible bien sûr) et de contacter les personnes concernées afin de remédier au problème au plus vite. Les administrateurs devront pouvoir accéder à une page web sur laquelle ils trouveront toutes les informations nécessaires à la surveillance, cette page devra être mise à jour régulièrement et être, comme toute interface, la plus agréable possible. Une certaine autonomie est demandée au monitoring: ainsi, lorsqu'un problème est détecté sur le réseau, le système doit prendre une décision adaptée qui peut être l'envoi d'un mail à un administrateur en particulier, ou encore l'envoi d'un sms. 9
2 ) Propositions des autres pays membres D'autres pays membres du projet eduroam se sont déjà intéressés au problème du monitoring au niveau national. Divers moyens existent pour partager le travail de chacun, notamment les ressources de types «wiki», les listes de diffusion et les forums. C'est au travers des sites communautaires du projet eduroam que l'on peut glaner des informations sur les solutions adoptées par un pays, les problèmes rencontrés, ainsi que de nombreuses autres informations intéressantes. Il a donc logiquement été décidé dans un premier temps de s'intéresser au travail effectué par les autres pays dans le cadre du monitoring de leurs réseaux: quelles solutions ont été adoptées? Pourquoi? Fin 2005, les grecs présentent lors d'une conférence à Athènes un monitoring basé sur le logiciel de surveillance Nagios, la solution choisie est de déployer des sondes, machines effectuant des mesures et des tests sur le réseau, dont les résultats seront collectés au niveau national par une machine dédiée. Ces résultats seront interprétés et utilisés par Nagios qui proposera notamment un monitoring en ligne et un système d'alertes. L'objectif est de proposer une méthode précise et modulaire qui minimise les coûts de déploiement. Cependant cette approche nous paraît trop frontale dans le sens où nous désirons éviter tout déploiement supplémentaire au niveau des établissements membres du projet et procéder à un monitoring uniquement grâce à la «racine» du réseau (ce qui est possible dans le cadre de eduroam en France grâce aux comptes de tests comme nous le verrons plus loin). La plupart des autres pays qui ont publié des informations sur le développement du monitoring ont adoptée une même approche du problème (l'italie par exemple). L'Espagne et le Portugal ont quant à eux mis en place un monitoring qui ne teste que les serveurs RADIUS de leurs réseaux nationaux respectifs (aucun test du fonctionnement global du réseau, mais ils projettent cependant de mettre cela en place assez rapidement) Seul le Royaume-Uni fait exception: le monitoring est intégré dans le cas de UKERNA (United Kingdom Education and Research Networking Association) de façon beaucoup plus complexe (une conférence avait eut lieu à ce sujet), les explications du déploiement ne seront donc pas ici détaillées puisqu'il faut au 10
préalable étudier le réseau dans sa globalité. Leur approche, qui semble tout à fait convenable, n'a donc pas été retenue pour analyses puisqu'il ne s'agit en aucun cas pour nous de remettre en cause le déploiement du réseau national. (Pour de plus amples informations sur le monitoring de UKERNA, veuillez vous reporter à la présentation suivante: http://www.terena.nl/events/tnc2006/core/getfile.php?file_id=1129) On peut cependant noter un point commun à l'ensemble des méthodes adoptées pour le monitoring: l'utilisation systématique du logiciel de monitoring Nagios (qui remplace NetSaint), très apprécié pour ses nombreuses fonctionnalités, sa très bonne ergonomie et son installation relativement simple. Ce point nous suggère de nous intéresser à Nagios afin de déterminer si son utilisation pourrait être bénéfique dans le cadre du projet. (Nagios est un projet open source : http://www.nagios.org) Attention, certains documents analysés sont relativement anciens et les remarques faites à leur sujet peuvent êtres obsolètes au moment où vous lirez ces lignes. 3 ) Choix de conception Dans la surveillance du réseau, deux aspects distincts se dégagent: tout d 'abord la surveillance des communications entre les serveurs RADIUS du pays: c'est à dire entre le proxy national et les serveurs RADIUS de chacun des établissements. Et d'autre part, le bon fonctionnement des méthodes d'authentification choisies par les membres et les points d'accès des universités, qui utilisent une méthode de transport par «tunnel» avec selon les utilisateurs des méthodes d'authentification différentes (PEAP, TTLS, TLS). On explique cette distinction par le fait que la surveillance des RADIUS n'est pas suffisante: en effet même si tous les serveurs RADIUS sont opérationnels, cela n'assure pas qu'un utilisateur pourra se connecter puisque les méthodes d'authentification, elles, n'auront pas été testées, par contre si les tests d'authentification réussissent, cela implique que les serveurs RADIUS fonctionnent puisque l'authentification se fait au travers de ces serveurs. 11
D'où l'idée de tester le réseau de manière montante et non descendante comme certains de nos confrères européens ont procédé: nous testerons dans un premier temps la validité de l'authentification et si il y a problème, alors les communications RADIUS seront testées afin de localiser ce problème. Le résultat du test d'authentification sera disponible sur une interface web (type carte de France) qui indiquera donc à l'utilisateur si le service est disponible dans tel ou tel établissement. Les administrateurs quant à eux disposeront de l'ensemble des résultats des tests, en temps réel. Le principal avantage de cette approche est que les «comptes de tests» (chaque établissement membre d'arredu dispose d'un compte de test qui lui permet notamment d'effectuer localement des tests de connexions ) sont très peu exposés lors du monitoring: en effet ces comptes servent lors des tests de communication entre les serveurs RADIUS, communications qui, lorsqu'elles sont directes, sont sécurisées uniquement par le secret partagé RADIUS (notamment les mots de passe apparaissent dans les fichiers log des serveurs RADIUS lorsque ces derniers sont en mode DEBUG). Les tests RADIUS n'étant effectués que si aucune méthode EAP testée ne fonctionne (les tests EAP sont eux sécurisé via un «tunnel» TLS), ils sont donc utilisé au minimum. Attention! il ne s'agit en aucun cas d'un problème global de sécurité, puisque lorsque l'utilisateur se connecte au travers d'eduroam, les crédits d'authentification transitent dans un tunnel où les données sont protégées et chiffrées, elles ne courent donc aucun risque. Le serveur national dispose d'une base de données (type annuaire LDAP) dans laquelle sont regroupés les comptes ARREDU de l'ensemble des établissements membres d'eduroam (créée lorsque qu'un établissement adhère au projet, ce compte contient des détails sur l'établissement, le compte de test, des données sur les administrateurs etc... http://arredu.cru.fr/). Cependant il faudra veiller à ce que les établissements membres du projet modifient régulièrement les mots de passe des comptes de tests. 12
III Mise en oeuvre 1 ) Le programme eapol_test WPA Supplicant est un logiciel open source pour Linux, il s'agit d'un supplicant WPA, c'est à dire typiquement un élément qui fait partie d'un réseau et effectue une demande de connexion en 802.1X (par exemple, un ordinateur portable se connectant sur une borne Wi-Fi est un supplicant sur son réseau). Ce logiciel, largement utilisé par la communauté, permet d'effectuer des connexion EAP sous presque tous les protocoles existant, on ne détaillera pas ici son utilisation puisqu'on ne s'y intéresse pas directement (page de wpa_supplicant: http://hostap.epitest.fi/wpa_supplicant/ ). Le logiciel est livré avec divers outils, et l'un d'entre eux est particulièrement intéressant: eapol_test. Il s'agit d'un programme qui relie l'implémentation de l'eap proposée par wpa_supplicant et l'authentification sur les serveurs RADIUS: il effectue à la fois le rôle d'un point d'accès Wi-Fi, et celui d'un supplicant IEEE 802.1X: il permet donc le test des diverses méthodes d'authentification EAP sans avoir à mettre en place ni un point d'accès ni un client Wi-Fi. Il s'agit exactement du programme recherché dans le cadre de ce projet puisqu'il va permettre l'automatisation des tests des protocoles EAP au travers des serveurs RADIUS sur le réseau eduroam français. Pour installer eapol_test : Téléchargez wpa_supplicant en version 0.5.4 ou supérieure Décompressez l'archive Créez un fichier.config dans le répertoire racine où les fichiers ont été décompressé, voici le contenu de ce fichier: CONFIG_IEEE8021X_EAPOL=y CONFIG_EAP_MSCHAPV2=y CONFIG_EAP_TTLS=y CONFIG_EAP_PEAP=y CONFIG_EAP_LEAP=y CONFIG_IEEE8021X=y 13
Ces lignes configure la compilation, on y indique que l'on souhaite la configuration pour TTLS,PEAP,LEAP, la prise en compte du standard 802.1X etc... par exemple si par la suite on désire également tester le protocole TLS il faudra veiller à rajouter dans ce fichier la ligne «CONFIG_EAP_TLS=y». Tapez la commande make eapol_test L'application eapol_test est compilée et est maintenant disponible Remarque: Il est nécessaire d'avoir l'application openssl correctement installée pour que la compilation fonctionne. Ne pas oublier de taper > make clean avant toute recompilation (notamment si le fichier.config est modifié) Tapez./eapol_test pour obtenir la syntaxe de l'utilisation du programme en commande ligne, on notera l'existence d'une option permettant de spécifier un délai d'attente («timeout»), d'autres permettant de configurer l'authentification sur un serveur RADIUS,et une option permettant de spécifier un fichier de configuration: c'est l'option la plus importante, au travers de laquelle on pourra indiquer le type de connexion souhaité. 2 ) Le script rad_eap_test Le script rad_eap_test a été développé par nos collègues Tchèques Jan Tomasek et Pavel Polacek et est disponible à l'adresse suivante: http://wiki.eduroam.cz/rad_eap_test/. Il a été crée dans le même but que le notre: effectuer des tests complets de la connectivité à eduroam au niveau national. Ce script, très performant, automatise l'utilisation de eapol_test en proposant une interface ligne qui évite la création systématique d'un fichier de configuration pour eapol_test. 14
Pavel Polacek avait également proposé des patchs pour eapol_test qui ne sont plus nécessaires depuis la version 0.5.4 de wpa_supplicant (ajout des options -t -m et -i). Téléchargez rad_eap_test dans sa version 0.19 ou supérieure Décompresser l'archive Placez l'application eapol_test préalablement compilée dans le dossier racine de rad_eap_test. Le script est désormais fonctionnel et il peut être testé, voici un exemple d'utilisation: > rad_eap_test -H mon.radius.com -P 1812 -S monsecretradius -u test@univrennes1.fr -p PassWord -m WPA-EAP -e PEAP -t 10 Cette commande lance un test d'authentification 802.1X suivant le protocole PEAP sur le serveur RADIUS mon.radius.com, dont le secret partagé avec ma machine est monsecretradius, mon compte et mon mot de passe de connexion sont respectivement test@univ-rennes1.fr et PassWord, et on impose un délai d'attente maximal de 10 secondes (par défaut: 30 secondes). En observant les fichiers logs des serveurs RADIUS, on s'aperçoit alors que eapol_test et le serveur RADIUS communiquent bien en transmettant des requêtes RADIUS et des messages EAP, la réponse à la commande est soit un access-accept (authentification réussie), soit un access-reject (connexion refusé: typiquement login ou secret partagé incorrect) soit un timeout (délai d'attente dépassé). Voici quelques erreurs auxquelles nous avons été confronté lors du test du script: La machine sur laquelle le test était lancé n'était pas dans le fichier de configuration du serveur RADIUS: cela est nécessaire, en particulier il faut définir un secret partagé entre la machine et le serveur RADIUS. Les filtres des serveurs RADIUS étaient mal configurés: en effet, certains filtres effacent l'attribut «Message-Authentificator» lors des dialogues EAP, rendant impossibles ces derniers. 15
Le script rad_eap_test est facilement modifiable: on peut notamment modifier les messages d'erreurs ou les codes de sorties (voir à la fin du fichier), il permet également de configurer eapol_test pour d'autres protocoles comme EAP-TLS, mais nous nous limiterons aux protocoles PEAP et TTLS, puisque pour des raisons de certificats,il n'est pas envisageable de tester le protocole TLS. Remarque: Lors de problèmes avec l'utilisation du script, nous ne pouvons que conseiller de suivre en temps réel les communications RADIUS, que ce soit le serveur RADIUS auquel on tente de s'authentifier ou le proxy national. On peut notamment les stopper et les relancer en mode debug (option -XA), et parallèlement on peut rendre le script plus «parlant» en activant la ligne suivante (retirer le commentaire dans le fichier rad_eap_test) : $EAPOL_PROG -c$conf -a$ip -p$port -s$secret -t$timeout -M$MAC -C"$CONN_INFO" $STATUS_DIR la configuration est elle placée dans la variable $conf, retirer le commentaire de la ligne suivante (toujours dans le fichier rad_eap_test) pour observer le contenu de la configuration: cat $conf En regardant en plus les fichiers logs des serveurs RADIUS, le problème devrait rapidement paraître plus évident. 16
IV Exploitation 1 ) La page web de surveillance Les résultats de rad_eap_test doivent être exploités, pour cela, 2 moyens seront utilisés: le logiciel Nagios comme nous le verrons par la suite, sera le principal exploitant du script, avec une interface dédiée et des fonctionnalités avancées. Mais afin d'avoir accès plus rapidement aux résultats de base, nous avons décidé de mettre en place au CRU une page web sur laquelle serait présentée dynamiquement l'état d'eduroam. Cette page est en fait un script en langage php qui utilise la base de données LDAP de Arredu. Comme nous l'avons vu, cette base contient un compte de test par établissement membre d'eduroam. Le script va effectuer des requêtes LDAP sur la base ARREDU afin d'obtenir pour chaque établissement actif d'eduroam le nom et le mot de passe du compte de test, ainsi que le nom du domaine (realm) et le port d'accounting (normalement cette valeur est de 1812 pour les serveurs RADIUS usuels). Pour chaque compte, les requêtes sont effectuées et 2 commandes sont exécutées: rad_eapol_test avec en option -e PEAP pour tester le protocole EAP-PEAP entre la machine hébergeant le script et l'établissement rad_eapol_test avec en option -e TTLS pour tester le protocole EAP-TTLS entre la machine hébergeant le script et l'établissement Si les 2 premières commandes échouent, on teste alors le serveur RADIUS (car si l'un des 2 tests précédent à réussi, cela implique que le serveur RADIUS fonctionne) grâce à la commande suivante: radtest pour obtenir l'état du serveur RADIUS 17
Les résultats de ces commandes sont ensuite analysés et rassemblés dans un tableau qui offre une perspective globale du réseau en «end2end» c'est à dire que le réseau est testé dans sa globalité, cela permet ensuite d'affirmer qu'un établissement est disponible pour les utilisateurs d'eduroam ou pas. De plus le tableau indique le type d'erreur si il y en a (connexion refusée, timeout). Ce script est relancé régulièrement (toutes les 15 minutes) grâce à une crontab à laquelle on a ajouté une tâche selon la syntaxe suivante: */15 * * * * php -q /test/test_serveurs.php > /test/tableau.html Il génère ainsi une page web dans laquelle est placé le tableau décrit précedemment. Remarque: Se reporter aux commentaires du fichier pour des informations sur le code. 2 ) Intégration au logiciel NAGIOS Nous avons décidé de mettre le script en oeuvre à l'aide de NAGIOS, logiciel de monitoring open-source, afin de pouvoir exploiter au maximum les résultats des tests effectués (comme nous l'avons vu, nos confrères européens ont eu la même initiative). En effet le script rad_eap_test est un plugin compatible NAGIOS: il donne en sortie un chiffre compris en 0 et 4 indiquant à NAGIOS le niveau de réussite ou d'échec du test. Voici comment NAGIOS interprète ce chiffre: valeur 0 : OK (le service fonctionne correctement). valeur 1 : Warning (le service fonctionne en mode dégradé). valeur 2 : Critical (le service ne fonctionne plus). valeur 3 : Unknown (impossible de déterminer l état du service). Et voici la sortie de rad_eap_test : valeur 0 : access-accept. valeur 1 : access-reject. valeur 2 : timeout. valeur 3 : problème de configuration. 18
rad_eap_test devra être placé dans le sous-répertoire libexec de NAGIOS, avec les droits en exécution et la commande NAGIOS correspondante devra être définie dans le fichier checkcommands.cfg Remarque: L'intégration de NAGIOS ne s'est pas faite à l'heure où sont écrit ces lignes: le monitoring «sans NAGIOS» offre (pour l'instant) des fonctionnalités suffisantes et l'intégration à NAGIOS se révèle plus compliquée que prévue: conversion de la base LDAP ARREDU vers la base SQL de NAGIOS nécessaire, création de groupes de machines, définition de 3 commandes pour chaque machines etc..., ce qui a déjà fait pour le script de tests, cependant des fonctionnalités intéressantes de NAGIOS comme l'envoie de SMS ou une gestion précise de l'envoie d'emails, de dépendances des tests, pourrait être utilisée dans le futur. Voici un schéma présentent les divers outils intervenant dans le monitoring: 19
Remarque: Lors du développement, le programme eapol_test a été placé sur la machine stage2. Il a finalement été placé sur la machine rad1.cru.fr (le proxy national d'eduroam). Nagios n'a 3 ) Mise en place de la carte dynamique Afin de mettre à disposition des utilisateurs d'eduroam les résultats de ces travaux, nous avons décidé de les présenter sous la forme d'une carte de France où chaque établissement membre du réseau sera localisé. Ainsi un membre de l'un de ces établissements pourra à tout moment consulter sur Internet les points d'accès dont il dispose, ce qui est bien sûr très utile en déplacement. Au lieu de procéder au développement d'un script qui serait utilisable uniquement dans le contexte d'eduroam et de la structure de notre réseau, nous avons décidé de développer une librairie en langage php qui permettra de générer des cartes dans d'autres contextes. Bien sûr cette approche nécessite plus de travail mais permettra à l'application, grâce à sa généricité, d'être utilisée dans d'autres environnements, ce qui pourra permettre un gain de temps notable pour d'autres développeurs, puisque ce genre de librairie n'est pas courante (voir inexistante). Nous ne détaillerons pas ici le fonctionnement de cette librairie: pour cela reportez vous à la documentation de cette dernière (compatible avec le logiciel doxygen) dans laquelle vous trouverez les détails des paramètres des divers fonctions et des commentaires de développement. Voici, dans notre contexte d'eduroam, comment s'utilise cette librairie: Le script de test des serveurs de la base ARREDU (décrit dans la section précédente) génère un fichier texte nommé «results_test.txt» dans lequel il place les informations du monitoring comme ceci: pour chaque nouveau site testé on écrit une nouvelle ligne avec son nom (le champ «cn» de la base ARREDU) puis sur les 2 lignes suivantes on écrit les résultats des tests PEAP et TTLS. Un script php nommé «carte_eduroam.php» effectue des requetes LDAP afin de récupérer les champs nécessaires à la construction de la carte et lit le fichier «results_test.txt» pour construire un tableau php utilisé par la librairie, voici le schéma de ce tableau: 20
Nom site1 Latitude site1 Longitude site1 Couleur site1 Lien site1 Titre tableau site1 Nom tableau result_peap Distance tolérée site1 Rayon site1 result_ttls Nom site2 Latitude site2 Longitude site2 Couleur site2 Lien site2 Titre tableau site2 Nom tableau result_peap Distance tolérée site2 Rayon site2 result_ttls........................... Les diverses données de ce tableau sont explicitées dans la documentation de la librairie, par exemple, la «distance tolérée» est la distance en pixels que l'on autorise par rapport aux autres sites de la carte avant d'effectuer un regroupement, le tableau avec les résultats des tests est celui qui sera affiché dans un popup lorsque la souris passera sur le site, le lien est le lien web auquel renvoie le site, etc... Voici comment les fonctions de la librairie sont utilisées dans le fichier «carte_eduroam.php»: map_initialize('/www/vespa/html/eduroam/monitoring/maps/',"/www/vespa/html/ eduroam/monitoring/mapping/","eduroam/monitoring/maps/","france.png","blue"," _img"); map_create(&$tableau); map_mapper("border=0"); map_intialize débute la création de la carte et fournit 3 chemins d'accès indispensable à la librairie: le premier est le chemin du répertoire dans lequel sera placé la carte, le second est le chemin d'accès à la librairie, et le troisième est le chemin d'accès serveur au répertoire où les cartes seront installées. Le paramètre suivant indique le fond de carte que l'on souhaite utiliser: la librairie reconnaît ce 21
fond (et le calibrage n'est donc pas nécessaire, ce qui n'est pas le cas lorsqu'un fond de carte inconnu à la librairie est fournit). Les 2 derniers paramètres sont respectivement la couleur utilisée en cas de regroupement des sites et le tag placé devant le nom des images générées. map_create crée la carte proprement dit, son unique paramètre est le tableau décrit plus haut,qui dans notre cas aura donc été crée grâce à la base ARREDU et au fichier results_test.txt map_mapper renvoi le code html contenant la carte crée, l'unique paramètre est le champ que l'on souhaite rajouter au tag HTML «<IMG>» que renvoi la fonction: par exemple ici on souhaite qu'il n'y ait pas de bordures. Remarque sur le style des popups: Lorsque la souris passe sur un site, un «pop up» (basé sur du langage javascript) apparaît avec les informations fournies, ce «pop up» peut être personnalisé: pour cela éditez les fichiers.js et.css situés dans le répertoire /style (vous pourrez alors, par exemple, modifiez la police, la couleur de fond, la bordure, etc...) 22
Voici un schéma résumant les lien des divers intervenants dans la création de la carte des participants eduroam: La mise en place de cette carte figurait dans le cahier des charges comme un supplément «bonus» au monitoring, mais la première partie ayant été achevé relativement tôt, j'ai pu prendre le temps nécessaire au développent de cette librairie, qui a été un point très intéressant du stage. 23