Voici les choix matériels et logiciels qui ont été faits au CNRS.
Choix Matériels
Contexte
Les équipements nécessaires à la solution étudiée dans les chapitres précédents doivent supporter le protocole 802.1x, les VLAN, les trunks et le filtrage pour la sécurité. Ceci, tout en supportant une connexion performante pour l'utilisateur, en filaire comme en Wifi.
Solutions possibles
En filaire, le CNRS s'est équipé en 2001 d'équipements de marque Cisco. Il s'agit de 4506 pour le routeur central (noté Rt-CNRS sur les schémas), 3550 pour les routeurs de laboratoire, 2950 pour les commutateurs de proximité. Cela permet d'avoir un coeur de réseau Gigabit, et un débit de 100Mb/s pour tous les utilisateurs, tout en supportant les contraintes que sont le protocole 802.1x, les VLAN, les trunks et le filtrage. Il n'est pas envisagé de changer ces équipements pour une raison de coût et car ils sont suffisamment performants encore aujourd'hui.
Concernant les bornes Wifi, il est demandé aux équipements de supporter les VLAN, les trunks, le protocole 802.1x, et la détection des bornes pirates. En 2005, l'étude a porté sur les équipements Cisco, Symbol, et Hewlett-Packard.
Choix réalisés
Pour le filaire, les équipements ne changent pas et les différents types de commutateurs-routeurs de marque Cisco sont conservés.
Concernant les bornes Wifi, le choix s'est porté sur la borne Hewlett Packard Procurve Wireless 420ww qui présente en effet des avantages très importants :
supporte 802.11b et 802.11g ;
supporte 802.1x ;
supporte les VLAN ;
supporte WPA pour les conférences ;
détecte les bornes pirates éventuelles ;
prix attractif, environ 300€ HT début 2007.
L'inconvénient de la borne Hewlett Packard WL420ww est de ne supporter l'annonce en diffusion que d'un seul réseau.
Choix Logiciels
Contexte
Concernant les logiciels, tous les serveurs devant les supporter sont sous Linux. Les logiciels libres sont préférés pour une question de budget, mais aussi de façon à pouvoir modifier leur code source si nécessaire. C'est aussi une volonté de politique générale des établissements éducation / recherche.
Serveur Radius
Pour le serveur Radius, il a été choisi FreeRadius, qui est la référence, et est disponible sur http://www.freeradius.org/. Ce serveur est celui sur lequel s'appuient les RFC de Radius. Il est de plus recommandé par les administrateurs gérant ARREDU. Très complet, il permet de faire l'authentification et l'accounting des connexions avec beaucoup de détails. Cela a un coût : il est très facile d'obtenir une configuration énorme et incompréhensible qui sera ingérable à long terme.
D'autres serveurs Radius sont disponibles, mais aucun ne supporte toutes les fonctionnalités demandées :
- XTRadius n'est plus maintenu depuis 2002 au profit de Cistron ;
- Cistron Radius ne supporte pas le protocole LDAP, et n'est plus maintenu depuis 2006 ;
- Yardradius ne supporte pas TTLS, et n'est plus activement développé.
Annuaire LDAP
L'annuaire LDAP central du site CNRS est déjà en place. Il s'agit de OpenLDAP, disponible sur http://www.openldap.org/. Ce serveur est aussi le plus connu du monde libre. Il est le seul disponible sur Debian. Performant, il est aujourd'hui utilisé pour gérer des annuaires de plusieurs centaines de milliers de comptes et il est donc correct pour supporter le millier d'utilisateurs du CNRS de Grenoble.
Serveur VPN
Pour le VPN, le logiciel OpenVPN a été choisi (http://openvpn.net/) car c'est le seul qui permette de gérer les tunnels SSL ainsi que d'authentifier les utilisateurs sur un serveur Radius tout en fournissant le logiciel à installer sur les ordinateurs clients gratuitement. Le client est disponible pour Windows, Mac OSX, Linux.
Comme il s'agit d'un tunnel SSL, il est juste nécessaire de laisser passer un port UDP au niveau des pare-feux.
Serveur de portail captif
Le portail captif choisi est Chillispot, disponible sur http://www.chillispot.info/. Ce portail captif permet l'authentification/accounting auprès d'un serveur Radius en natif, mais supporte surtout un tunnel HTTPS pour faire transiter les identifiants de l'utilisateur. De cette façon, les pirates éventuels ne peuvent pas récupérer le mot de passe de l'utilisateur en écoutant le réseau. Par contre, une fois l'utilisateur connecté, la connexion sera non cryptée.
La plupart des portails captif, comme NoCat, utilisent le protocole HTTP pour transmettre le mot de passe. Ils ne sont plus acceptables dans un environnement de sécurité.
Le serveur Web utilisé pour la communication HTTPS est Apache car c'est celui qui est le plus massivement utilisé dans le monde, tout en supportant toutes les technologies comme les CGI, et le protocole HTTPS. Facile d'installation, les fichiers de configuration sont très lisibles et les documentations sur le site Web sont très bien écrites.
Serveur DHCP
Le serveur DHCP utilisé est celui de l'ISC (http://www.isc.org/index.pl?/sw/dhcp/). C'est le serveur utilisé sur les plateformes Unix car il est maintenu et fournit toutes les technologies souhaitées. Il doit être interfacé avec Syslog-NG pour permettre la propagation des journaux de connexion vers la base d'accounting.
Serveur VMPS
Il existe plusieurs serveurs VMPS sous licence libre. Il a été choisi le programme de Christophe Fillot, disponible sur http://www.utc.fr/~fillot/vmps/, car il est très simple d'utilisation et de configuration comparé aux autres comme OpenVMPS. De plus, il sait gérer l'intégration dans un VLAN par défaut en cas d'absence de définition.
Client 802.1x
Côté clients, Windows ne supportant pas le cryptage TTLS, il a fallu trouver un autre logiciel. En libre et gratuit, il n'y a que SecureW2, c'est donc lui qui a été choisi.
Pour les autres plateformes comme MacOS et Linux, le choix se tournera probablement vers wpa_supplicant, mais ceci n'a pas été testé et fait partie des évolutions futures de ce projet.
CNRS / Centre Réseau et Informatique Commun (CRIC) - Dernière modification : 26/06/2019.
Mail : CRIC @ grenoble.cnrs.fr (sans les espaces)