Dépannage du WiFi public : résoudre l'erreur « Connecté, pas d'internet » et les échecs de redirection vers la page de connexion

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 du WiFi invité qui refuse tout simplement de se charger. Vous avez déjà connu cette situation. Un client arrive dans votre hôtel, votre point de vente, 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'internet. Juste une icône qui tourne et une frustration qui grandit. Pour les directeurs d'exploitation et les responsables informatiques, ce moment n'est pas qu'un simple inconvénient. Il représente un échec direct de votre expérience client, une augmentation des appels au support 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 point technique, nous allons examiner les aspects techniques. Nous expliquerons exactement comment la détection de Captive Portal fonctionne 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 concret que vous pourrez transmettre à votre équipe informatique dès aujourd'hui. Commençons par le fonctionnement mécanique. La plupart des gens considèrent un Captive Portal simplement comme une 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 les choses tournent mal. Voici la séquence de connexion. 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. 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 URL de test sur detectportal.firefox.com. Si le réseau dispose d'un accès internet ouvert, ces requêtes 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 requête 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 d'accueil de 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 navigateur 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 raisons pour lesquelles ce processus é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 de deux mille participants sur un sous-réseau standard slash-24, vous disposez de 254 adresses IP utilisables. Si la durée de bail DHCP est configurée sur la valeur par défaut de 24 heures, vous épuiserez ce pool dans les minutes qui suivent l'ouverture des portes. Chaque tentative de connexion ultérieure échouera avant même que la séquence du Captive Portal ne commence. La solution est simple : configurez 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 les utilisateurs simultanés en période de pointe, et non pas seulement pour l'effectif total. Cause première numéro deux : l'échec de l'interception DNS. La redirection du Captive Portal dépend de l'interception de la sonde HTTP par la passerelle. Mais cette 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 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 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 la forme d'un écran vide. Si vous proposez une connexion via les réseaux sociaux avec 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 discrètement hors service aujourd'hui. Planifiez des audits trimestriels de votre walled garden et utilisez la surveillance de domaine par caractères génériques (wildcard) si votre matériel le permet. Cette fonctionnalité est disponible nativement sur Cisco Meraki, HPE Aruba, Ruckus et Juniper Mist. Cause première numéro quatre : le blocage de la redirection par HSTS. HTTP Strict Transport Security, ou HSTS, est une politique de sécurité de navigateur qui impose des connexions uniquement via HTTPS pour certains 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 affiche 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 de communiquer directement l'URL du Captive Portal à l'appareil client, évitant ainsi totalement le besoin de redirection HTTP. iOS 14, Android 11 et leurs versions supérieures prennent cela 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 des adresses MAC qui brise la persistance de la session. Les appareils modernes iOS et Android utilisent par défaut des adresses MAC aléatoires par mesure de confidentialité. Chaque fois qu'un appareil se connecte à un réseau, il peut présenter une adresse MAC différente. Étant donné que l'état de la session du Captive Portal est suivi par l'adresse MAC, un invité qui s'est authentifié il y a une heure peut se retrouver à nouveau face à 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 obsolète. Parlons maintenant de l'implémentation. À quoi ressemble concrètement un déploiement de Captive Portal bien configuré dans la pratique ? Commencez par votre architecture DHCP. Pour tout site accueillant plus de 200 appareils simultanés, abandonnez le sous-réseau unique en slash-24. Utilisez un slash-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 définit les baux à 8 heures. Un stade définit les baux à 3 heures. Un centre commercial définit les baux à 90 minutes. Un centre de conférences définit 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 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 pour 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 vos équipes. 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 alertes de sécurité sur le navigateur de chaque appareil. Renouvelez les certificats avant leur expiration - un certificat expiré est l'une des causes les plus courantes de pannes soudaines de portails à l'échelle d'un site. Un piège classique dans lequel tombent de nombreuses équipes informatiques : tester le portail depuis un appareil qui s'est déjà authentifié auparavant. La session de votre appareil étant toujours active, vous contournez complètement le portail et en concluez que tout fonctionne. Testez toujours depuis un appareil dans un état vierge 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 donner 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 à un slash-22, offrant 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 qu'une pénurie 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 vente au détail comptant 200 boutiques. La chaîne utilisait la connexion via les réseaux sociaux avec Google et Facebook sur son portail invité. Après une 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 de ces domaines dans le walled garden. La correction a pris 10 minutes une fois identifiée. La leçon à retenir : ne saisissez 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 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 n'est 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 peut 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 d'inactivité (idle timeout). 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 d'inactivité 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 point d'information du jour. Les échecs de Captive Portal pour le WiFi invité 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 vérifiable. Pour votre équipe informatique, les actions immédiates sont les suivantes : auditez les 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 en tant que successeur de la réauthentification par Captive Portal pour les visiteurs récurrents. La technologie est mûre, les normes sont établies sous IEEE 802.1X et WPA3-Enterprise, et Purple la met à disposition sans coût logiciel supplémentaire dans le cadre du forfait Connect. Purple opère 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 pour les éviter. Si vous souhaitez découvrir comment la solution 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.