Dépannage du Captive Portal Cisco Meraki : check-list pour splash page, walled garden et RADIUS

Un Captive Portal Meraki qui échoue présente généralement l'un des quatre défauts suivants. Le type de splash page est incorrect, ou le walled garden ne contient pas les domaines et les ressources du portail. Le transfert de l'URL d'autorisation peut être rompu, ou les points d'accès ne peuvent pas joindre le RADIUS avec un secret partagé correspondant. Le journal d'événements Meraki indique quel est le défaut.

À quoi ressemble un Captive Portal Meraki qui ne fonctionne pas ?

Trois symptômes couvrent la plupart des tickets de support. Chacun d'eux pointe vers un maillon différent de la chaîne de connexion.

• La splash page n'apparaît jamais. L'appareil rejoint l'SSID et obtient une adresse IP, mais aucune invite de connexion ne s'ouvre.
• Le portail tourne en boucle. L'invité remplit le formulaire, appuie sur connecter et revient sur la page de connexion.
• Le portail accepte les informations mais n'accorde jamais l'accès. La page indique que l'opération a réussi, mais l'appareil reste captif.

Un quatrième symptôme est plus discret. Les invités de retour sont invités à se connecter beaucoup plus souvent que prévu. C'est rarement un défaut de portail. Il s'agit généralement du paramètre de fréquence de la splash page.

Avant de modifier quoi que ce soit, confirmez le fonctionnement théorique de la chaîne. Sur un déploiement Purple, le point d'accès Meraki redirige l'appareil vers les serveurs de la splash page de Purple. La splash page collecte les informations de l'invité et génère une connexion unique. Le point d'accès transmet ensuite cette connexion au serveur RADIUS de Purple pour finaliser l'authentification. L'article de support Purple captive portal support article décrit ce flux. Chaque symptôme correspond à l'échec de l'un de ces trois transferts.

Ce guide part du principe que l'SSID est déjà configuré. Il complète le guide de configuration du Captive Portal Meraki et ne répète pas les étapes d'installation.

Qu'est-ce qui empêche généralement une splash page Meraki de s'afficher ou la fait tourner en boucle ?

Le type de splash page ne correspond pas au portail

Meraki propose des options de clic unique, de connexion avec un serveur RADIUS et de Captive Portal externe. Le portail et l'SSID doivent s'attendre à la même méthode.

Un portail externe en clic unique libère l'appareil en appelant une URL d'autorisation. Un portail externe avec connexion transmet les identifiants, que le point d'accès vérifie auprès du RADIUS. Si l'SSID et le portail ne concordent pas, le transfert échoue et l'invité tourne en boucle.

Le walled garden est incomplet

Le walled garden liste les destinations qu'un appareil peut atteindre avant de s'authentifier. Meraki accepte les entrées sous forme de domaines ou de plages d'adresses IP. Si le domaine propre du portail est manquant, la splash page ne peut pas du tout se charger.

Les ressources manquantes causent des défauts plus subtils. Les feuilles de style, les images, les polices, les réseaux de diffusion de contenu et les fournisseurs de connexion sociale se chargent tous à partir de leurs propres hébergeurs. Si l'un d'eux est bloqué, la page s'affiche de manière incorrecte ou le bouton de connexion ne fonctionne pas.

Le walled garden peut également être trop permissif. Les appareils exécutent un Captive Network Assistant (CNA), qui interroge un domaine prédéfini pour tester l'accès à internet. Si ce domaine de test est accessible avant la connexion, l'appareil en conclut qu'il est en ligne. Il n'affiche alors jamais l'invite de connexion.

L'URL d'autorisation ou l'URL de continuation est perdue

Avec un Captive Portal externe, Meraki ajoute des paramètres à la redirection. Ceux-ci incluent une URL d'autorisation de base (grant URL) et l'URL de continuation initialement demandée par l'invité. Le portail doit renvoyer l'appareil vers l'URL d'autorisation pour libérer son accès.

Si le portail perd, réécrit ou met en cache ces paramètres, le point d'accès ne reçoit jamais l'autorisation. L'invité voit un message de réussite, puis le chargement de la page suivante le redirige à nouveau vers la page de connexion.

