Passer au contenu principal

La page splash de Cisco Meraki ne fonctionne pas : un organigramme de dépannage

Ce guide pratique de jour 2 isole l'endroit où un flux de splash Cisco Meraki a échoué : autorisation du client, initiation de la redirection HTTP, accessibilité du walled-garden ou connexion RADIUS. Il offre aux équipes informatiques sur site un parcours de preuve contrôlé, afin qu'elles puissent rétablir le WiFi invité sans modifier l'ensemble du réseau en production.

By Marketing TeamPublished
📖 12 min de lecture3,455 mots2 exemples concrets10 définitions clés

Écouter ce guide

Voir la transcription du podcast
Introduction et contexte Si votre page de splash Cisco Meraki a cessé de s'afficher, résistez à l'envie de la reconstruire. Dans un déploiement fonctionnel, la page n'est qu'une étape d'une chaîne. L'appareil doit rejoindre l'SSID prévu, recevoir un adressage réseau utilisable, être traité comme non autorisé, lancer le chemin de redirection, atteindre les services de pré-authentification autorisés et, pour l'accès par connexion, finaliser l'échange RADIUS. Ce guide vous offre un parcours contrôlé pour diagnostiquer un service Cisco Meraki Guest WiFi établi. Il ne s'agit pas d'un guide de configuration. Vous devez documenter l'incident avec des preuves désignant l'étape en échec, la prochaine équipe responsable et le changement à effectuer. Analyse technique approfondie Commencez par un seul appareil. Enregistrez son adresse MAC, l'SSID, le point d'accès ou la passerelle MX, l'heure locale, le navigateur et si l'appareil avait déjà utilisé le réseau. Si vous ne pouvez pas reproduire le problème sur un client spécifique, vous ne pouvez pas faire confiance au résultat d'une modification de configuration à l'échelle du parc. Dans l'affichage des détails du client Cisco Meraki, vérifiez son statut de splash. Un appareil non autorisé est éligible pour un nouveau flux de splash. Un appareil autorisé peut ne pas l'être. C'est important lorsque les utilisateurs signalent que la fréquence du splash a été ignorée. Un appareil autorisé sous la fréquence précédente peut conserver cette période d'autorisation après le changement de paramètre. Pour un test correct, révoquez l'autorisation uniquement sur l'appareil de test désigné, puis relancez le flux. Utilisez maintenant le journal d'événements Meraki comme une chronologie plutôt que comme une liste d'erreurs. Filtrez d'abord par l'adresse MAC du client, puis ciblez la plage horaire autour de l'échec signalé. Pour les points d'accès MR, surveillez les catégories 802.11, Auth, DHCP et RADIUS. Sur MX, utilisez Auth et RADIUS selon le cas. L'ordre des étapes est essentiel. Une association 802.11 prouve que l'appareil a rejoint un point d'accès. Elle ne prouve pas que l'appareil a obtenu une adresse IP, atteint votre Captive Portal ou accédé à Internet. Si l'association est manquante, ou si des désassociations répétées interrompent le test, vous avez un problème de connexion sans fil avant d'avoir un problème de Captive Portal. Ne demandez pas encore à l'équipe de la page d'enquêter. Ensuite, recherchez des preuves DHCP. Un client qui n'a pas reçu d'adressage valide ne peut pas lancer le flux de splash de manière fiable. Si les erreurs DHCP sont regroupées sur un seul SSID ou point d'accès, inspectez l'adressage du client et le chemin du VLAN. Cisco Meraki identifie le marquage VLAN du SSID et du commutateur en amont comme des zones d'investigation DHCP courantes. Corrigez cela avant de modifier la fréquence du splash ou la configuration RADIUS. Une fois l'association et l'adressage confirmés, déterminez si vous testez un client autorisé ou non autorisé. S'il est autorisé, l'absence de page peut être tout à fait normale. Révoquez l'autorisation du client de test désigné et recommencez le test. La branche suivante capture une grande partie des échecs de redirection apparents. Cisco Meraki lance la redirection vers la page de splash lorsqu'un appareil non autorisé envoie un HTTP GET. Le point d'accès intercepte cette requête et redirige le navigateur vers l'URL de splash. Pour l'HTTPS, c'est différent. La requête étant chiffrée, le point d'accès ne peut pas la remplacer par une redirection vers la page de splash. Une requête de navigateur orientée HTTPS-first peut expirer au lieu de charger la page de splash. Testez donc le déclencheur délibérément. Confirmez que le navigateur accepte les cookies. Effacez le cache du navigateur uniquement si cela correspond à votre procédure opérationnelle. Ouvrez ensuite une destination HTTP sur l'appareil de test non autorisé. Si la page apparaît, le mécanisme de Captive Portal fonctionne. Documentez le comportement du client. La bonne réponse n'est pas d'affaiblir la sécurité ou de promettre que chaque requête HTTPS-first sera redirigée. Si la page reste vide, vérifiez à nouveau les cookies. Cisco Meraki identifie les cookies désactivés comme une cause de page vide. La page de splash s'appuie sur l'état de session du navigateur. Un navigateur configuré pour rejeter les cookies peut produire des symptômes qui ressemblent à un défaut d'hébergement. Si la page commence à se charger mais manque de style, d'images, d'éléments de formulaire ou de son service d'identité, passez au walled garden. Ce sont les destinations qu'un appareil non autorisé peut atteindre. Examinez l'hôte de la page, puis uniquement les points de terminaison d'actifs, d'authentification et de service nécessaires avant l'autorisation. Cisco Meraki prend en charge les noms d'hôte, les adresses IP, les plages et les domaines génériques, tandis qu'une URL de splash personnalisée doit être autorisée. Pour une page hors ligne Purple, cette limite est importante. Le visiteur reste dans le walled garden et ne peut pas utiliser de liens externes ou de ressources distantes. Comparez chaque nouvelle dépendance de page avec la politique de pré-authentification. Le téléchargement d'actifs dans le modèle de splash peut être plus propre. Ce n'est qu'après le chargement fiable de la page que vous devez enquêter sur le RADIUS. Le RADIUS est pertinent pour une page de splash d'authentification qui se charge mais rejette les identifiants, tourne en boucle ou signale une expiration de délai. Ce n'est pas votre premier suspect lorsqu'aucune page n'apparaît. Cisco Meraki clarifie un point très important. Pour une page de splash d'authentification utilisant votre serveur RADIUS, la requête RADIUS provient du cloud Dashboard. Elle ne provient pas de l'AP ou du MX local. Cela affecte tout le parcours de dépannage. Une adresse LAN privée pour le serveur RADIUS ne pourra pas servir ce flux. Le service doit être accessible à partir des plages sources documentées du Dashboard, les sources concernées doivent être reconnues comme clients RADIUS, et le secret partagé doit correspondre. La méthode d'authentification est également importante. Cisco Meraki documente le PAP pour ce flux de splash d'authentification et indique que RADSec n'est pas pris en charge. Validez votre politique RADIUS par rapport à ce mode documenté. Ne supposez pas que la politique conçue pour un déploiement WiFi d'entreprise distinct s'appliquera sans modification. Cisco fournit également un test RADIUS Dashboard pour la configuration sans fil documentée. Utilisez-le là où il est disponible, puis inspectez les propres journaux du serveur RADIUS pour déterminer si la requête est arrivée, a été rejetée ou n'a reçu aucune réponse. Recommandations d'implémentation et pièges à éviter Intégrez cette séquence de diagnostic dans votre manuel opérationnel. Incluez l'appareil de test désigné, la limite d'approbation pour révoquer son autorisation, l'hôte splash attendu, la liste des dépendances du walled-garden, le propriétaire du service RADIUS et les contacts d'escalade. Chaque site doit savoir qui détient le contenu de la page, la configuration réseau et la politique d'authentification. Cela évite qu'une équipe de réception, un MSP et une équipe d'identité n'effectuent tous des modifications non coordonnées. Ne modifiez pas la fréquence d'affichage du splash pour forcer un test. Révoquez plutôt un client de test. N'utilisez pas le résultat d'un seul navigateur comme preuve d'une panne. Comparez un appareil de test propre avec l'appareil concerné. N'ajoutez pas d'accès Internet pré-authentification illimité sous prétexte qu'une page personnalisée est défectueuse. Identifiez précisément la dépendance. Ne considérez pas un événement RADIUS comme la preuve que le visiteur a accédé à la page. Suivez la séquence : association, adressage, état non autorisé, déclenchement HTTP, accessibilité de la page et authentification de connexion. Questions rapides Pourquoi la page s'affiche-t-elle trop souvent ? Vérifiez les cookies, le cache du navigateur et si le point d'accès de la passerelle a redémarré. Ces éléments affectent l'état que Cisco Meraki utilise pour l'expérience de splash. Pourquoi s'affiche-t-elle trop rarement ? L'appareil est peut-être encore autorisé selon une fréquence antérieure. Révoquez le client de test contrôlé et testez à nouveau. Pourquoi le Guest WiFi ne redirige-t-il pas ? Confirmez que le client est non autorisé, qu'il dispose d'un adressage valide et qu'il teste une requête HTTP. Une requête HTTPS-first ne peut pas déclencher la même redirection. Pourquoi la connexion expire-t-elle ? Validez l'accessibilité entre le Dashboard et RADIUS, les plages sources actuelles, les entrées des clients RADIUS, l'alignement des secrets partagés, la prise en charge de PAP et la politique du serveur. Que signifient les événements d'authentification ? Ils marquent la catégorie d'authentification du splash. Analysez-les en parallèle des enregistrements d'association, DHCP et RADIUS, et non de manière isolée. Un scénario pratique sur site illustre bien ce point. Une équipe d'exploitation de centre de conférences signale que les téléphones des participants se connectent au Guest WiFi mais que la page de connexion semble incomplète. L'équipe réseau choisit un terminal, enregistre son adresse MAC et confirme l'association, le DHCP et l'état de splash non autorisé. Un test HTTP ouvre la page, mais son élément d'identité externe ne se charge pas. Cela exclut RADIUS du chemin de panne immédiat. L'équipe examine la liste des dépendances de pré-authentification et constate que le nouvel élément de la page n'a pas été inclus dans la révision du walled-garden. Elle corrige la dépendance approuvée, répète le test et enregistre l'autorisation réussie. La leçon n'est pas que chaque page splash défectueuse nécessite une nouvelle entrée dans le walled-garden. La leçon est de valider l'étape en premier lieu. Un autre site pourrait présenter le même symptôme pour les visiteurs parce qu'un déclencheur HTTP n'a pas eu lieu, ou parce que le cloud du Dashboard ne peut pas joindre le serveur RADIUS. Ce processus permet de séparer rapidement ces défaillances. Résumé et prochaines étapes Un problème de page d'accueil Cisco Meraki est généralement une étape interrompue, pas une page en panne. Prouvez que l'appareil a rejoint le bon réseau. Prouvez qu'il dispose d'un adressage valide. Confirmez s'il est réellement non autorisé. Déclenchez le flux avec HTTP. Examinez le walled garden uniquement pour les dépendances requises avant la connexion. Ensuite, étudiez l'authentification Dashboard-to-RADIUS si la page de connexion elle-même échoue. Cette approche protège le fonctionnement de votre site. Elle évite un changement précipité qui perturberait les autres clients tout en fournissant à l'équipe réseau des preuves qu'elle peut reproduire. Conservez l'organigramme avec le manuel d'exploitation du service, testez-le après chaque modification planifiée de page ou d'identité, et veillez à ce que chaque escalade inclue l'adresse MAC du client, l'heure, l'SSID, la passerelle et les preuves de journalisation. C'est ainsi que vous transformez « la page d'accueil ne fonctionne pas » en un incident technique résoluble.

