Pourquoi mon Wi-Fi invité ne se connecte-t-il pas ? Dépannage 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 Purple VOIX : Anglais britannique - ton d'Architecte 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 nous nous attaquons aujourd'hui à 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 produit. 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 seulement un inconvénient mineur. Il représente un échec direct de votre expérience client, une augmentation des appels au support d'accueil et une occasion manquée de capturer les données de première main qui justifient votre investissement dans l'infrastructure sans fil. Dans ce point technique, nous allons examiner ce qui se passe 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'un Captive Portal fait réellement au niveau du réseau. La plupart des gens le considèrent 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. 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 fournisseur. Les appareils Apple interrogent captive.apple.com. Les appareils Android interrogent connectivitycheck.gstatic.com. Les appareils Windows interrogent msftconnecttest.com. Firefox a 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 va bien. 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 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 Captive Portal - pour afficher la page de connexion. Voilà pour le scénario idéal. Voyons maintenant les six manières dont cela peut échouer. Cause première numéro un : l'épuisement du pool DHCP. C'est le tueur silencieux lors des événements à forte 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 DHCP est définie 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 : définissez les durées de bail DHCP des invités entre 15 et 30 minutes pour les environnements à fort taux de 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 du 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 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 forme d'écran vide. Si vous proposez une connexion via les réseaux sociaux (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 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 le snooping 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, cela est disponible nativement. Cause première numéro quatre : le blocage de la redirection par HSTS. Le protocole HSTS (HTTP Strict Transport Security) 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 rediriger vers le portail, le navigateur détecte une non-correspondance de certificat. Il affiche 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 ne doit rediriger que les sondes d'évaluation 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. iOS 14 et Android 11 (et versions supérieures) prennent cela en charge de manière native. Cause profonde numéro cinq : 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 sonde 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. Cause profonde numéro six : la randomisation de l'adresse MAC qui rompt la persistance de la session. Les appareils iOS et Android modernes utilisent par défaut des adesses MAC randomisées comme fonctionnalité de confidentialité. Chaque fois qu'un appareil se connecte à un réseau, il peut présenter une adresse MAC différente. Puisque l'état de la session du Captive Portal est suivi par adresse MAC, un invité authentifié il y a une heure peut se voir présenter à nouveau la page de connexion après la rotation de l'adresse MAC de son appareil. La solution côté utilisateur 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 (Layer 2) à l'aide d'identifiants plutôt que d'adresses MAC, rendant la randomisation obsolète. --- SECTION 3 : Recommandations de mise en œuvre et pièges à éviter - environ 2 minutes Maintenant que nous comprenons les causes profondes, voyons à quoi ressemble concrètement 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 slash-24. Utilisez un slash-22 ou plus grand, et définissez des durées de bail (lease times) adaptées au profil de fréquentation de votre site. Un hôtel configure les baux sur 8 heures. Un stade les configure sur 3 heures. Un centre commercial les configure sur 90 minutes. Un centre de conférence les configure sur 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 automatiquement ces entrées de walled garden dans le cadre de notre service managé 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 public de confiance émis par une autorité de certification reconnue. Les certificats auto-signés déclencheront des avertissements sur le navigateur de chaque appareil. Renouvelez les certificats avant leur expiration – un certificat expiré est l'une des causes les plus fréquentes de pannes soudaines de portail à l'échelle de tout un site. Un piège classique pour 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 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 stratégique. Les Captive Portals sont une technologie mature, mais ils génèrent inévitablement des frictions. 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 forfait Connect. Des sites comme Premier Inn et Manchester Airports Group déploient déjà cette solution pour éliminer les frictions de réauthentification pour les visiteurs récurrents, tout en garantissant une totale conformité GDPR et la capture de données de première main. --- SECTION 4 : Questions-réponses rapides - environ 1 minute Passons en revue les questions les plus fréquentes posées par les équipes informatiques des sites. 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. Si ce domaine est bloqué par votre pare-feu ou ne figure pas dans votre walled garden, les appareils Android ne déclencheront jamais le portail. Ajoutez-le explicitement. Question : Un visiteur indique que le portail s'est chargé mais qu'il ne parvient 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, que le secret partagé correspond des deux côtés et examinez les journaux RADIUS pour y rechercher des messages Access-Reject. Question : Comment gérer les visiteurs qui sont déconnectés après seulement quelques minutes ? Réponse : 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 une inactivité 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 à au moins 30 minutes pour les environnements de l'hôtellerie et du commerce de détail. --- SECTION 5 : Résumé et prochaines étapes - environ 1 minute En résumé : les pannes de Captive Portal WiFi pour visiteurs se classent en six catégories - épuisement du DHCP, échec d'interception DNS, walled garden incomplet, blocage des redirections HSTS, VPN actif sur l'appareil client et randomisation des adresses MAC. Chacune a une solution spécifique et testable. Pour votre équipe informatique, les actions immédiates sont : auditer la durée des baux 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 à partir d'un nouvel appareil non authentifié après chaque modification de configuration. Pour votre feuille de route à plus long terme, évaluez OpenRoaming comme successeur de la réauthentification par Captive Portal pour les visiteurs récurrents. 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 du forfait Connect. Pour plus de guides techniques, d'études de cas et de ressources de mise en œuvre, visitez purple.ai. Merci d'avoir écouté ce briefing technique Purple. Gardez vos réseaux fiables et vos visiteurs connectés.