RADIUS est injoignable ou le secret partagé est incorrect

L'authentification avec RADIUS dépend de la capacité des points d'accès à atteindre le serveur RADIUS. RADIUS est le protocole Remote Authentication Dial-In User Service, défini dans la norme RFC 2865. Le serveur traite chaque expéditeur comme un client RADIUS et vérifie un secret partagé à chaque requête.

Deux pannes prédominent. Soit un pare-feu bloque le trafic RADIUS provenant des points d'accès, soit le secret partagé diffère entre le tableau de bord et le serveur. Dans les deux cas, le portail collecte les informations mais l'authentification ne se termine jamais.

Le mode NAT et le mode pont (bridge) modifient les éléments à vérifier

En mode NAT, le point d'accès attribue lui-même les adresses des clients. Les appareils en amont voient le trafic provenir du point d'accès, et non du client. En mode pont (bridge), les clients obtiennent leurs adresses depuis votre serveur DHCP sur votre réseau local LAN ou VLAN.

Le mode pont ajoute des points de défaillance qui dépendent de votre infrastructure. Ceux-ci incluent une plage DHCP épuisée, un VLAN non acheminé (trunked) vers le point d'accès, ou des règles de DNS amont ou de pare-feu bloquant les hôtes du portail.

Comment identifier la cause du problème ?

Procédez en partant du client vers l'extérieur. Testez avec un seul appareil, et oubliez le réseau entre chaque tentative pour que chaque test démarre de zéro.

Symptôme	Ce que montre le journal d'événements	Cause la plus probable	Première vérification
Aucune page d'accueil n'apparaît	Association, mais pas de redirection de page d'accueil	Domaine de test CNA accessible, ou panne DHCP ou DNS	Confirmer que l'appareil a une IP et un DNS, puis ouvrir neverssl.com
Page d'accueil vide ou sans style	Redirection de page d'accueil, page incomplète	Walled garden manquant de serveurs d'hébergement de ressources	Outils de développement du navigateur, lister chaque hôte bloqué
Boucle infinie après validation	Redirections répétées vers la page d'accueil, pas d'autorisation	Paramètres de l'URL d'autorisation perdus, ou incompatibilité de type de page d'accueil	Comparer la chaîne de requête de redirection avec ce que le portail renvoie
Message de réussite, pas d'internet	Tentatives d'authentification échouées ou expirées	RADIUS bloqué ou secret partagé incorrect	Journaux du serveur RADIUS pour les requêtes provenant des points d'accès
Invités récurrents à nouveau sollicités	Nouveaux événements de page d'accueil pour des appareils connus	Fréquence de la page d'accueil trop courte	Paramètre de fréquence de la page d'accueil sur le SSID
Alerte de certificat sur ordinateur	Redirection terminée	Page de connexion fournie via HTTP	Certificat sur l'hôte du portail

Lire le journal d'événements Meraki

Ouvrez le journal d'événements réseau dans le tableau de bord Meraki et filtrez par l'adresse MAC de l'appareil de test. Filtrez ensuite par types d'événements de page d'accueil (splash) et d'authentification. Lisez les événements dans l'ordre chronologique : association, attribution d'adresse, redirection vers la page d'accueil, authentification. Le point où la séquence s'arrête est l'endroit où se situe le problème. L'absence d'événement de redirection signifie que la redirection ne s'est jamais déclenchée. Un événement de redirection sans événement d'authentification pointe vers le portail ou l'URL d'autorisation. Un événement d'authentification ayant échoué pointe vers le RADIUS.

Comment résoudre le problème sur les réseaux Meraki MR et les appareils clients ?

Suivez les étapes du fournisseur dans l'article de support Purple sur le captive portal. Les solutions ci-dessous vous indiquent ce qu'il faut modifier et pourquoi.

Corriger le walled garden

