Voir la transcription du podcast
Bienvenue dans la série d'informations techniques Purple. Je suis votre hôte et aujourd'hui, nous abordons un sujet qui revient dans presque tous les déploiements WiFi invités d'entreprise sur lesquels nous travaillons : la configuration d'un Captive Portal sur les points d'accès Cisco Meraki MR, et plus particulièrement la façon de l'intégrer à la plateforme cloud de Purple à l'aide de l'authentification RADIUS. Que vous soyez un MSP intégrant un nouveau client dans le secteur de l'hôtellerie ou un architecte réseau interne pour une chaîne de magasins, cet épisode vous fournira les étapes de configuration précises et les explications sous-jacentes.
Plantons le décor. Vous disposez d'un site - il peut s'agir d'un hôtel, d'un centre de conférence, d'un stade ou d'un parc commercial - équipé de points d'accès Cisco Meraki MR gérés via le Meraki Dashboard. L'objectif est de déployer une expérience WiFi invités personnalisée à l'image de la marque qui collecte des données de première partie, impose l'acceptation des conditions d'utilisation et transmet des données analytiques à une plateforme marketing. C'est précisément pour cela que Purple a été conçu, et Meraki est l'un de nos déploiements matériels les plus courants à l'échelle mondiale.
Maintenant, le point d'architecture essentiel à comprendre avant de modifier le moindre paramètre est le suivant : sur Cisco Meraki, l'authentification RADIUS pour une page de redirection n'est pas traitée localement par le point d'accès. La requête RADIUS Access-Request provient du cloud Meraki - de l'infrastructure du Dashboard - et non de l'AP sur votre réseau local. Il s'agit d'une distinction cruciale qui piège de nombreux ingénieurs lors de leur premier déploiement Meraki. Cela signifie que votre serveur RADIUS, en l'occurrence le point de terminaison cloud RADIUS de Purple, doit être accessible depuis Internet, et que vos règles de pare-feu doivent autoriser le trafic provenant des plages d'adresses IP du Meraki Dashboard, et pas seulement de votre sous-réseau AP local. Vous trouverez les plages d'adresses IP actuelles du Dashboard sous l'onglet Aide, puis Informations sur le pare-feu dans votre Meraki Dashboard.
Passons maintenant à la configuration. Je vais vous guider dans l'ordre réel de réalisation lors d'un déploiement en direct.
Étape 1 : Configuration de l'SSID. Dans le Meraki Dashboard, accédez à Wireless, puis Configure, puis SSIDs. Sélectionnez l'emplacement de l'SSID que vous souhaitez utiliser pour l'accès invité. Donnez-lui un nom clair - tel que GuestWiFi ou NomDuSite underscore Guest. Dans les exigences d'association (Association requirements), définissez la sécurité (Security) sur Open, sans chiffrement. C'est une démarche correcte et délibérée - la couche de sécurité pour les invités est gérée par le Captive Portal et l'authentification RADIUS, et non par le chiffrement WPA. Si vous effectuez un déploiement dans un environnement PCI-DSS, vous devrez vous assurer que le trafic invité est isolé sur son propre VLAN, ce que nous aborderons sous peu.
Étape deux : Page de connexion et authentification. Toujours sur la page Access Control de votre SSID, faites défiler vers le bas jusqu'à la section Splash page. Configurez-la sur Sign-on with, et dans le menu déroulant, sélectionnez my RADIUS server. Il s'agit du paramètre essentiel qui indique à Meraki d'authentifier les utilisateurs auprès d'un serveur RADIUS externe avant d'accorder l'accès au réseau. Juste en dessous, vous verrez l'option Captive portal strength. Configurez-la sur Block all access until sign-on is complete. C'est ce qui applique le walled garden - sans cela, les visiteurs pourraient contourner complètement le Captive Portal.
Étape trois : Configuration du serveur RADIUS. Dans la section RADIUS, cliquez sur Add server. Vous aurez besoin de trois informations provenant de votre compte Purple : l'adresse IP ou le FQDN du serveur RADIUS, le port d'authentification qui est l'UDP 1812, et le secret partagé. Purple fournit ces informations dans la section de configuration de l'établissement du portail. Pour garantir la redondance dans les déploiements de production, vous devez ajouter un serveur RADIUS secondaire - Purple fournit un point de terminaison de basculement. Configurez le port de comptabilité sur UDP 1813 si vous souhaitez que les données de session soient transmises au moteur d'analyse de Purple, ce que je recommande vivement pour tout établissement où le temps de séjour et la durée des sessions sont des indicateurs significatifs.
Un mot rapide sur les attributs RADIUS. Meraki respecte l'attribut Session-Timeout renvoyé dans la réponse RADIUS Access-Accept. Purple l'utilise pour contrôler la durée d'une session visiteur avant qu'une ré-authentification ne soit requise. Pour un hôtel, vous pouvez configurer cela sur 86 400 secondes - soit 24 heures. Pour un café, une durée d'environ 3 600 secondes, soit une heure, est plus appropriée. L'attribut Idle-Timeout est également respecté, mais uniquement si la comptabilité RADIUS est activée. Cela déconnecte les sessions inactives, ce qui est important pour la gestion de la capacité dans les établissements à forte densité.
Étape quatre : URL de la page de connexion. Accédez à Wireless, puis Configure, puis Splash page. Sélectionnez votre SSID visiteur dans le menu déroulant. Configurez l'option Custom splash URL avec l'URL du portail Purple pour votre établissement. C'est l'URL vers laquelle Meraki redirigera les clients non authentifiés. Meraki ajoute des paramètres de requête à cette URL - y compris un paramètre login_url - que Purple utilise pour finaliser la négociation d'authentification. Ne modifiez pas et ne supprimez pas ces paramètres.
Étape cinq : le walled garden. C'est là que la plupart des déploiements rencontrent des difficultés. Le walled garden est la liste des domaines et des plages d'adresses IP qu'un appareil visiteur peut atteindre avant de s'être authentifié. Sans les entrées correctes, la page du Captive Portal elle-même ne se chargera pas, car le navigateur sera bloqué et ne pourra pas atteindre le CDN de Purple ni les fournisseurs de connexion sociale.
Retournez dans le menu Access Control pour votre SSID invité. Définissez Walled garden sur Walled garden is enabled. Dans le champ Walled garden ranges, vous devez ajouter les éléments suivants. Premièrement, les domaines de la plateforme Purple : star point purple point ai, et star point venuewifi point com. Deuxièmement, les domaines CDN que Purple utilise pour héberger les ressources du portail : star point cloudfront point net, et star point akamaihd point net. Troisièmement, l'infrastructure de redirection Meraki : star point network-auth point com. Quatrièmement, si vous proposez des options de connexion via les réseaux sociaux, vous devez ajouter les domaines OAuth correspondants. Pour Google : accounts point google point com, star point googleapis point com, star point gstatic point com. Pour Facebook : star point facebook point com, star point fbcdn point net, et connect point facebook point net. Pour Twitter ou X : star point twitter point com et star point twimg point com.
Une remarque importante sur la façon dont Meraki gère les domaines avec caractères génériques (wildcards) dans le walled garden. Meraki prend en charge les entrées avec caractères génériques en utilisant le préfixe astérisque, par exemple star point cloudfront point net. Cependant, il s'agit d'une correspondance basée sur le DNS - Meraki résout le domaine et autorise les adresses IP résultantes. Cela signifie que pour les fournisseurs de CDN comme CloudFront ou Akamai, où les IP résolues peuvent changer fréquemment, vous devez utiliser le caractère générique du domaine plutôt que des plages d'adresses IP statiques. Les entrées d'adresses IP statiques conviennent parfaitement pour les points de terminaison RADIUS de Purple, qui sont stables, mais pas pour le trafic CDN.
Parlons maintenant de deux scénarios réels sur lesquels j'ai travaillé directement.
Le premier concerne un hôtel de 350 chambres au Royaume-Uni. Le client utilisait des points d'accès Meraki MR46 répartis sur trois bâtiments, avec environ 400 appareils invités connectés simultanément aux heures de pointe. Le déploiement initial utilisait une page d'accueil par simple clic - sans RADIUS, uniquement l'acceptation des conditions d'utilisation. Le problème était qu'ils n'avaient aucune visibilité sur l'identité des personnes connectées, aucune collecte d'e-mails et aucun moyen de mener des campagnes marketing après le séjour. Nous les avons migrés vers Purple avec une authentification basée sur RADIUS. La configuration était simple, mais le piège résidait dans le fait que leur pare-feu en amont bloquait le trafic UDP sortant sur le port 1812 vers tout ce qui se trouvait en dehors du sous-réseau local. Une fois que nous avons ajouté les plages d'adresses IP du tableau de bord Meraki à la liste d'autorisation du pare-feu, l'authentification a fonctionné immédiatement. Après le déploiement, l'hôtel a collecté les adresses e-mail de près de 68 % des invités connectés au cours du premier mois, et leur équipe marketing a mené une campagne de réengagement qui a généré une augmentation mesurable des réservations directes.
Le second scénario est une chaîne de vente au détail de 45 magasins, chacun équipé de points d'accès Meraki MR33. Le défi ici résidait dans l'échelle et la cohérence. Configurer manuellement 45 SSID avec les paramètres RADIUS et les listes de walled garden appropriés aurait été source d'erreurs et extrêmement chronophage. La solution a été d'utiliser la configuration basée sur les modèles de Meraki. Nous avons créé un modèle de réseau unique avec les paramètres SSID, RADIUS et de walled garden appropriés, puis nous avons lié les 45 réseaux de magasins à ce modèle. Tout changement, comme l'ajout d'un nouveau fournisseur de connexion sociale au walled garden, est effectué une seule fois dans le modèle et se propage automatiquement à tous les magasins. Les outils d'analyse de Purple ont ensuite agrégé les données de fréquentation et de temps de séjour de tous les magasins, offrant à l'équipe des opérations commerciales une vue unique sur un tableau de bord du comportement des visiteurs par magasin, par région et par heure de la journée.
Voici trois règles d'or qui vous feront gagner du temps sur chaque déploiement de Captive Portal Meraki.
Règle numéro un : Vérifiez toujours les plages IP du tableau de bord Meraki avant de configurer RADIUS. Les plages changent occasionnellement, et si votre pare-feu les bloque, l'authentification échouera silencieusement du point de vue de l'utilisateur - la page du portail restera simplement bloquée. Utilisez l'outil de test RADIUS intégré dans le tableau de bord sous la section Contrôle d'accès pour vérifier la connectivité avant la mise en service.
Règle numéro deux : Utilisez des domaines génériques (wildcards) dans le walled garden, et non des plages IP, pour tout contenu hébergé sur un CDN. Les plages IP des CDN sont vastes et changent fréquemment. Une entrée de domaine générique est plus facile à maintenir et plus fiable.
Règle numéro trois : Activez la comptabilité RADIUS sur le port 1813, même si vous pensez ne pas en avoir besoin pour le moment. Les données de session sont précieuses pour résoudre les problèmes de déconnexion et pour transmettre des indicateurs précis de temps de séjour à votre plateforme d'analyse. Cela ne coûte rien à activer et est très difficile à mettre en œuvre rétroactivement.
Voici maintenant quelques questions rapides qui me sont régulièrement posées.
Puis-je utiliser la page d'accueil intégrée de Meraki au lieu de Purple ? Oui, mais vous perdez la capture de données, les analyses, l'automatisation du marketing et la gestion des consentements conforme au GDPR. La page d'accueil intégrée convient pour un simple clic d'accès, mais ce n'est pas une plateforme d'intelligence client.
Cette configuration fonctionne-t-elle sur les pare-feux Meraki MX ainsi que sur les points d'accès MR ? La configuration de la page d'accueil RADIUS est prise en charge sur les points d'accès MR. Les équipements MX gèrent l'authentification VPN client différemment. Pour le WiFi invité spécifiquement, vous configurez les SSID des MR.
Qu'en est-il de WPA3 ? Les points d'accès Meraki MR prennent en charge WPA3 sur les SSID d'entreprise. Pour les déploiements de Captive Portal d'invités, le SSID est généralement Open, donc WPA3 ne s'applique pas directement. Cependant, si vous déployez un SSID Passpoint ou OpenRoaming aux côtés de votre SSID de Captive Portal - ce que Purple prend en charge - ce SSID utilise WPA3-Enterprise avec 802.1X, et c'est là que WPA3 devient pertinent.
En résumé : l'intégration entre Cisco Meraki et Purple est éprouvée et fiable, mais elle nécessite une attention particulière sur trois points : le routage de l'adresse IP source RADIUS, l'exhaustivité du walled garden et la configuration du délai d'expiration de la session. Maîtrisez ces trois aspects et le déploiement se fera sans encombre. L'intérêt commercial est évident - les établissements qui déploient une plateforme de WiFi invité correctement configurée avec capture de données constatent régulièrement des retours mesurables en termes d'engagement marketing et d'analyses opérationnelles.
Si vous souhaitez approfondir le sujet, consultez le guide de Purple sur l'implémentation de l'authentification 802.1X avec cloud RADIUS, ainsi que notre guide de déploiement des AP Cisco Wireless sur le blog de Purple. Les deux liens sont disponibles dans les notes de l'émission.
Merci pour votre écoute. Si vous avez un scénario de déploiement spécifique que vous aimeriez que nous abordions, contactez l'équipe technique de Purple. À bientôt dans le prochain épisode.