Fait partie de notre série principale : Guide du Captive Portal

La page splash de Cisco Meraki ne fonctionne pas : un organigramme de dépannage

Les portails de connexion Cisco Meraki cessent de s'afficher lorsqu'un client est toujours autorisé, ne peut pas émettre la requête HTTP qui déclenche la redirection, ne peut pas atteindre une dépendance autorisée pour le portail, ou ne peut pas terminer l'authentification RADIUS. Commencez avec un seul client affecté, filtrez les enregistrements Auth, DHCP et RADIUS par son adresse MAC, puis testez l'étape correspondante ci-dessous. 1 2 3 5

Qu'est-ce qui doit obligatoirement fonctionner pour qu'un portail Cisco Meraki s'affiche ?

Considérez un Captive Portal comme une chaîne d'événements, et non comme une simple page web. Un appareil doit s'associer au bon SSID, obtenir un adressage valide, être classé comme non autorisé, envoyer du trafic capable d'initier le flux du portail, atteindre le service hébergé requis, puis recevoir l'autorisation. Cisco Meraki décrit le déclencheur comme un HTTP GET provenant d'un client non autorisé. Le point d'accès intercepte cette requête et renvoie une redirection HTTP 307 vers l'URL du portail. 1

Cela explique un appel d'assistance fréquent : un utilisateur invité peut se connecter à votre WiFi mais signale que la page de connexion ne se charge pas. Le point d'accès fonctionne pourtant probablement comme prévu. Si l'appareil tente d'ouvrir en premier une destination uniquement HTTPS, la requête chiffrée ne peut pas être redirigée. Cisco Meraki identifie spécifiquement cela comme un scénario d'expiration de session (timeout) du navigateur. Testez la branche HTTP contrôlée avant de modifier le SSID, la conception de la page ou le serveur RADIUS. 2