Chargez la page de connexion sur un appareil en dehors du réseau invité, avec les outils de développement ouverts. Enregistrez chaque hôte appelé par la page, y compris les fournisseurs de connexion sociale. Ajoutez chacun d'eux au walled garden en tant que domaine ou plage d'adresses IP. Supprimez tout ce qui correspond à un domaine de test CNA.

Corriger le transfert de l'URL d'autorisation

Capturez l'URL de redirection complète depuis un appareil en échec. Vérifiez que le portail renvoie bien l'appareil vers l'URL d'autorisation de base avec les paramètres intacts. Vérifiez qu'aucun proxy, réducteur de lien ou cache ne se trouve entre le portail et l'appareil.

Corriger le RADIUS

Vérifiez que les points d'accès peuvent atteindre le serveur RADIUS sur les ports configurés. Saisissez à nouveau le secret partagé des deux côtés, à partir d'une seule copie, en même temps. Vérifiez ensuite le journal du serveur pour voir si des requêtes proviennent des adresses des points d'accès.

Corriger le comportement des clients

Android affiche une notification indiquant "vous devrez peut-être vous connecter" qui ouvre le CNA. Certains fabricants de téléphones modifient ce comportement, effectuez donc des tests sur les modèles que possèdent vos invités. Si un invité manque l'invite, Purple recommande d'ouvrir un navigateur et de visiter neverssl.com. Ce site évite les problèmes de redirection SSL car il n'utilise jamais HTTPS.

Les navigateurs de bureau affichent un avertissement lorsqu'une page de connexion est diffusée via HTTP simple. L'article sur le certificat Cisco WLC de Purple traite du défaut équivalent sur les Cisco WLCs. La solution consiste à utiliser un certificat publiquement approuvé dont le Common Name correspond au nom d'hôte du portail. Le même principe s'applique à tout hôte de portail.

Autres fournisseurs

Purple est indépendant du matériel. Les mêmes vérifications s'appliquent sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Seuls les noms des menus diffèrent.

Deux scénarios concrets

Un hôtel de 200 chambres après une refonte du portail

Situation. Un établissement du secteur hospitality en centre-ville a renouvelé sa page de connexion avec de nouvelles polices et un bouton de connexion sociale. Ensuite, les clients ont vu une page blanche sans bouton de connexion.

Ce qui a été fait. L'équipe informatique a chargé la nouvelle page avec les outils de développement ouverts et a trouvé deux hôtes bloqués. L'un était un réseau de diffusion de polices. L'autre était le fournisseur de connexion sociale. Les deux ont été ajoutés au walled garden.

Résultat. La page s'est affichée complètement lors du test suivant. Les plaintes à la réception concernant l'accès WiFi des invités ont cessé le jour même.

Une chaîne de vente au détail de 40 magasins après une modification du pare-feu

Situation. Une chaîne de distribution a renforcé le pare-feu de son siège social. Le lendemain matin, les clients de chaque magasin voyaient la page de succès mais ne pouvaient pas naviguer.

Ce qui a été fait. Le journal d'événements affichait des expirations de délai d'authentification sur chaque site. La nouvelle règle avait bloqué le trafic RADIUS provenant des points d'accès des magasins. L'équipe a rétabli la règle uniquement pour les ports RADIUS.

Résultat. Les événements d'authentification sont revenus à la normale dans l'ensemble des 40 magasins dans l'heure qui a suivi le changement.

Comment éviter que les pannes de Captive Portal Meraki ne se reproduisent ?

• Liez le walled garden aux modifications du portail. Chaque changement de conception déclenche une révision du walled garden avant la mise en ligne.
• Gardez le SSID ouvert. Purple recommande un réseau ouvert pour l'accès invité, car cette convention est familière et réduit les frictions.
• Renouvelez les secrets partagés par paires. Modifiez le tableau de bord et le serveur RADIUS au cours de la même fenêtre de maintenance.
• Testez sur quatre plateformes. Android, iOS, Windows et macOS gèrent chacun le CNA différemment.
• Utilisez un certificat de confiance. Diffusez la page de connexion via HTTPS avec un certificat publiquement approuvé.
• Séparez le personnel des invités. Le personnel doit s'authentifier par identité, et non via une page de connexion invité. Voir Comment activer le Single Sign On.

