Bonjour,
Beaucoup de déploiements en IAP nécessitent de supporter la diffusion d'un SSID accueillant une population de type "guest".
Quand le site distant sur lequel officient les bornes n'est connecté au SI qu'au travers d'un lien privé, il devient indispensable de transporter ces flux non sécurisés vers un point de terminaison central par l'intermédiaire d'un tunnel.
Or c'est justement ce point qui nous interesse aujourd'hui car il existe plusieurs façons de faire qui ont une importance sur le design final.
Lors de la création du tunnel, plusieurs modes sont proposés (IPSEC, Aruba GRE, Manual GRE). Or certains de ces modes proposent l'option "Per-AP tunnel", qui par défaut est décochée. Avec cette configuration, seule l'AP élue maître au sein du cluster tentera de monter ce tunnel avec le point de terminaison.
Reste alors la question de savoir comment une borne esclave fera pour acheminer son trafic invité vers ce point de terminaison : La borne esclave switchera localement sur le VLAN associé le trafic guest. La borne maître le "récupère" et l'envoie dans le tunnel.
Comme vous pouvez le constatez, ce mode sans "Per-AP tunnel" exige de l'infrastructure filaire sous jacente qu'elle puisse transporter le VLAN guest en local. Les ports sur lesquels sont connectées les bornes doivent donc être en 802.1q.
A partir du moment ou le "Per-AP tunnel" est activé, cette problématique disparaît puisque chaque borne a son tunnel vers le point de terminaison. Plus besoin donc de demander à l'architetecture sous jacente de commuter les flux guest. Ce qui enlève aussi une épine du pied coté sécu.
Il y a une cependant une exception: Dans le cas de figure ou le SSID guest a été configuré avec "Virtual controller managed" dans "Client IP assignment", le traffic guest est reforwardé par un mécanisme propriétaire entre bornes esclaves et borne maitre. Pas besoin dans ce cas donc d'avoir le Per-AP tunnel ou d'avoir un prerequis quelconque sur le LAN.