Résoudre l'erreur connecté mais pas d'accès internet sur un WiFi invité

Résoudre l'erreur "Connecté mais pas d'internet" sur le WiFi invité — Une présentation technique de Purple [INTRODUCTION & CONTEXTE — environ 1 minute] Bienvenue dans la série de présentations techniques de Purple. Je suis votre hôte, et nous abordons aujourd'hui l'un des problèmes les plus persistants et frustrants de la mise en réseau de sites 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 toutes les barres de signal, il est associé à votre point d'accès, une adresse IP lui a été attribuée - et pourtant le navigateur ne renvoie rien. Le Captive Portal ne se charge jamais. L'invité appelle la réception. Votre équipe de support effectue un test de ping, tout semble correct sur le papier, et pourtant le problème persiste. Voici ce qu'il en est : 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, ni d'une mauvaise configuration du pare-feu, ni d'un problème de bande passante au sens traditionnel. Il s'agit d'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 en détail 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 bases. 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, téléphones 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, du type 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 - généralement 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'une panne de connectivité - c'est un échec de réponse DNS. Alors pourquoi le DNS échoue-t-il sur un réseau encombré ? C'est le point qui piège de nombreuses équipes. Par défaut, les requêtes DNS sont envoyées via UDP sur le port 53. UDP est un protocole sans connexion - il n'y a pas de poignée de main, pas d'accusé de réception, pas de retransmission au niveau de la couche transport. Si un paquet DNS est abandonné en raison de la congestion du réseau, le client attend simplement l'expiration du délai d'attente, puis réessaye 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 congrès pendant une conférence - la liaison montante et le résolveur DNS peuvent devenir saturés très rapidement. 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 fournisseur d'accès internet ou un résolveur public comme 8.8.8.8. Lorsque chaque appareil du réseau recherche simultanément la détection du 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 d'une plage normale de moins de 50 millisecondes à des centaines, voire des milliers de millisecondes. Les délais d'attente commencent à expirer. Les erreurs « connecté, pas d'internet » commencent à affluer. Il existe également un mécanisme secondaire qui mérite d'être compris : l'expiration du TTL. Les réponses DNS incluent une valeur de durée de vie (Time To Live) qui indique à l'appareil récepteur pendant combien de temps stocker l'adresse IP résolue en cache. Sur un réseau encombré où les appareils s'associent et se désassocient constamment - ce qui est courant dans les lieux à forte densité - les entrées en cache expirent et doivent être fréquemment résolues à nouveau. 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é. La réponse traditionnelle à ce problème consiste à augmenter la bande passante - mettre à niveau la liaison amont, ajouter des points d'accès supplémentaires, mettre en œuvre 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 d'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 situe 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 délais d'attente de deux à trois secondes à des réponses inférieures à 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. D'un point de vue normatif, cette architecture s'aligne sur les recommandations de l'IEEE 802.11 pour les déploiements à haute densité et prend en charge 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 de secteur public ou d'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 votre infrastructure de résolution d'entreprise. [RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER — environ 2 minutes] Permettez-moi de vous donner des conseils pratiques de 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 invité et le résolveur ajoute de la latence. Si votre filtre DNS est hébergé dans un centre de données distant et que votre réseau invité se trouve dans un hôtel à Manchester, vous ajoutez un temps de trajet aller-retour qui va à l'encontre du but recherché. Utilisez une appliance locale 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 constate. 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 s'authentifier - 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 fournir 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 qu'une entrée mise en cache expire pour ensuite solliciter un résolveur en 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 de VPN d'entreprise, stockage cloud. Cela génère un autre type de ticket de support, mais est tout aussi préjudiciable à l'expérience des invités. Commencez par une politique prudente, surveillez les journaux de requêtes DNS pour identifier les domaines bloqués, et affinez-les 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 pour mes invités ?" Vous 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 délai d'attente 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' ?" Lancez 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 délai d'attente DNS est le 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 nativement. [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 - il s'agit d'un filtre DNS d'entreprise local et performant qui résout rapidement les sondes de détection de Captive Portal, maintient un cache local et applique un filtrage basé sur des règles pour réduire la charge de requêtes en amont. Les trois actions à mener cette semaine : lancez 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 déterminez 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 l'un de ces sujets, la documentation de la plateforme Purple détaille la configuration du filtre DNS, et les guides d'optimisation du WiFi invité sur purple.ai valent la peine d'être consultés en parallèle de ce briefing. Merci pour votre écoute - à la prochaine. [FIN DE L'ÉPISODE]