Purple gère le WiFi invité dans plus de 80 000 sites actifs et a traité 440 millions de connexions en 2024 (données internes de Purple). La même liste de contrôle s'applique aux hubs de transport accueillant des passagers et aux sites de santé accueillant des patients et des visiteurs.

Questions fréquemment posées

Est-ce que Purple fonctionne avec mes points d'accès Cisco Meraki existants ?

Oui, Purple fonctionne sur vos points d'accès Cisco Meraki MR existants sous forme de superposition cloud. Vous dirigez la page de connexion du SSID vers Purple et configurez les paramètres RADIUS de Purple dans le tableau de bord Meraki. Aucun nouveau matériel n'est requis. L'article de support du Captive Portal de Purple détaille les étapes de configuration. La même approche fonctionne sur le reste d'un parc mixte.

Purple peut-il gérer le WiFi invité sur un parc de fournisseurs mixtes ?

Oui, Purple est indépendant du matériel et prend en charge Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Vous gérez une seule page de connexion et un seul flux d'authentification pour tous les fournisseurs, depuis une plateforme unique. Cela convient parfaitement aux groupes ayant acquis des sites équipés de matériels différents. Cela convient également aux parcs prévoyant de remplacer les points d'accès progressivement plutôt qu'en un seul projet.

L'accès invité doit-il fonctionner sur un SSID ouvert ou sécurisé ?

Purple recommande un SSID ouvert pour l'accès invité, car c'est désormais la convention standard et les invités la reconnaissent. Le Captive Portal gère l'étape de connexion, de sorte que les invités n'ont pas besoin de mot de passe avant de se connecter. Un réseau ouvert réduit les frictions au moment de la connexion. Maintenez les appareils du personnel sur un réseau distinct, basé sur l'identité, plutôt que de partager le SSID invité.

Les données des visiteurs collectées via la page de connexion sont-elles conformes au GDPR ?

Oui, Purple est certifié ISO 27001 et Cyber Essentials, et fonctionne conformément aux réglementations GDPR et CCPA. Les visiteurs expriment un choix d'adhésion conscient sur la page de connexion, le consentement marketing est donc explicite. Les données que vous collectez sont des données de première partie, détenues par votre organisation. Purple est également certifié B Corp. Assurez-vous que votre propre politique de confidentialité correspond aux champs collectés par votre page de connexion.

Pourquoi les navigateurs de bureau affichent-ils un avertissement de certificat avant la page de connexion ?

Les navigateurs de bureau affichent un avertissement lorsque le portail redirige vers une page de connexion via une simple liaison HTTP. Les navigateurs modernes s'attendent à ce que les pages de connexion utilisent HTTPS, ils signalent donc la connexion comme non privée. La solution consiste à installer un certificat SSL/TLS publiquement approuvé sur l'hôte du portail. Le nom commun du certificat doit correspondre au nom d'hôte utilisé par la redirection. L'avertissement ne bloque pas l'accès, mais il nuit à la confiance des visiteurs.

Qui gère l'authentification RADIUS lorsque Purple exécute le portail ?

Le serveur RADIUS de Purple finalise la connexion. La page de connexion génère une connexion unique, et la borne d'accès Meraki la transmet au serveur RADIUS de Purple. Vous saisissez les informations RADIUS de Purple et le secret partagé dans le tableau de bord Meraki. Votre pare-feu doit autoriser le trafic RADIUS provenant des bornes d'accès vers Purple. Si le secret partagé diffère d'un côté ou de l'autre, l'authentification échoue.

Quel effort représente la transition de la page de connexion Meraki vers Purple ?

La transition est un simple changement de configuration sur chaque SSID, et non un projet matériel. Vous modifiez le type de page de connexion, ajoutez les entrées du walled garden et saisissez les informations RADIUS de Purple. La majeure partie de l'effort consiste à tester la solution sur Android, iOS, Windows et macOS avant le déploiement. Prévoyez d'abord un site pilote, puis appliquez les paramètres testés au reste du parc.