Dépannage du WiFi public : résoudre les erreurs « Connecté, pas d'Internet » et les échecs de redirection vers la page d'accueil

Bienvenue dans ce point technique de Purple. Aujourd'hui, nous nous attaquons à l'un des problèmes les plus persistants et les plus mal compris des réseaux sans fil d'entreprise : le Captive Portal WiFi invité qui refuse tout simplement de se charger. Vous avez déjà connu cela. Un client arrive dans votre hôtel, votre magasin, votre stade ou votre centre de conférence. Il se connecte au réseau WiFi. Rien ne se passe. Pas de page de connexion. Pas d'internet. Juste une icône qui tourne et une frustration grandissante. Pour les directeurs d'exploitation de sites et les responsables informatiques, ce moment n'est pas un simple désagrément. Il représente un échec direct de l'expérience client, une augmentation des appels à l'assistance à l'accueil et une occasion manquée de collecter les données de première partie qui justifient votre investissement dans l'infrastructure sans fil. Dans ce point technique, nous allons plonger sous le capot. Nous expliquerons exactement comment fonctionne la détection de Captive Portal au niveau du système d'exploitation, nous identifierons les six causes principales responsables de la grande majorité des échecs de connexion, et nous vous fournirons un cadre de dépannage pratique et exploitable que vous pourrez transmettre à votre équipe informatique dès aujourd'hui. Commençons par le fonctionnement technique. La plupart des gens considèrent un Captive Portal comme une simple page de connexion. Il s'agit en réalité d'un mécanisme d'interception du trafic au niveau du réseau, et cette distinction est cruciale lorsque des dysfonctionnements surviennent. Voici la séquence. L'appareil d'un invité rejoint votre SSID invité et reçoit une adresse IP via DHCP. À ce stade, le système d'exploitation n'attend pas que l'utilisateur ouvre un navigateur. En arrière-plan, un service système lance immédiatement une requête HTTP GET non chiffrée vers une URL de test contrôlée par le constructeur. Les appareils Apple interrogent captive.apple.com. Les appareils Android interrogent connectivitycheck.gstatic.com. Les appareils Windows interrogent msftconnecttest.com. Firefox possède sa propre sonde à l'adresse detectportal.firefox.com. Si le réseau dispose d'un accès internet ouvert, ces sondes renvoient les réponses attendues et le système d'exploitation en conclut que tout fonctionne correctement. Mais sur un réseau invité, votre passerelle ou contrôleur sans fil intercepte cette sonde HTTP avant qu'elle n'atteigne internet. Au lieu de la réponse attendue, la passerelle renvoie une redirection HTTP 307 pointant vers la page d'accueil de votre Captive Portal. Le système d'exploitation détecte la redirection inattendue, réalise qu'il se trouve derrière un Captive Portal et ouvre une fenêtre de navigation sécurisée - souvent appelée Captive Network Assistant - pour afficher la page de connexion. Voilà pour le scénario idéal. Voyons maintenant les six scénarios où le système échoue. Cause première numéro un : l'épuisement du pool DHCP. C'est le tueur silencieux lors des événements à haute densité. Si vous organisez une conférence avec deux mille participants sur un sous-réseau standard en /24, vous disposez de 254 adresses IP utilisables. Si la durée de bail DHCP est configurée sur les 24 heures par défaut, vous épuiserez ce pool dans les minutes qui suivent l'ouverture des portes. Chaque tentative de connexion ultérieure échoue avant même que la séquence de Captive Portal ne commence. La solution est simple : définissez les durées de bail DHCP des invités entre 15 et 30 minutes pour les environnements à forte rotation, et dimensionnez vos sous-réseaux de manière appropriée pour le pic d'utilisateurs simultanés, et pas seulement pour l'effectif total. Cause première numéro deux : l'échec de l'interception DNS. La redirection vers le Captive Portal dépend de l'interception de la sonde HTTP par la passerelle. Mais la sonde nécessite d'abord une résolution DNS. Si votre configuration DNS ne permet pas aux clients pré-authentifiés de résoudre des noms de domaine externes, la sonde ne se déclenche jamais. Assurez-vous que votre politique de pare-feu autorise explicitement les requêtes DNS des clients non authentifiés, et vérifiez que votre interception DNS fonctionne en effectuant une capture de paquets sur un appareil de test. Cause première numéro trois : un walled garden incomplet. Le walled garden - également appelé liste de contrôle d'accès pré-authentification - définit les domaines externes que les invités non authentifiés peuvent atteindre. Si la page d'accueil de votre portail charge des ressources à partir d'un CDN qui ne figure pas dans le walled garden, la page s'affiche sous forme d'écran blanc. Si vous proposez la connexion sociale via Google, Apple ou Facebook, chaque domaine OAuth utilisé par ces fournisseurs doit être mis sur liste blanche. Et voici le point critique : les fournisseurs d'identité sociale mettent régulièrement à jour leurs plages d'adresses IP de CDN et leurs domaines d'authentification. Un walled garden qui fonctionnait parfaitement il y a six mois peut être silencieusement hors service aujourd'hui. Planifiez des audits trimestriels du walled garden et utilisez le snooping de domaine générique (wildcard) si votre matériel le prend en charge. Sur Cisco Meraki, HPE Aruba, Ruckus et Juniper Mist, cette fonctionnalité est disponible nativement. Cause première numéro quatre : le blocage de la redirection par HSTS. Le protocole HTTP Strict Transport Security, ou HSTS, est une politique de sécurité de navigateur qui force les connexions à des domaines spécifiques uniquement via HTTPS. Si l'appareil d'un invité tente de contacter un domaine préchargé HSTS - ce qui inclut pratiquement tous les grands sites Web - et que votre passerelle tente d'intercepter cette requête HTTPS pour la rediriger vers le portail, le navigateur détecte une non-correspondance de certificat. Il présente alors un avertissement de sécurité impossible à contourner et bloque complètement la redirection. La solution correcte consiste à ne jamais tenter d'interception HTTPS. Votre passerelle doit uniquement rediriger les sondes de test HTTP non chiffrées. La solution à long terme basée sur les normes est la RFC 8910, qui définit l'option DHCP 114. Cette option permet à votre serveur DHCP d'annoncer directement l'URL du Captive Portal à l'appareil client, évitant ainsi complètement le besoin de redirection HTTP. iOS 14 et Android 11 et versions ultérieures le prennent en charge nativement. Cinquième cause profonde : un VPN actif sur l'appareil de l'invité. Un VPN chiffre tout le trafic de l'appareil et l'achemine via un tunnel externe avant qu'il n'atteigne votre passerelle. Votre passerelle ne voit jamais la requête HTTP. La séquence de détection du Captive Portal ne se déclenche jamais. L'invité ne voit ni page de connexion ni internet. La solution pour l'invité est simple : désactiver le VPN, se connecter au portail, puis réactiver le VPN. Pour votre personnel d'accueil, cela devrait être la première question à poser lorsqu'un invité signale un problème de connexion. Sixième cause profonde : la randomisation de l'adresse MAC qui rompt la persistance de la session. Les appareils iOS et Android modernes utilisent par défaut des adresses MAC aléatoires comme fonctionnalité de confidentialité. Chaque fois qu'un appareil se connecte à un réseau, il peut présenter une adresse MAC différente. Comme l'état de la session du Captive Portal est suivi par l'adresse MAC, un invité authentifié il y a une heure peut se voir à nouveau présenter la page de connexion après la rotation de la MAC de son appareil. La solution côté invité consiste à désactiver l'adresse privée pour votre SSID spécifique dans les paramètres réseau. La solution côté opérateur consiste à implémenter une authentification basée sur les profils - comme OpenRoaming via Passpoint et 802.1X - qui authentifie au niveau de la couche 2 à l'aide d'identifiants plutôt que d'adresses MAC, rendant la randomisation non pertinente. Parlons maintenant de l'implémentation. À quoi ressemble concrètement un déploiement de Captive Portal bien configuré ? Commencez par votre architecture DHCP. Pour tout site prévoyant plus de 200 appareils simultanés, abandonnez le sous-réseau unique en /24. Utilisez un /22 ou plus grand, et définissez des durées de bail adaptées au profil de présence de votre site. Un hôtel fixe les baux à 8 heures. Un stade les fixe à 3 heures. Un centre commercial les fixe à 90 minutes. Un centre de conférence les fixe à 30 minutes. Ensuite, validez votre walled garden avant chaque événement majeur. Les entrées minimales requises sont : le nom de domaine complet de votre portail et tous les domaines CDN associés, les URL de détection du Captive Portal pour Apple, Google, Windows et Firefox, et les domaines OAuth pour chaque fournisseur de connexion sociale que vous prenez en charge. Sur la plateforme de Purple, nous maintenons et mettons à jour ces entrées de walled garden automatiquement dans le cadre de notre service géré dans le cloud, ce qui libère votre équipe de la charge de maintenance manuelle. Pour le certificat de votre portail, utilisez un certificat TLS public de confiance émis par une autorité de certification reconnue. Les certificats auto-signés déclencheront des avertissements de navigateur sur tous les appareils. Renouvelez les certificats avant leur expiration - un certificat expiré est l'une des causes les plus courantes de pannes soudaines de portail à l'échelle d'un site. Un piège qui guette de nombreuses équipes informatiques : tester le portail depuis un appareil qui s'est déjà authentifié. La session de votre appareil étant toujours active, vous contournez entièrement le portail et en concluez que tout fonctionne. Testez toujours depuis un appareil dans un état neuf et non authentifié – soit un nouvel appareil, soit un appareil sur lequel vous avez oublié le réseau et effacé le profil WiFi. Permettez-moi de vous présenter deux scénarios réels qui illustrent ces principes. Premier scénario : un hôtel de 350 chambres dans le centre de Londres. L'établissement gérait un unique sous-réseau en /24 pour le WiFi des clients. Lors d'une grande conférence, 400 délégués sont arrivés simultanément. En l'espace de 20 minutes, le pool DHCP était épuisé. Les clients ont signalé qu'ils étaient connectés mais qu'ils ne pouvaient pas accéder au portail ni à Internet. La solution immédiate a consisté à étendre le sous-réseau en /22, offrant ainsi 1 022 adresses utilisables, et à réduire la durée du bail DHCP de 24 heures à 8 heures. La solution à plus long terme a été d'implémenter le Captive Portal géré dans le cloud de Purple, qui surveille l'utilisation du pool DHCP en temps réel et alerte l'équipe réseau avant que l'épuisement ne survienne. Le taux d'échec du portail est tombé à près de zéro dans les 48 heures suivant ce changement. Deuxième scénario : une grande chaîne de magasins de détail comptant 200 points de vente. La chaîne utilisait la connexion via les réseaux sociaux (Google et Facebook) sur son portail client. Après la mise à jour par Google de son infrastructure OAuth, les nouveaux domaines d'authentification n'étaient pas inclus dans le walled garden. Les clients pouvaient accéder à la page du portail, mais les boutons de connexion sociale affichaient des écrans vides. L'équipe informatique de la chaîne a passé deux jours à diagnostiquer le problème avant d'identifier la lacune dans le walled garden. La correction a pris 10 minutes une fois identifiée. La leçon à retenir : ne codez jamais en dur les adresses IP dans votre walled garden pour les fournisseurs OAuth basés sur le cloud. Utilisez des entrées de domaine génériques (wildcard) et révisez-les chaque trimestre. Passons maintenant à quelques questions rapides que nous posent régulièrement les équipes informatiques des établissements. Pourquoi le portail fonctionne-t-il sur les iPhones mais pas sur les appareils Android ? Android utilise connectivitycheck.gstatic.com comme URL de test. Si ce domaine est bloqué par votre pare-feu ou s'il ne figure pas dans votre walled garden, les appareils Android ne déclencheront jamais le portail. Ajoutez-le explicitement. Un client indique que le portail s'est chargé, mais qu'il ne parvient pas à se connecter après s'est identifié. Il s'agit presque toujours d'un échec d'autorisation RADIUS. Vérifiez que votre serveur RADIUS est accessible depuis le contrôleur sans fil, assurez-vous que le secret partagé correspond des deux côtés, et examinez les journaux RADIUS pour y rechercher des messages Access-Reject. Comment gérer les clients qui sont déconnectés après seulement quelques minutes ? Vérifiez votre paramètre d'expiration de session d'inactivité (idle timeout). De nombreux contrôleurs sont configurés par défaut sur une expiration de session d'inactivité de 5 minutes, ce qui est beaucoup trop agressif pour les appareils mobiles qui se mettent en veille entre deux interactions. Configurez l'idle timeout sur au moins 30 minutes pour les environnements de l'hôtellerie et du commerce de détail. Pour résumer les points clés de notre présentation d'aujourd'hui. Les échecs du Captive Portal WiFi pour les clients se classent en six catégories : l'épuisement du pool DHCP, l'échec de l'interception DNS, un walled garden incomplet, le blocage des redirections HSTS, un VPN actif sur l'appareil client et la randomisation des adresses MAC. Chacun de ces problèmes dispose d'une solution spécifique et testable. Pour votre équipe informatique, les actions immédiates sont les suivantes : auditer les durées de bail DHCP et le dimensionnement de vos sous-réseaux, valider votre walled garden par rapport aux domaines OAuth actuels de vos fournisseurs de connexion sociale, et tester votre portail depuis un nouvel appareil non authentifié après chaque modification de configuration. Pour votre feuille de route à plus long terme, évaluez OpenRoaming comme le successeur de la réauthentification par captive portal pour les visiteurs réguliers. La technologie est mature, les normes sont établies selon les standards IEEE 802.1X et WPA3-Enterprise, et Purple la met à disposition sans coût logiciel supplémentaire dans le cadre de l'offre Connect. Purple est déployé dans plus de 80 000 sites et a traité 440 millions de connexions rien qu'en 2024. Nous avons été témoins de tous les modes de défaillance décrits dans ce document, et nous avons développé les outils nécessaires pour les prévenir. Si vous souhaitez découvrir comment l'overlay cloud de Purple s'intègre à votre infrastructure existante Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist, visitez purple.ai ou contactez votre responsable de compte. Merci pour votre écoute.