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 briefing 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 portail captif WiFi invité qui refuse tout simplement de se charger. Vous avez déjà vécu cela. Un invité arrive dans votre hôtel, votre magasin de détail, votre stade ou votre centre de conférences. Il se connecte au réseau WiFi. Rien ne se passe. Pas de page de connexion. Pas d'accès internet. Juste une icône qui tourne et une frustration qui grandit. Pour les directeurs d'exploitation de sites et les responsables informatiques, ce moment n'est pas qu'un simple inconvénient mineur. Il représente un échec direct de votre expérience client, une hausse des appels au support à l'accueil, et une opportunité manquée de collecter les données de première partie qui justifient votre investissement dans l'infrastructure sans fil. Dans ce briefing, nous allons analyser la technique en détail. Nous expliquerons précisément comment fonctionne la détection de portail captif 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 activable que vous pourrez transmettre à votre équipe informatique dès aujourd'hui. Commençons par le fonctionnement. La plupart des gens considèrent un portail captif 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 extrêmement importante lorsque des problèmes 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 fabricant de l'appareil. 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 sur 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 votre page de connexion du portail captif. Le système d'exploitation détecte la redirection inattendue, réalise qu'il se trouve derrière un portail captif et ouvre une fenêtre de navigation sécurisée - souvent appelée Captive Network Assistant - pour afficher la page de connexion. Voilà le parcours idéal. Parlons maintenant des six façons dont ce processus peut échouer. Cause d'origine 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 slash-24, vous disposez de 254 adresses IP utilisables. Si la durée du 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 du Captive Portal ne commence. La solution est simple : configurez les durées de bail DHCP 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 d'origine numéro deux : l'échec de l'interception DNS. La redirection du Captive Portal dépend de l'interception de la requête HTTP par la passerelle. Mais cette requête 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 requête ne se déclenche jamais. Assurez-vous que votre politique de pare-feu autorise explicitement les requêtes DNS provenant de clients non authentifiés, et vérifiez que votre interception DNS fonctionne en effectuant une capture de paquets sur un appareil de test. Cause d'origine numéro trois : un walled garden incomplet. Le walled garden - également appelé liste de contrôle d'accès de 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 la forme d'un écran vide. Si vous proposez une connexion sociale via Google, Apple ou Facebook, tous les domaines OAuth utilisés par ces fournisseurs doivent être autorisés. 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 discrètement défaillant aujourd'hui. Planifiez des audits trimestriels du walled garden et utilisez la détection de domaine par wildcard si votre matériel le permet. Sur Cisco Meraki, HPE Aruba, Ruckus et Juniper Mist, cette fonctionnalité est disponible nativement. Cause d'origine numéro quatre : le blocage de la redirection par HSTS. Le protocole HTTP Strict Transport Security, ou HSTS, est une politique de sécurité du navigateur qui impose des connexions uniquement via HTTPS pour des domaines spécifiques. 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 requêtes 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 de communiquer directement l'URL du Captive Portal à l'appareil client, évitant ainsi complètement le besoin de redirection HTTP. Les systèmes iOS 14 et Android 11 et versions supérieures prennent cela en charge nativement. Cinquième cause profonde : un VPN actif sur l'appareil 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 de test. 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 : l'altération de la persistance de session par la randomisation des adresses MAC. Les appareils iOS et Android modernes utilisent par défaut des adresses MAC randomisées par mesure 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 session du Captive Portal est suivi par l'adresse MAC, un invité qui s'est authentifié il y a une heure peut se voir présenter à nouveau 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 - telle que OpenRoaming via Passpoint et 802.1X - qui s'authentifie au niveau de la couche 2 à l'aide d'identifiants plutôt que d'adresses MAC, ce qui rend la randomisation sans importance. Parlons maintenant de mise en œuvre. À 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 fixe les baux à 3 heures. Un centre commercial fixe les baux à 90 minutes. Un centre de conférence fixe les baux à 30 minutes. Ensuite, validez votre walled garden avant chaque événement majeur. Les entrées minimales requises sont : le nom de domaine complet (FQDN) de votre portail et tous les domaines CDN associés, les URL de détection de Captive Portal pour Apple, Google, Windows et Firefox, et les domaines OAuth de chaque fournisseur de connexion sociale que vous prenez en charge. Sur la plateforme de Purple, nous gérons et mettons à jour ces entrées de walled garden automatiquement dans le cadre de notre service géré dans le cloud, ce qui élimine la charge de maintenance manuelle pour votre équipe. Pour le certificat de votre portail, utilisez un certificat TLS de confiance publique émis par une autorité de certification reconnue. Les certificats auto-signés déclencheront des alertes de navigateur sur chaque appareil. Renouvelez les certificats avant leur expiration - un certificat expiré est l'une des causes les plus courantes de pannes soudaines de portail sur l'ensemble d'un site. Un piège classique qui surprend de nombreuses équipes informatiques : tester le portail depuis un appareil déjà authentifié. La session de votre appareil étant toujours active, vous contournez complètement le portail et en concluez que tout fonctionne. Testez toujours à partir d'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. Laissez-moi 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 slash-24 pour le WiFi invité. 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 incapables d'accéder au Captive Portal ou à Internet. La solution immédiate a consisté à étendre le sous-réseau en slash-22, offrant ainsi 1 022 adresses utilisables, et à réduire la durée du bail de 24 heures à 8 heures. La solution à plus long terme a été de déployer 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 se produise. 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 vente au détail comptant 200 magasins. La chaîne utilisait la connexion via les réseaux sociaux avec Google et Facebook sur son portail invité. Après la mise à jour par Google de son infrastructure OAuth, les nouveaux domaines d'authentification ne figuraient plus 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 l'absence dans le walled garden. Une fois identifié, le correctif a pris 10 minutes. La leçon : ne codez jamais d'adresses IP en dur dans votre walled garden pour les fournisseurs OAuth basés sur le cloud. Utilisez des entrées de domaine génériques avec caractères jokers et révisez-les chaque trimestre. Passons maintenant à quelques questions rapides que nous posent régulièrement les équipes informatiques des sites. 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éclenchent 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'être 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, vérifiez 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 de délai d'expiration pour inactivité. De nombreux contrôleurs sont configurés par défaut sur un délai d'inactivité de 5 minutes, ce qui est beaucoup trop agressif pour les appareils mobiles qui se mettent en veille entre deux interactions. Définissez le délai d'expiration pour inactivité sur au moins 30 minutes pour les environnements de l'hôtellerie et de la vente au détail. Pour résumer les points clés de ce briefing : Les échecs de Captive Portal pour le WiFi invité se répartissent 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'un correctif spécifique et vérifiable. Pour votre équipe informatique, les actions immédiates sont les suivantes : auditez vos durées de bail DHCP et le dimensionnement de vos sous-réseaux, validez votre walled garden par rapport aux domaines OAuth actuels de vos fournisseurs de connexion sociale, et testez 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 de retour. La technologie est mature, les normes sont établies sous les standards IEEE 802.1X et WPA3-Enterprise, et Purple la met à disposition sans coût logiciel supplémentaire dans le cadre de l'abonnement Connect. Purple opère dans 80 000 sites et a traité 440 millions de connexions rien qu'en 2024. Nous avons été confrontés à tous les modes de défaillance décrits dans ce briefing - et nous avons conçu les outils 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.