Cette même rigueur évite une deuxième erreur classique : considérer chaque demande d'authentification répétée comme un échec de la page. La fréquence d'affichage du portail dépend de la politique d'autorisation. Cisco Meraki conserve l'état d'autorisation au niveau du point d'accès passerelle et du contrôleur cloud, tandis que le navigateur conserve un cookie de session. Un client dont la période d'autorisation est toujours valide peut ne pas voir la page s'afficher à nouveau après que vous avez réduit la fréquence configurée. À l'inverse, un client dont les cookies sont désactivés ou effacés peut être invité à s'authentifier trop souvent. 2

Ce que signale le client Première preuve à collecter Étape la plus probable Premier contrôle à effectuer
« Je me connecte mais aucune page ne s'ouvre » MAC du client, SSID, point d'accès et heure Déclencheur HTTP ou autorisation du client Confirmez Splash: Not authorized, puis naviguez vers une destination de test HTTP. 1 2
« Ça fonctionnait hier mais plus aujourd'hui » État d'autorisation et disponibilité récente du point d'accès Fréquence du portail ou état de la passerelle Comparez la date d'expiration avec l'état du client. Révoquez l'autorisation uniquement pour le client de test désigné. 2 3
« La page est vide » Paramètres des cookies du navigateur et type d'appareil État de la session du navigateur Activez les cookies et répétez le flux sur le même client. 2
« La page s'ouvre mais la connexion tourne en boucle ou échoue » Tentative de connexion, événements d'authentification et enregistrements RADIUS Accessibilité cloud-vers-RADIUS ou politique de sécurité Exécutez le test RADIUS du Dashboard là où Cisco Meraki le propose, puis vérifiez le pare-feu, la plage source et la correspondance du secret partagé. 4
“La page personnalisée n'a aucun style ou formulaire” Hôte de la page et chaque dépendance externe Walled garden Comparez la page personnalisée, les points de terminaison d'actifs et d'identité avec les entrées du walled garden. 3 7 8

