Résoudre l'erreur "Connecté mais pas d'Internet" sur le WiFi invité

Résoudre l'erreur "Connecté mais pas d'Internet" sur le WiFi invité — Un briefing technique Purple [INTRODUCTION & CONTEXTE — environ 1 minute] Bienvenue dans la série des briefings techniques Purple. Je suis votre hôte, et aujourd'hui nous nous attaquons à l'un des problèmes les plus persistants et frustrants des réseaux d'entreprise : l'erreur "connecté, pas d'Internet" sur le WiFi invité. Si vous gérez l'infrastructure WiFi d'un hôtel, d'une chaîne de magasins, d'un stade ou d'un centre de conférences, vous y avez déjà été confronté. L'appareil d'un invité affiche un signal maximal, il est associé à votre point d'accès, une adresse IP lui a été attribuée — et pourtant, le navigateur ne charge rien. Le Captive Portal ne s'affiche jamais. L'invité appelle la réception. Votre équipe d'assistance lance un test de ping, tout semble correct sur le papier, et pourtant le problème persiste. Voici la réalité : dans la grande majorité des cas que je rencontre sur les déploiements d'entreprise, il ne s'agit pas d'une panne matérielle, d'une mauvaise configuration du pare-feu, ni d'un problème de bande passante au sens traditionnel. C'est un problème de timing DNS — et il est presque toujours déclenché par la congestion du réseau. Aujourd'hui, je souhaite vous expliquer exactement pourquoi cela se produit, comment le diagnostiquer de manière fiable et comment le déploiement d'un filtre DNS d'entreprise résout définitivement ce goulot d'étranglement. [ANALYSE TECHNIQUE APPROFONDIE — environ 5 minutes] Commençons par les fondamentaux. Lorsqu'un appareil invité se connecte à votre réseau WiFi, la toute première chose qu'il doit faire — avant de pouvoir charger une seule page web, avant que votre Captive Portal ne puisse le rediriger, avant que toute authentification ne puisse avoir lieu — est de résoudre un nom de domaine en une adresse IP via le DNS. Le Domain Name System est l'annuaire d'Internet. Sans lui, votre appareil n'a aucun moyen de savoir où envoyer le trafic. C'est là que le problème commence. La plupart des appareils grand public — iPhones, terminaux Android, ordinateurs portables Windows — disposent d'un mécanisme intégré appelé sonde de détection de Captive Portal. Sur iOS, par exemple, l'appareil envoie une requête HTTP à un point de terminaison Apple connu, tel que captive.apple.com. Sur Android, il interroge connectivitycheck.gstatic.com. Sur Windows, il teste msftconnecttest.com. Ces sondes sont conçues pour détecter si le réseau nécessite une page de connexion avant d'autoriser l'accès à Internet. Le point critique est le suivant : ces sondes dépendent du DNS. L'appareil doit d'abord résoudre le nom de domaine du point de terminaison de la sonde avant de pouvoir envoyer la requête HTTP. Et cette requête DNS a un délai d'expiration (timeout) — généralement compris entre une et cinq secondes selon le système d'exploitation. Si le résolveur DNS de votre réseau ne répond pas dans ce laps de temps, l'appareil en conclut que le réseau n'a pas de connectivité Internet, même s'il est entièrement associé et dispose d'une adresse IP valide. C'est cela, l'erreur "connecté, pas d'Internet". Il ne s'agit pas d'un échec de connectivité — c'est un échec de réponse DNS. Alors, pourquoi le DNS échoue-t-il sur un réseau encombré ? C'est l'aspect qui piège de nombreuses équipes. Par défaut, les requêtes DNS sont envoyées via UDP sur le port 53. L'UDP est un protocole sans connexion : il n'y a pas de poignée de main (handshake), pas d'accusé de réception, pas de retransmission au niveau de la couche transport. Si un paquet DNS est abandonné en raison d'une congestion du réseau, le client attend simplement l'expiration du délai d'attente (timeout), puis réessaie ou abandonne. Sur un réseau WiFi invité comptant des centaines ou des milliers d'appareils simultanés — pensez à un stade pendant un match, un hôtel complet, un centre de conférence pendant une conférence plénière — la liaison montante et le résolveur DNS peuvent très rapidement arriver à saturation. Le problème est aggravé par le fait que les réseaux invités partagent généralement un seul résolveur DNS en amont, souvent le résolveur par défaut du FAI ou un résolveur public comme 8.8.8.8. Lorsque chaque appareil du réseau tente simultanément de détecter le Captive Portal, exécute des mises à jour d'applications en arrière-plan et effectue des requêtes DNS pour les réseaux sociaux et les services de streaming, ce résolveur unique devient un goulot d'étranglement. Les temps de réponse des requêtes passent de la plage normale de moins de 50 millisecondes à des centaines, voire des milliers de millisecondes. Les timeouts commencent à se produire. Les erreurs « connecté, pas d'internet » commencent à affluer. Il existe également un mécanisme secondaire important à comprendre : l'épuisement du TTL. Les réponses DNS incluent une valeur TTL (Time To Live) qui indique à l'appareil récepteur combien de temps il doit conserver en cache l'adresse IP résolue. Sur un réseau encombré où les appareils s'associent et se dissocient constamment — ce qui est fréquent dans les lieux à forte densité — les entrées mises en cache expirent et doivent être résolues à nouveau fréquemment. Cela augmente la charge de requêtes DNS sur le résolveur précisément au moment où le réseau est le plus sollicité. Face à ce problème, la réponse traditionnelle consiste à augmenter la bande passante : mettre à niveau la liaison montante, ajouter des points d'accès, implémenter des politiques de QoS. Ce sont toutes des mesures valables, mais elles ne s'attaquent pas à la cause profonde. La cause profonde est que votre chemin de résolution DNS n'est pas optimisé pour les environnements invités à haute densité. Et c'est précisément ce qu'un filtre DNS d'entreprise résout. Un filtre DNS d'entreprise — tel que la fonctionnalité de filtrage DNS intégrée à la plateforme de WiFi invité de Purple — fonctionne comme un résolveur DNS local à haute performance qui se place entre vos appareils invités et l'internet en amont. Plutôt que de transférer chaque requête vers un résolveur public distant, il maintient un cache local des domaines fréquemment résolus, gère nativement les requêtes de détection de Captive Portal et applique un filtrage basé sur des politiques pour bloquer les domaines malveillants ou non conformes avant même qu'ils n'atteignent le résolveur en amont. Le résultat est une réduction spectaculaire de la latence des requêtes DNS — passant généralement de timeouts de deux à trois secondes à des réponses de moins de 200 millisecondes — ce qui signifie que les requêtes de détection de Captive Portal réussissent dès la première tentative, que l'erreur « connecté, pas d'internet » disparaît et que le temps d'accès des invités diminue considérablement. Du point de vue des normes, cette architecture s'aligne sur les recommandations de l'IEEE 802.11 pour les déploiements à haute densité et favorise la conformité avec les exigences de traitement des données du GDPR en vous permettant d'enregistrer et d'auditer les requêtes DNS — ce qui est particulièrement pertinent si vous opérez sous une licence du secteur public ou de l'hôtellerie. Elle répond également aux exigences de segmentation réseau de la norme PCI DSS en garantissant que le trafic DNS des invités est isolé de l'infrastructure de résolution de votre entreprise. [RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER — environ 2 minutes] Permettez-moi de vous donner des conseils pratiques pour le déploiement. Lorsque vous déployez un filtre DNS d'entreprise sur un réseau WiFi invité, trois décisions de configuration détermineront votre succès ou votre échec. Premièrement, l'emplacement du résolveur. Votre filtre DNS doit être déployé le plus près possible du réseau invité — idéalement sur le même VLAN ou sous-réseau que vos points d'accès invités. Chaque saut entre l'appareil de l'invité et le résolveur ajoute de la latence. Si votre filtre DNS se trouve dans un centre de données distant et que votre réseau invité est dans un hôtel à Manchester, vous ajoutez un temps de trajet aller-retour qui va à l'encontre de l'objectif recherché. Utilisez un équipement local ou un filtre DNS basé sur le cloud avec un point de présence régional. Deuxièmement, le passthrough DNS du Captive Portal. C'est la configuration erronée la plus courante que je rencontre. Lorsque vous déployez un filtre DNS, vous devez vous assurer que le propre domaine du Captive Portal — l'URL vers laquelle les invités sont redirigés pour l'authentification — est mis sur liste blanche dans le filtre. Si le filtre bloque ou retarde la résolution du domaine de votre Captive Portal, vous recréerez exactement le problème que vous essayiez de résoudre. Testez toujours explicitement la résolution du Captive Portal après avoir déployé une politique de filtrage DNS. Troisièmement, l'ajustement du TTL. Configurez votre résolveur DNS local pour qu'il serve des TTL courts pour les domaines de test de détection de Captive Portal — Apple, Google, Microsoft — afin que les appareils effectuent des requêtes fréquentes et obtiennent toujours une réponse locale rapide, plutôt que d'attendre l'expiration d'une entrée en cache pour ensuite solliciter un résolveur amont encombré. Un TTL de 30 à 60 secondes pour ces domaines spécifiques constitue un point de départ raisonnable. Le piège à éviter est le sur-filtrage. Certaines équipes déploient des listes de blocage DNS agressives qui bloquent par inadvertance des domaines utilisés par des applications d'invités légitimes — services de streaming, terminaux VPN d'entreprise, stockage cloud. Cela génère un autre type de ticket d'assistance, mais s'avère tout aussi préjudiciable à l'expérience des invités. Commencez par une politique conservatrice, surveillez les journaux de requêtes DNS pour identifier les domaines bloqués, et affinez-la sur une période de deux semaines avant de verrouiller la configuration. [SÉANCE DE QUESTIONS-RÉPONSES RAPIDES — environ 1 minute] Passons en revue les questions que l'on me pose le plus souvent à ce sujet. "Puis-je simplement utiliser 8.8.8.8 comme résolveur DNS invité ?" Vous le pouvez, mais en cas de forte charge, il expirera. Un résolveur local ou régional sera toujours plus performant qu'un résolveur public sur un réseau encombré. « Est-ce que cela affecte les déploiements WPA3 ? » Non — le WPA3 améliore la sécurité de l'authentification mais ne modifie pas le chemin de résolution DNS. Le même problème de timeout DNS se produit quel que soit le standard de chiffrement utilisé. « Comment savoir si le DNS est la cause réelle de mes erreurs "connecté, pas d'Internet" ? » Effectuez une capture de paquets sur le VLAN invité pendant les heures de pointe. Filtrez le trafic sur le port UDP 53. Si vous constatez des requêtes DNS sans réponse correspondante dans les deux secondes, le timeout DNS est votre coupable. « Un filtre DNS d'entreprise aide-t-il à la conformité ? » Oui — la journalisation des requêtes DNS fournit une piste d'audit qui soutient les obligations de responsabilité du GDPR et peut aider à la réponse aux incidents. La plateforme de Purple intègre cette journalisation de manière native. [RÉSUMÉ & PROCHAINES ÉTAPES — environ 1 minute] Pour résumer : l'erreur "connecté, pas d'Internet" sur le WiFi invité est majoritairement un problème de timing DNS causé par une congestion du réseau qui sature un chemin de résolution non optimisé. La solution n'est pas d'augmenter la bande passante — c'est d'utiliser un filtre DNS d'entreprise local et performant qui résout rapidement les requêtes de détection de Captive Portal, maintient un cache local et applique un filtrage basé sur des règles pour réduire la charge des requêtes en amont. Les trois actions à mener cette semaine : effectuez une capture de paquets DNS pendant les heures de pointe pour confirmer le diagnostic ; passez en revue l'emplacement actuel de votre résolveur DNS et identifiez s'il est local ou distant ; et évaluez le déploiement d'un filtre DNS d'entreprise sur votre VLAN invité. Si vous souhaitez approfondir le sujet, la documentation de la plateforme Purple couvre en détail la configuration du filtre DNS, et les guides d'optimisation du WiFi invité sur purple.ai méritent d'être consultés en parallèle de ce briefing. Merci pour votre écoute — à la prochaine. [FIN DE L'ÉPISODE]