Pourquoi mon WiFi invité ne se connecte-t-il pas ? Résolution des problèmes de Captive Portal

TITRE : Pourquoi mon WiFi invité ne se connecte-t-il pas ? Résolution des problèmes de Captive Portal FORMAT : Podcast d'information technique de Purple VOIX : Anglais britannique - Ton d'architecte de solutions senior DURÉE : Environ 10 minutes --- SECTION 1 : Introduction et contexte - environ 1 minute Bonjour et bienvenue dans ce point technique de Purple. Je suis votre hôte et 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 cela. Un invité arrive dans votre hôtel, votre magasin de détail, 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 qui grandit. Pour les directeurs d'exploitation de sites 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 d'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 regarder sous le capot. Nous expliquerons exactement comment fonctionne la détection du 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 donnerons un cadre de dépannage pratique et exploitable que vous pourrez transmettre à votre équipe informatique dès aujourd'hui. C'est parti. --- SECTION 2 : Analyse technique approfondie - environ 5 minutes Pour résoudre un problème de Captive Portal, vous devez d'abord comprendre ce qu'est réellement un Captive Portal au niveau du réseau. La plupart des gens pensent qu'il s'agit simplement d'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. L'appareil d'un invité se connecte à 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 envoie immédiatement une requête HTTP GET non chiffrée à une URL de test contrôlée par le fournisseur. Les appareils Apple interrogent captive.apple.com. Les appareils Android interrogent connectivitycheck.gstatic.com. Les appareils Windows interrogent msftconnecttest.com. Firefox a son propre test sur detectportal.firefox.com. Si le réseau dispose d'un accès internet ouvert, ces tests renvoient les réponses attendues, et le système d'exploitation en conclut que tout va bien. 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 302 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 navigateur sécurisée - souvent appelée l'assistant de Captive Portal - pour afficher la page de connexion. Voilà pour le scénario idéal. Parlons maintenant des six façons dont cela peut échouer. Cause racine numéro un : l'épuisement du pool DHCP. C'est le tueur silencieux 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 de bail de votre DHCP est définie 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 : 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 les pics d'utilisateurs simultanés, et pas seulement pour l'effectif total. Cause racine 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 n'autorise pas les clients pré-authentifiés à résoudre les 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 racine numéro trois : un walled garden incomplet. Le walled garden - également appelé liste de contrôle d'accès de pré-autorisation - 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 vide. Si vous proposez une connexion via les réseaux sociaux comme 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 défaillant aujourd'hui. Planifiez des audits trimestriels du walled garden et utilisez la détection de domaine par caractère 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 racine numéro quatre : HSTS bloquant la redirection. La sécurité de transport HTTP stricte, ou HSTS, est une politique de sécurité des navigateurs qui impose des connexions aux 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 incompatibilité de certificat. Il présente alors un avertissement de sécurité impossible à ignorer et bloque complètement la redirection. La bonne solution 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 d'avoir recours à la redirection HTTP. iOS 14 et Android 11 et versions ulté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 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 accès 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 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 session du Captive Portal est suivi par 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 des 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. - SECTION 3 : Recommandations d'implémentation et pièges à éviter - environ 2 minutes Maintenant que nous comprenons les causes profondes, voyons à quoi ressemble un déploiement de Captive Portal bien configuré. Commencez par votre architecture DHCP. Pour tout site accueillant 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 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, ainsi que 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 libère votre équipe de cette charge de maintenance manuelle. Pour le certificat de votre portail, utilisez un certificat TLS de confiance publique provenant d'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 portail sur l'ensemble d'un site. Un piège classique pour de nombreuses équipes informatiques consiste à 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 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. Enfin, anticipez l'évolution technologique à venir. Les portails captifs sont une technologie éprouvée, mais ils génèrent une friction inhérente. OpenRoaming, basé sur Passpoint et 802.1X, permet aux visiteurs réguliers de se connecter automatiquement et de manière sécurisée sans jamais voir de page de connexion. Purple agit comme un fournisseur d'identité gratuit pour OpenRoaming dans le cadre de notre offre Connect. Des sites comme Premier Inn et Manchester Airports Group déploient déjà cette solution pour éliminer la friction de la ré-authentification pour les visiteurs récurrents, tout en maintenant une conformité GDPR totale et la collecte de données de première main. - SECTION 4 : Questions-Réponses rapides - environ 1 minute Passons en revue les questions les plus fréquemment posées par les équipes informatiques des sites physiques. Question : Pourquoi le portail fonctionne-t-il sur les iPhones mais pas sur les appareils Android ? Réponse : Android utilise connectivitycheck.gstatic.com comme URL de test de connectivité. 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. Question : Un client indique que le portail s'est chargé mais qu'il ne peut pas se connecter après s'être identifié. Réponse : 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 à la recherche de messages Access-Reject. Question : Comment gérer les clients qui sont déconnectés après seulement quelques minutes ? Réponse : Vérifiez le paramètre de votre délai d'expiration d'inactivité. De nombreux contrôleurs sont configurés par défaut sur un délai de 5 minutes, ce qui est bien trop agressif pour les appareils mobiles qui se mettent en veille entre deux interactions. Définissez ce délai d'expiration à au moins 30 minutes pour les environnements d'accueil et de commerce. - SECTION 5 : Résumé et étapes suivantes - environ 1 minute Pour résumer : les échecs de portail captif WiFi pour les visiteurs se divisent en six catégories - l'épuisement des adresses DHCP, l'échec d'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 dispose d'un correctif précis et vérifiable. Pour votre équipe informatique, les actions immédiates sont les suivantes : auditez vos durées de bail DHCP et la taille 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 appareil vierge 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 portail captif pour vos visiteurs récurrents. La technologie est mature, les normes sont établies sous les protocoles IEEE 802.1X et WPA3-Enterprise, et Purple la rend disponible sans coût logiciel supplémentaire dans le cadre de l'offre Connect. Pour obtenir d'autres guides techniques, des études de cas et des ressources d'implémentation, visitez purple.ai. Merci d'avoir écouté ce briefing technique Purple. Maintenez vos réseaux fiables et vos invités connectés.