Que devez-vous capturer avant de modifier quoi que ce soit ?

Commencez par un seul rapport reproductible. Enregistrez l'adresse MAC du client, l'SSID, le point d'accès passerelle ou MX, le type d'appareil, l'heure locale, le navigateur et si l'appareil avait déjà effectué une authentification splash. Demandez au déclarant de laisser l'appareil connecté pendant que vous l'inspectez. Cela vous donne une limite d'incident et évite qu'un hôtel, un site de vente au détail ou un lieu d'événement très fréquenté ne transforme une plainte générale en modifications de configuration à l'aveugle.

Ouvrez les détails du client et vérifiez s'il est autorisé. Cisco Meraki identifie un client non autorisé comme Splash: Not authorized ; un client autorisé affiche son temps d'autorisation restant. N'utilisez pas un onglet de navigateur enregistré pour votre test. Cela peut mélanger une session passée avec l'état radio et DHCP actuel. 1

Filtrez ensuite le journal des événements du Dashboard par l'adresse MAC du client et l'heure de l'incident. Pour les points d'accès MR, le type d'événement Auth représente l'authentification de la page splash. 802.11 indique l'association et la désassociation, DHCP porte les événements liés au bail, et RADIUS identifie l'activité RADIUS ou de contournement d'authentification MAC (MAC Authentication Bypass). Le même filtre Auth est disponible pour l'authentification splash MX. Cisco Meraki note que les appareils téléchargent les événements stockés après s'être reconnectés, tout en conservant les horodatages d'origine, alors alignez le fuseau horaire avant de décider de ce qui s'est passé en premier. 5

Utilisez l'enregistrement ordonné suivant. Il réduit le domaine de panne sans deviner.

Point de contrôle des preuves Indication saine S'il est absent ou incorrect Ce que cela vous indique
Association 802.11 Le client a rejoint l'AP et l'SSID attendus Pas d'association, désassociation répétée ou AP inattendu Diagnostiquez l'association radio avant le comportement du Captive Portal. 6
Adressage Une adresse client valide et aucune erreur DHCP à l'heure du rapport Erreur DHCP ou aucune configuration client utilisable Vérifiez l'adressage SSID/client et le chemin VLAN. 2 6
État Splash Le client n'est pas autorisé pour un nouveau test Le client reste autorisé Révoquez uniquement le client de test désigné, puis testez à nouveau. 2 3
Auth Un événement lié au splash s'aligne avec le test Aucun événement après le test HTTP Le déclencheur de redirection ou le test du client est incomplet. 5
Preuve RADIUS La tentative et la réponse s'alignent avec l'heure de connexion Expiration du délai, rejet ou absence de réponse Passez à la branche Dashboard-vers-RADIUS. 4 5

Comment exécuter l'organigramme de dépannage ?

La page splash de Cisco Meraki ne fonctionne pas : un organigramme de dépannage - splash troubleshooting flowchart

