En permettant l’application de la politique au plus proche de l’utilisateur, à la bordure du réseau, les points d’accès HiveAP peuvent appliquer des politiques de sécurité, de contrôle d’accès et de qualité de service puissantes et flexibles, fonction de l’identité de l’utilisateur, tout ceci au périmètre du réseau, permettant ainsi de ne laisser entrer sur le réseau de l’entreprise que le trafic dument autorisé.
C’est un élément essentiel de la technologie de contrôle coopératif et de l’architecture distribuée de la solution Aerohive : appliquer des politiques de contrôle au trafic local au niveau du point d’accès permet au moteur de firewall et de protection contre les dénis de service de valider le trafic au point d’entrée et ce avant même qu’il soit transmis au réseau au travers du HiveAP.
De même, il permet au moteur de qualité de service de répondre instantanément et en temps réel aux variations de débit inhérentes à tout environnement radio dynamique.
Appliquer la politique au périmètre fournit un contrôle substantiellement meilleur que toute autre solution appliquant le même contrôle bien plus loin dans le réseau, par exemple au niveau d’un contrôleur centralisé.
La solution de réseau sans fil Aerohive définit différents groupes de politiques d’accès correspondant à différentes classes d’utilisateurs et ce au travers de la création de profil d’utilisateurs.
Chaque profile d’utilisateurs permet de définir : un VLAN, une politique de qualité de service (QoS), une politique de firewall (MAC et TCP/IP) et une politique de mobilité de niveau 3 ; politiques qui sont ensuite assignées aux utilisateurs lorsqu’ils se connectent au réseau sans fil.
Sur un même HiveAP, un ou plusieurs attributs peuvent être assignés à un profil utilisateur.
Si un utilisateur s’authentifie avec le HiveAP en utilisant une authentification 802.1X et EAP, le serveur Radius peut retourner l’attribut de profil utilisateur correspondant au HiveAP qui va alors associer l’utilisateur au profil défini. En outre, l’attribut de profil utilisateur retourné par le serveur Radius peut être défini en fonction de l’appartenance de l’utilisateur à un groupe Active Directory, LDAP ou à un domaine Radius (realm).
Si un utilisateur ne s’authentifie pas avec 802.1X (par exemple, une connexion par clé WPA partagée), alors le profil utilisateur peut être assigné en fonction du SSID sur lequel l’utilisateur est connecté. Tous les utilisateurs du SSID partagent alors les mêmes paramètres du profil utilisateur, puisqu’il n’existe alors aucun moyen pour les différencier.
L’attribut de profil utilisateur assigné à un client demeure lié à celui-ci et ce même s’il erre entre différents points d’accès HiveAP au sein du réseau.
En outre, la granularité de configuration des HiveAP permet aux administrateurs de configurer des politiques identiques quelque soit la localisation du client, ou bien d’adapter la politique en fonction du lieu où se connecte le client, par exemple en modifiant le numéro de VLAN utilisé tout en conservant les autres paramètres (ex. règles de firewall et de QoS).
Autre exemple de granularité : les HiveAP d’un bâtiment peuvent spécifier dans le profil utilisateur une politique de QoS ne limitant pas l’utilisation de la bande passante ; cependant, dans un autre bâtiment où la bande passante sera plus restreinte et coûteuse, les HiveAP peuvent spécifier une règle de limitation plus stricte du volume de trafic. Et lorsque l’utilisateur errera entre les différents bâtiments, il conservera le même attribut de profil utilisateur, mais la politique correspondante sera automatiquement modifiée en fonction de la localisation du HiveAP sur lequel est connecté le client.
Le diagramme ci-après montre un exemple d’utilisation du profil utilisateur.
Dans cet exemple, lorsqu’un utilisateur s’authentifie et se connecte au SSID Corp_Wi-Fi, le serveur Radius retourne un numéro d’attribut de profil utilisateur pour cet utilisateur spécifique et le HiveAP utilise cette valeur pour lier l’utilisateur au profil correspondant, garantissant ainsi que les politiques adéquates lui sont appliquées. Cette mise en correspondance de numéro d’attributs et de profils utilisateurs peut être différente dans différentes zones du réseau, permettant l’application d’une politique globale ou différenciée en fonction de la localisation du client.
Toujours dans cet exemple et dans les différentes localisations de l’utilisateur, un numéro de VLAN distinct et des politiques de QoS différenciées, mais les mêmes règles de firewall et de mobilité, sont appliqués à l’utilisateur. De même, d’autres utilisateurs mobiles peuvent errer dans les mêmes zones du réseau et se verront attribuer des numéros de VLAN et des politiques différentes.
Ceci permet aux administrateurs de créer des politiques d’accès basées à la fois sur l’identité de l’utilisateur et sa localisation.
A chaque fois que des données sont transmises depuis un réseau à haut débit, tel qu’un réseau Ethernet filaire, vers un réseau à plus bas débit, tel qu’un réseau sans fil, il existe un risque important de perte de paquets et de dégradation des performances.
L’analogie la plus évidente est une autoroute à 4 voies qui se rétrécirait en 2 voies et sur laquelle un véhicule de secours, par exemple une ambulance, doit progresser le plus rapidement possible un jour de congestion.
Lorsque le trafic est envoyé depuis un réseau filaire vers un réseau sans fil, et afin d’assurer des performances optimales pour les applications critiques telles que la voix ou la vidéo, sans porter préjudice aux performances des applications à plus faible priorité telles que le courrier électronique et le Web, des techniques de qualité de services (QoS) avancées sont nécessaires.
Pour répondre à ce besoin, Aerohive a développé un moteur de QoS embarqué dans chaque HiveAP afin d’assurer des performances optimales pour chaque type de trafic (haute ou basse priorité).
En outre, la puissance nécessaire pour traiter correctement la qualité de service est distribuée au sein de chaque HiveAP, ce qui permet un traitement réparti du trafic global sur le réseau sans fil au lieu d’un traitement central sur un seul contrôleur qui doit alors traiter l’ensemble du trafic.
Cette approche permet une évolutivité linéaire lorsque de nouveaux HiveAP sont ajoutés, et ce sans congestion ni goulet d’étranglement.
L’une des technologies de qualité de service pour les réseaux sans fil implémentées dans les points d’accès modernes est la norme IEEE 802.11e/WMM (Wireless Multi-Media).
Avec WMM, le trafic provenant d’un HiveAP peut être priorisé avant transmission sur le réseau sans fil. Le trafic est alors classifié en 4 catégories, qui sont ensuite mises en file d’attente et hiérarchisées en fonction du temps et de la sensibilité des données. Les catégories les plus prioritaires peuvent utiliser un plus petit délai inter-trame et une plus petite fenêtre de dégagement pour permettre une transmission sur le réseau sans fil avec moins de délai et de retard.
Bien que WMM assure un traitement adéquat pour la transmission du trafic prioritaire sur le réseau sans fil, il n’en est pas de même pour les files d’attente à moindre priorité. Ainsi, puisque WMM utilise des files d’attente à priorité stricte, si un trafic voix ou vidéo est en cours de transmission sur le réseau sans fil, il est fort probable que les files d’attente de priorité inférieure se retrouvent rapidement encombrées et congestionnées du fait de l’impossibilité de transmettre leurs données sur le réseau. Et lorsqu’une file d’attente est pleine, même momentanément, les paquets sont systématiquement rejetés.
Ceci ne semble pas constituer un problème essentiel, puisque si les paquets sont rejetés, et surtout si le protocole utilisé est TCP, alors ils seront retransmis. Et pourtant, il n’en est rien. Il s’agit bien là d’un problème majeur. En effet, puisque TCP utilise un algorithme intégré d’évitement de congestion qui divise la fenêtre de contention par deux lorsqu’un paquet est rejeté, les performances TCP peuvent gravement affectées.
Bien que les applications classifiées en priorité élevée ne sont pas affectées, les applications à priorité basse, telles que le Web et le courrier électronique, peuvent en subir les conséquences. En utilisant des techniques avancées de QoS pour augmenter les capacités de WMM, il est possible de d’atténuer les pertes de paquets et assurer des performances bien meilleures pour ces applications à basse priorité.
Dans le but d’assurer une transmission très efficace de la voix et de la vidéo, mais également de minimiser les conséquences liées à d’éventuelles pertes de paquets dues à une congestion momentanée des files d’attente WMM, Aerohive étend les fonctions de WMM en implémentant un procédé de classification avancée, des politiques de traitement spécifique (limitation du débit), une mise en file d’attente et un mécanisme spécifique d’ordonnancement des paquets au sein de chaque HiveAP.
Le diagramme ci-après présente un exemple simple de la série de traitements appliqués au trafic par le moteur de qualité de service embarqué dans un HiveAP.
Le traitement appliqué par le HiveAP au trafic en provenance du réseau, afin d’assurer une qualité de service optimale, repose sur 6 étapes essentielles :
En résumé, le moteur de QoS de Aerohive, embarqué dans les HiveAP, permet de transmettre les paquets avec une priorisation granulaire et déterministe vers les files d’attente WMM. En outre, l’ordonnanceur de paquets supervise constamment la disponibilité et la congestion des queues WMM et n’autorise la transmission de paquets vers ces queues que lorsqu’elles sont disponibles. Ce mécanisme évite que des paquets soient rejetés inutilement lorsque les queues WMM sont pleines et permet d’obtenir une meilleure qualité pour les trafics sensibles tels que la voix et la vidéo, tout en préservant les performances des trafics à priorité plus faible tels que le Web et le courrier électronique. Lorsque les paquets ont atteint les queues WMM, ils sont transmis au medium sans fil en fonction de leur catégorie, niveau de priorité et du standard WMM.
Ces précieuses améliorations de la QoS des réseaux sans fil sont rendues possibles par l’implémentation du moteur de QoS directement au sein des points d’accès HiveAP, le seul endroit du réseau où il est possible de réagir instantanément aux changements dynamiques des conditions réseaux et radio et offrir en réponse une qualité de service adaptée.
Grâce à l’architecture distribuée de contrôle coopératif, la politique de sécurité est définie par les administrateurs de manière centralisée sur le HiveManager, mais elle est appliquée à l’entrée du réseau, directement sur les points d’accès HiveAP.
Ceci est rendu possible par le fait que chaque HiveAP est responsable du chiffrement/déchiffrement des trames des communications sans fil, disposant ainsi de la possibilité d’inspecter le contenu des paquets, d’appliquer les contrôles de sécurité et de chiffrer à nouveau le trafic avant de le renvoyer vers le réseau.
Ceci permet aux HiveAP d’appliquer des politiques de sécurité avancées, localement au niveau du point d’entrée sur le réseau et ce avant que le trafic ne soit envoyé vers le réseau filaire, vers une autre connexion sans fil maillée ou vers un autre client sans fil.
Les politiques de sécurité sont appliquées par les HiveAP de manière différenciée et personnalisée en fonction de l’utilisateur ou du SSID. Ces politiques de sécurité permettent de filtrer les adresses MAC des clients, les communications Ethernet niveau 2 et les communications IP/TCP-UDP niveaux 3 et 4. S’ajoute à cela un moteur de protection contre les tentatives de déni de service (DoS).
En outre, puisque chaque HiveAP est responsable de l’application de la politique de sécurité sur son propre trafic, on dispose des avantages et de la puissance du traitement distribué de la sécurité entre tous les HiveAP du réseau sans fil, plutôt que d’être restreint et soumis aux capacités limitées d’un contrôleur centralisé.
Enfin, puisque chaque HiveAP déchiffre le trafic à l’entrée du réseau et ce avant même de l’envoyer vers le réseau filaire, il est tout à fait possible de réutiliser les systèmes et infrastructures de sécurité déjà déployées sur le réseau d’entreprise pour appliquer un deuxième contrôle sur le trafic provenant du réseau sans fil. Il peut s’agir de firewalls, de sondes de détection/prévention d’intrusions, d’antivirus réseau, de solutions de contrôle de l’admission (NAC/NAP),… Dans une architecture centralisée à base de contrôleur, il n’est pas rare que ces solutions de sécurité existantes soient rendues totalement inopérantes.
Une autre manière d’application la politique au niveau du point d’entrée sur le réseau consiste à utilise la fonction de portail web captif intégré sur chaque HiveAP, similaire à la fonction de hot-spot Wi-Fi que l’on utilise habituellement dans les aéroports et les hôtels.
Lorsqu’un utilisateur se connecte à un SSID sur lequel le portail web captif est activé, son navigateur est automatiquement redirigé vers une page Web d’enregistrement, totalement personnalisable (format, contenu, logo,…).
La même technologie qui permet aux HiveAP de supporter la mobilité de niveau 3 de manière transparente pour les clients sans fil peut également être utilisée afin de créer dynamiquement des tunnels entre HiveAP connectés à différents réseaux et renvoyer le trafic des utilisateurs dans ces tunnels en fonction de leur identité.
Cette fonctionnalité est particulièrement intéressante dans les environnements où de nombreux invités (guests) sont autorisés à se connecter au réseau.
Deux solutions sont classiquement envisageables :
Parmi les différents paramètres contenus dans un profil utilisateur sur un HiveAP, il est possible de configurer, dans la politique de mobilité, l’utilisation de tunnels dynamiques basés sur l’identité de l’utilisateur. Lorsqu’un utilisateur s’associe à un SSID sur un HiveAP, s’authentifie, et se voit assigner un profil utilisateur, la politique de sécurité (firewall) et la politique de qualité de service (QoS) pour ledit utilisateur sont appliquées localement par le HiveAP, puis l’intégralité du trafic de l’utilisateur est injecté dans un tunnel GRE vers un HiveAP (ou un groupe de HiveAP) spécifique connecté à un réseau distant (par exemple, une DMZ d’un firewall d’accès Internet).
De cette manière, une fois authentifié, l’utilisateur reçoit ses paramètres IP depuis un serveur DHCP du réseau distant, comme s’il était connecté physiquement localement à celui-ci. L’utilisateur devient alors véritablement un membre étendu du réseau distant.
Exemples d’utilisation : une équipe de consultants, d’intervenants externes, de sous-traitants ou d’auditeurs doit disposer momentanément d’un accès distant au site central de l’entreprise, tout en étant connecté physiquement depuis une filiale ou une agence. En utilisant le principe de tunnels basés sur l’identité de l’utilisateur, ces clients temporaires peuvent s’associer à un SSID diffusé sur l’ensemble des HiveAP du réseau et voir leur trafic automatiquement et directement renvoyé dans un tunnel vers un groupe de HiveAP disposés au niveau du site distant auquel ils souhaitent se connecter. Ils sont alors perçus, d’un point de vue réseau IP, comme des utilisateurs locaux à ce réseau distant.
Un autre exemple du fonctionnement de ce principe de tunnels et d’accès distants, couplé avec un portail web captif, est détaillé dans le diagramme ci-après.
Un SSID Invité configuré et diffusé sur l’ensemble des HiveAP du réseau interne est utilisé par les personnes externes qui visitent l’entreprise. Lorsqu’un invité s’associe à ce SSID, un portail web captif est utilisé pour authentifié l’utilisateur sur la base d’un serveur Radius. Une fois l’authentification effectuée, les politiques de QoS et de sécurité sont appliquées à l’utilisateur et le trafic du client est directement renvoyé dans le tunnel vers un HiveAP disposé en DMZ du firewall d’accès Internet. A aucun moment, l’utilisateur invité ne peut accéder à une ressource du réseau interne. Seul l’accès à la DMZ lui est possible. D’ailleurs, son adresse IP appartient au sous-réseau de la DMZ et non à celui du réseau sur lequel le HiveAP auquel il est associé est connecté. Le trafic du client ne peut donc en aucun cas être routé localement.
En plus des capacités de portail web captive disponibles sur les HiveAP, Aerohive propose d’autres fonctionnalités qui peuvent être utilisées pour fournir une solution d’accès invité globale, robuste, sécurisée et évolutive.
Citons notamment :
Cette solution complète d’accès invité proposée par Aerohive permet une totale flexibilité grâce à l’intégration des fonctionnalités directement au niveau des points d’accès HiveAP et à l’interopérabilité avec les solutions tierces de gestion des invités.
This création is licensed under a Creative Commons Paternité - Pas d'Utilisation Commerciale - Partage des Conditions Initiales à l'Identique 2.0 France License.
Revenir en haut