Utilisez l'organigramme une fois pour un client de test propre et une fois pour un client identifié comme affecté. La différence est utile. Si un client propre accède à la page de splash alors que l'appareil identifié n'y parvient pas, vous avez la preuve d'un problème d'autorisation, d'état du navigateur ou de politique propre au client, plutôt que d'une panne générale du site.

  1. Confirmez l'association et l'adressage. Si le journal d'événements n'indique pas que le client s'associe au SSID prévu, ne dépannez pas la page de splash. S'il s'associe mais que les enregistrements DHCP affichent une erreur, corrigez d'abord l'adressage ou le chemin VLAN. Cisco Meraki identifie le marquage VLAN au niveau du SSID ou du port de commutateur en amont comme une zone fréquente d'échec DHCP. 6

  2. Confirmez que le client n'est pas autorisé. Un appareil préalablement autorisé peut ne pas nécessiter de nouvelle page de splash pour le moment. Cisco Meraki documente une fonction de révocation d'autorisation de client pour des tests contrôlés. Utilisez-la sur l'appareil désigné, plutôt que de modifier la fréquence de splash pour tous les utilisateurs du site. 2 3

  3. Testez le déclencheur avec HTTP. Effacez le cache du navigateur uniquement si cela correspond à votre procédure de test, confirmez que les cookies sont activés, puis ouvrez une destination HTTP. Cisco Meraki indique qu'une requête HTTPS en premier ne peut pas être redirigée car le trafic est chiffré. Si le test HTTP fonctionne, documentez le comportement du client comme cause. Le réseau n'a pas perdu sa redirection de splash. 1 2

  4. Testez l'accessibilité de la page et le walled garden. Un walled garden autorise des adresses IP, des plages ou des noms d'hôte désignés avant l'authentification splash, y compris les domaines avec caractères génériques. Si vous utilisez une URL de splash personnalisée, Cisco Meraki indique que l'adresse IP et/ou l'URL de la page personnalisée doivent figurer dans le walled garden. Lorsque la page dépend de terminaux de ressources, d'identité ou de services distincts, passez en revue chaque destination requise avec le propriétaire du service. Ne devinez pas les adresses IP et n'ajoutez pas d'accès Internet général comme raccourci. 3

Les pages Purple établissent clairement la distinction. Une page de splash hors ligne apparaît avant la connexion et ne peut pas inclure de liens ou de ressources externes car le visiteur se trouve dans le walled garden. Une page en ligne apparaît après une connexion réussie et peut comporter des médias ou des liens externes. Si une page HTML Purple hors ligne a perdu une image, une feuille de style, un script ou un élément d'identité tiers après une modification, comparez ces dépendances avec les entrées pré-authentification autorisées avant de modifier la conception. 7 8

  1. Testez le RADIUS d'inscription uniquement après le chargement de la page. Le protocole RADIUS, utilisé ici pour les requêtes d'authentification centralisées, n'est pas le premier suspect lorsqu'aucune page de splash ne s'affiche. Il devient pertinent lorsque le formulaire d'inscription se charge mais que l'authentification échoue ou expire. Pour ce flux Cisco Meraki, c'est le cloud Dashboard qui initie la requête d'accès RADIUS, et non le point d'accès local ou le MX. Le serveur doit être accessible publiquement depuis les plages sources documentées de Dashboard, avoir un secret partagé correspondant et prendre en charge PAP. Cisco Meraki indique que RADSec n'est pas pris en charge pour l'authentification par splash. 4

  2. Exécutez le test RADIUS pris en charge et examinez l'enregistrement du serveur. Cisco Meraki propose un test RADIUS sur le Dashboard pour la configuration sans fil documentée, bien que le bouton de test n'existe pas pour les réseaux des séries MX ou Z. Un dépassement de délai signifie que vous devez vérifier les informations actuelles du pare-feu du Dashboard, les entrées du client RADIUS, l'accessibilité de l'hôte public, l'alignement des secrets partagés et le comportement des règles. Le contrôle d'état de Cisco Meraki envoie des requêtes d'accès périodiques et considère le serveur comme inaccessible après six tentatives infructueuses, espacées de 20 secondes. 4

Vous avez des questions sur votre configuration spécifique ?

Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.

Comment isoler les points de défaillance courants ?

La page splash de Cisco Meraki ne fonctionne pas : un organigramme de dépannage - meraki splash evidence map

La fréquence d'apparition du portail captif semble incorrecte

Si la page de splash apparaît moins souvent que ne le prévoient les règles, vérifiez si le client était déjà autorisé lorsque la fréquence a été modifiée. Cisco Meraki précise que la période d'autorisation existante reste en vigueur. Révoquer l'autorisation du client sélectionné permet de tester correctement le paramètre mis à jour. Si la page apparaît plus souvent, vérifiez l'acceptation des cookies par le navigateur, le vidage du cache et la continuité de la passerelle des points d'accès. Un redémarrage de la passerelle peut nécessiter une nouvelle authentification, sauf si le navigateur peut présenter son cookie. 2

Cela est important dans le secteur de l'hôtellerie. Un hôtel type de 200 chambres devrait effectuer un test avec un téléphone de test contrôlé après une modification, puis mesurer le résultat selon trois critères simples : le client passe à l'état autorisé, il reçoit l'expiration attendue, et la requête HTTP suivante se comporte comme prévu. C'est un meilleur critère de validation que de demander à la réception si les plaintes ont cessé.

Le WiFi invité ne redirige pas

Ne dites pas que le protocole HTTPS a « cassé » les portails captifs. Le comportement documenté de Cisco Meraki est plus précis : le mécanisme de redirection fonctionne sur un GET HTTP non autorisé, tandis qu'une requête HTTPS initiale ne peut pas être redirigée. Les appareils modernes peuvent lancer leur processus de détection de portail captif du système d'exploitation lors de l'association. Si cette invite n'apparaît pas, utilisez le test HTTP pour établir si la branche du réseau fonctionne. 1 2

Pour un déploiement type dans le commerce de détail, l'équipe informatique d'un magasin peut reproduire le problème avec un appareil de test du personnel sur l'SSID de la surface de vente. La preuve de réussite n'est pas une vague confirmation de chargement de page. Enregistrez l'association, l'adresse valide, l'état non autorisé, l'événement Auth après le test HTTP et l'état d'autorisation qui en résulte. Cet enregistrement peut être comparé d'un magasin à l'autre sans exposer les identifiants des visiteurs.

Le walled garden est incomplet

Un walled garden est un accès pré-autorisation intentionnellement limité. Il ne doit pas devenir une liste de contournement. Vérifiez d'abord l'hôte de la page de splash, puis les dépendances dont votre page de pré-authentification a réellement besoin. Cisco Meraki autorise les adresses IP, les plages d'adresses IP et les noms d'hôte, avec des domaines génériques. Cisco exige également que l'URL ou l'adresse IP d'une page de splash personnalisée soit incluse dans le walled garden lorsque cette fonctionnalité est activée. 3

Une page hors ligne Purple est l'étape la plus contraignante. Purple indique qu'il ne peut pas utiliser de liens ou de ressources externes tant que le visiteur se trouve dans le walled garden (portail captif restreint). L'éditeur HTML permet à votre équipe de charger des ressources directement dans le portail et de prévisualiser la page en cours, ce qui réduit les dépendances distantes inutiles. Suivez les étapes publiées par Purple avant de publier un modèle modifié. 7 8

La page de connexion expire ou rejette les identifiants

Distinguez le rejet du dépassement de délai (timeout). Un rejet est le résultat d'une politique de sécurité ou d'une authentification échouée. Un message d'expiration ou de « difficulté de connexion » indique d'abord un problème de joignabilité entre le Dashboard et le serveur RADIUS configuré. Cisco Meraki précise que les requêtes de la page de connexion proviennent du cloud Dashboard et ne peuvent pas utiliser une adresse LAN privée pour le serveur RADIUS. 4

Confirmez que le serveur attend le protocole PAP pour ce mode de page de connexion, que les plages sources documentées du Dashboard sont autorisées, que toutes les adresses IP sources pertinentes sont configurées comme clients RADIUS et que le secret partagé correspond aux deux extrémités. Cisco Meraki précise également que l'intégration de la page de connexion externe doit utiliser l'URL login_url fournie sans modification, et que le filtrage doit autoriser son nom d'hôte variable plutôt qu'un modèle fixe unique. 4

Que signifient les événements de page de connexion Meraki dans le journal d'événements ?

Lisez l'enregistrement comme une chronologie. L'événement 802.11 association signifie que le client a rejoint un point d'accès. Cela ne signifie pas que le client a obtenu une adresse, a accédé à la page de connexion ou a obtenu un accès Internet. Un événement Auth est la catégorie d'événement pour l'authentification de la page de connexion. Un événement DHCP se produisant à peu près au même moment peut orienter l'enquête vers l'attribution d'adresses. Un événement RADIUS est important pour un flux de connexion basé sur RADIUS, mais il ne prouve pas que le navigateur a accédé à la page. 5 6

Évitez de confondre le protocole 802.1X avec une page de connexion. Cisco Meraki identifie les messages 802.1X et RADIUS pour les SSIDs WPA2-Enterprise. Sa documentation RADIUS distincte pour la page de connexion décrit le protocole PAP entre le cloud Dashboard et votre serveur RADIUS. Dans ce guide, utilisez les catégories association, Auth, DHCP et RADIUS pour localiser l'étape défaillante. Ne déduisez pas une cause exacte à partir d'une seule ligne de journal. 4 6

Événement ou enregistrement Signification dans cette enquête Question suivante
802.11 association L'appareil a rejoint un point d'accès A-t-il reçu un adressage valide et est-il resté connecté ? 6
802.11 disassociation L'appareil a quitté ou a été retiré de la table des points d'accès Un mouvement RF, un état de veille ou une déconnexion interrompent-ils le test ? 6
Auth Catégorie d'authentification de la page de connexion S'est-il produit après un déclencheur HTTP contrôlé ? 5
DHCP Catégorie d'attribution d'adresses ou d'erreurs L'adressage du client ou le transport du VLAN bloquent-ils l'étape suivante ? 5 6
RADIUS Catégorie liée à RADIUS ou MAB S'agit-il d'une tentative de connexion via la page de connexion, et le cloud a-t-il reçu une réponse du serveur ? 4 5
Enregistrement de tentative de connexion Heure de connexion, SSID, identifiants du client et de la passerelle, ainsi que le statut d'autorisation Le résultat enregistré correspond-il au rapport du site ? 9

Cisco Meraki expose également les tentatives de connexion au splash portal via son Dashboard API documenté. L'enregistrement comprend l'heure de connexion, l'SSID, l'adresse MAC de la passerelle, l'adresse MAC du client et le statut d'autorisation. Pour les équipes informatiques multisites, cela permet d'associer le ticket du site à un résultat d'authentification sans traiter une simple anecdote comme une preuve d'incident. 9

Comment éviter qu'une page splash corrigée ne retombe en panne ?

Conservez un court guide d'exploitation à l'intention du responsable de votre service de Guest WiFi . Ce guide doit identifier l'SSID de test, l'appareil de test, la procédure de révocation des autorisations, l'hôte attendu de la page, les dépendances de pré-authentification, la propriété du RADIUS et le contact d'escalade. Il doit également préciser le comportement de la configuration en cas de déconnexion du contrôleur. Cisco Meraki documente les comportements ouverts, restreints et par défaut lorsque le contrôleur cloud n'est pas disponible. 3

Pour les parcs d'équipements qui utilisent un Captive Portal pour le consentement, l'image de marque et la politique d'accès, traitez la page hors ligne comme un composant applicatif contrôlé. Purple propose des types de pages hors ligne, en ligne et en dehors des heures d'ouverture. Utilisez le guide publié sur les Splash Pages pour les modifications du parcours d'accès et le guide de l' HTML editor pour les ressources téléchargées et la prévisualisation. Séparez le diagnostic quotidien de la configuration initiale. 7 8

Lorsque ce problème devient récurrent sur un site, centralisez les preuves plutôt que les suppositions. Corrélez l'heure de l'incident, l'adresse MAC du client, l'AP ou le MX, l'SSID, l'état d'autorisation, les catégories du journal d'événements et la réponse du serveur RADIUS. Cette approche convient parfaitement aux secteurs de l' Hospitality , du Retail et du Transport où les équipes locales ont besoin d'une limite d'escalade claire et l'équipe réseau de preuves reproductibles. Pour une conception de service plus large, consultez la page Guest WiFi Management: Smart Authentication & Segmentation .

Questions fréquentes

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

Oui. Purple prend en charge les déploiements de Guest WiFi qui se superposent à l'infrastructure existante, y compris Cisco Meraki. Ce guide couvre le diagnostic de niveau 2 d'une panne de splash page Meraki. Il ne remplace pas le travail de conception et d'intégration nécessaire pour un nouveau Captive Portal. Utilisez le guide des pages de splash Purple publié pour connaître les types de pages pris en charge et les modifications du parcours d'accès. 7

Quel est le travail nécessaire pour migrer une splash page Meraki vers Purple ?

Le travail dépend du flux d'authentification existant, des dépendances de pré-authentification et de la conception de la page. Commencez par inventorier l'hôte de la page actuelle, les entrées du walled garden, la méthode de connexion et la destination post-connexion. Purple prend en charge les modèles de splash page standards et HTML, y compris les ressources téléchargées et la prévisualisation en direct. Planifiez la migration comme un changement contrôlé, et non comme la correction d'un incident. 7 8

Une splash page Cisco Meraki peut-elle rediriger une requête uniquement HTTPS ?

Non. Cisco Meraki indique dans sa documentation que sa redirection splash commence lorsqu'un client non autorisé envoie un HTTP GET. Le trafic initialement en HTTPS est chiffré et ne peut pas être redirigé par ce mécanisme. Testez avec une destination HTTP, puis distinguez le comportement du navigateur client d'une panne de splash page à l'échelle du réseau. 1 2

De quelles entrées walled garden une splash page Meraki personnalisée a-t-elle besoin ?

Le walled garden doit autoriser l'adresse IP et/ou l'URL de la splash page personnalisée lorsqu'elle est activée. Ensuite, autorisez uniquement les points de terminaison de pré-authentification supplémentaires dont la page a réellement besoin. Cisco Meraki prend en charge les adresses IP, les plages et les noms d'hôte, y compris les domaines génériques. Ne remplacez pas cet examen par un accès internet non restreint. 3

Pourquoi une splash page de connexion Meraki expire-t-elle avec RADIUS ?

Une expiration signifie souvent que le cloud du Cisco Meraki Dashboard ne parvient pas à obtenir de réponse du serveur RADIUS configuré. Vérifiez l'accessibilité publique, les plages sources actuelles du Dashboard, la correspondance des secrets partagés des clients RADIUS et la prise en charge de PAP. L'AP ou le MX local n'est pas la source des requêtes RADIUS de la splash page. 4

Comment surveiller les échecs de connexion à la splash page sur plusieurs sites ?

Utilisez le journal d'événements Meraki pour filtrer le client et la plage horaire concernés, puis corrélez les catégories Auth, DHCP et RADIUS. L'API de tentatives de connexion splash de Cisco peut renvoyer l'heure de connexion, l'SSID, la passerelle, l'identifiant du client et le statut d'autorisation. Cela crée un enregistrement de preuves cohérent pour un centre de support multisite. 5 9

Références

Définitions clés

Captive portal

Un état de réseau pré-authentification contrôlé qui restreint un client jusqu'à ce qu'il termine l'interaction de splash configurée.

Vous dépannez le captive portal lorsqu'un appareil rejoint le WiFi invité mais n'a pas encore reçu d'accès réseau normal.

Autorisation de splash

L'état Cisco Meraki qui enregistre si un client a satisfait à l'exigence de splash et, le cas échéant, combien de temps cette autorisation reste valide.

Vérifiez cela en premier lorsqu'un appareil qui fonctionnait auparavant ne reçoit plus la page splash.

Walled garden

La liste restreinte d'adresses IP, de plages et de noms d'hôte qu'un client non autorisé peut atteindre avant de terminer l'authentification splash.

Examinez-le lorsqu'une page personnalisée manque de ressources, de comportement de formulaire ou d'une autre dépendance légitime de pré-authentification.

Fréquence de splash

L'intervalle configuré qui régit la fréquence à laquelle la page splash est présentée à un client.

Cela aide à expliquer pourquoi un appareil reste autorisé après une modification de politique, ou semble être sollicité à plusieurs reprises.

Déclencheur de redirection HTTP

L'HTTP GET du client non autorisé que Cisco Meraki intercepte pour commencer le processus de redirection splash.

Utilisez un test HTTP contrôlé pour séparer l'initiation de la redirection d'une requête de navigateur HTTPS-first.

Requête HTTPS-first

Une tentative du client d'atteindre une destination HTTPS chiffrée avant l'autorisation de splash.

Cisco Meraki documente que ce trafic ne peut pas être redirigé par le mécanisme de splash HTTP, ce qui peut s'apparenter à un dépassement de délai de la page.

RADIUS

Remote Authentication Dial-In User Service, un protocole utilisé ici pour valider les identifiants de connexion du splash par rapport à un serveur d'authentification géré centralement.

Examinez ce point après le chargement de la page de connexion si l'authentification est rejetée ou expire.

PAP

Password Authentication Protocol, la méthode d'authentification documentée par Cisco Meraki pour l'utilisation du splash de connexion avec un serveur RADIUS hébergé par le client.

Confirmez que la politique RADIUS autorise PAP avant de traiter le problème comme une panne de serveur générique.

Événement Auth

La catégorie du journal d'événements du Dashboard Cisco Meraki utilisée pour l'activité d'authentification de la page splash.

Lisez-le en parallèle avec les enregistrements d'association, DHCP et RADIUS pour reconstituer le moment où le flux du client s'est arrêté.

802.1X

Un cadre de contrôle d'accès réseau basé sur les ports utilisé pour l'authentification WiFi d'entreprise, distinct du flux de page d'accueil d'authentification pris en charge par RADIUS décrit dans ce guide.

Ne confondez pas les enregistrements d'événements 802.1X avec la preuve qu'une page splash de connexion via un navigateur s'est chargée.

Exemples concrets

Scénario hôtelier illustratif : un hôtel de 200 chambres doit diagnostiquer des rapports intermittents de dysfonctionnement du splash du WiFi invité sans perturber les clients enregistrés.

Désignez un téléphone de test et enregistrez son adresse MAC, son SSID, son point d'accès de desserte et l'heure locale. Confirmez l'association et l'adressage valide, puis inspectez l'état du splash du client. Révoquez l'autorisation uniquement pour ce téléphone lorsqu'un nouveau test est requis. Exécutez un test HTTP et comparez les preuves correspondantes de l'Auth, du DHCP et de RADIUS. Le résultat mesurable est un client de test autorisé, l'expiration de l'autorisation attendue et un résultat documenté pour chaque point de contrôle.

Scénario de vente au détail illustratif : la page de pré-authentification personnalisée d'un magasin s'ouvre mais perd son élément de connexion après une modification de contenu.

Ne rendez pas l'ensemble d'Internet disponible avant la connexion. Confirmez que la page elle-même se charge sur un appareil de test non autorisé, puis inventoriez ses points de terminaison de pré-authentification requis. Comparez l'hôte de la page et chaque ressource ou dépendance d'identité requise avec la politique du walled-garden. Testez à nouveau en utilisant le même client et capturez l'état du splash, la chronologie d'Auth et le résultat de l'autorisation. Le résultat mesurable est un flux de connexion finalisé sans élargissement non approuvé de l'accès de pré-authentification.

Vous avez des questions sur votre configuration spécifique ?

Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.