Résoudre l'erreur « Connecté, pas d'accès Internet » sur le WiFi invité

L'erreur de connexion sans accès Internet sur le WiFi invité se produit lorsque les vérifications de connectivité échouent avant le chargement du portail captif. Dans les lieux fréquentés, les requêtes DNS sur le port UDP 53 (RFC 1035) expirent en cas de congestion. Pour résoudre ce problème, vous devez pointer les étendues DHCP des invités vers un filtre DNS de mise en cache, renseigner les domaines du walled garden sur l'ensemble des contrôleurs tels que Cisco Meraki et revoir les règles de shaping du trafic.

À quoi ressemble l'erreur « connecté, pas d'accès Internet » sur le WiFi invité ?

L'invité voit des barres de signal maximales et un réseau rejoint, mais rien ne se charge. La page de connexion n'apparaît jamais, ce qui l'empêche d'accepter les conditions ou de s'identifier. Il se dirige alors vers la réception, le point d'information ou le comptoir de service.

Chaque système d'exploitation formule l'avertissement différemment. L'équipe d'assistance de votre site doit être en mesure de tous les reconnaître :

• Windows affiche « Pas d'accès Internet » sous le nom du réseau.
• Android affiche « Connecté sans accès Internet » ou « Internet n'est peut-être pas disponible ».
• L'iPhone et l'iPad affichent « Pas de connexion Internet » sous le nom du réseau.

Ces trois messages proviennent du même mécanisme. Après avoir rejoint le réseau, l'appareil interroge une adresse web connue pour tester la connexion. Si ce test renvoie la page attendue, l'appareil considère que la connexion fonctionne. S'il renvoie une page de connexion, l'appareil ouvre le portail captif. S'il n'obtient aucune réponse, l'appareil indique « pas d'accès Internet ».

Avant que l'appareil puisse demander l'une de ces pages, il doit rechercher le nom d'hôte via le DNS. C'est lors de cette recherche que débutent la plupart des échecs dans les zones à forte densité.

Quelles sont les causes habituelles des erreurs de connexion sans accès Internet sur le WiFi invité ?

Expirations des requêtes DNS sur un réseau saturé

Le DNS (Domain Name System) traduit un nom d'hôte en adresse IP. La plupart des requêtes DNS transitent par le port UDP 53, comme défini dans la norme RFC 1035. UDP ne disposant d'aucune retransmission intégrée, une requête abandonnée attend simplement le temporisateur de rétentative propre à l'appareil.

La congestion survient par pics. Pensez à la mi-temps dans un stade, au départ des clients d'un hôtel après le petit-déjeuner ou à l'arrivée d'un train en gare. Des centaines d'appareils se connectent en quelques secondes, et chacun d'eux envoie une recherche simultanément. Si le résolveur se trouve à plusieurs sauts de distance sur une liaison WAN saturée, les requêtes sont retardées ou abandonnées. L'appareil abandonne, le portail ne s'ouvre jamais et l'invité voit la mention « pas d'accès Internet ».

Les autres causes fréquentes

Le DNS constitue la cause la plus fréquente dans les lieux à forte fréquentation, mais ce n'est pas la seule. Vérifiez également les points suivants :

• Entrées de walled garden manquantes. Le walled garden est la liste des domaines qu'un appareil peut atteindre avant de s'identifier. Si votre portail ou ses ressources sont manquants, la page ne peut pas se charger.
• Épuisement du pool DHCP. Si le pool d'adresses est épuisé, les appareils s'attribuent une adresse 169.254.x.x et ne peuvent rien atteindre.
• Limitation du débit ou étranglement QoS du port UDP 53. Une limite trop stricte définie par client ou par SSID peut priver le DNS de ressources lors d'un pic d'activité.
• DNS chiffré. Le DNS sur HTTPS (DoH, RFC 8484) et le DNS sur TLS (DoT, RFC 7858) envoient les requêtes à des résolveurs externes. Un walled garden qui bloque ces résolveurs interrompt la recherche avant la connexion.
• Une panne en amont. Si la liaison WAN elle-même est interrompue, tous les équipements échouent, ainsi que tous les ports filaires.

Comment identifier la cause de votre problème ?

Commencez par analyser le schéma d'occurrence, pas le matériel. Utilisez cette matrice pour cibler la cause avant de modifier quoi que ce soit.

Trois vérifications que votre équipe de support peut effectuer

1. Vérifier l'adresse IP de l'équipement. Une adresse 169.254.x.x indique un problème de DHCP, pas de DNS. Une adresse normale dans la plage invitée signifie que l'équipement a rejoint le réseau correctement.
2. Mesurer le temps d'une recherche depuis un équipement de test. Exécutez nslookup captive.apple.com depuis un ordinateur portable sur le réseau invité. Une réponse lente ou un échec pendant une période chargée confirme l'existence d'un goulot d'étranglement DNS.
3. Capturer les paquets sur le VLAN invité. Un VLAN (LAN virtuel) sépare le trafic invité de vos autres réseaux. Filtrez la capture sur udp port 53 et recherchez les requêtes sans réponse correspondante.

Consultez ensuite le moment où les erreurs se produisent. Dans WiFi Analytics, comparez les volumes de connexion et d'authentification par rapport aux moments où les invités signalent des problèmes. Les échecs qui suivent vos heures les plus chargées indiquent clairement une congestion.

Comment un filtre DNS d'entreprise résout-il le goulot d'étranglement ?

Un filtre DNS d'entreprise est un résolveur que vous contrôlez, placé à proximité du réseau invité. Il remplace le résolveur distant du FAI ou le résolveur public distribué par le DHCP actuellement. Il accomplit trois tâches qui éliminent le dépassement de délai.

Il répond depuis le cache. Les noms d'hôte de vérification de connectivité sont demandés des milliers de fois par heure dans un établissement fréquenté. Un filtre à proximité répond aux recherches répétées à partir de son cache, de sorte qu'elles ne traversent jamais la liaison WAN congestonnée.

Il rejette le trafic indésirable au préalable. Les requêtes destinées à des catégories malveillantes ou bloquées sont refusées au niveau du filtre. Cela libère de la capacité WAN pour les recherches importantes.

Il enregistre chaque requête. Vous obtenez un historique des domaines qui ont échoué, à quel moment et à quelle fréquence. Cela transforme les hypothèses en preuves la prochaine fois qu'un responsable signale un problème.

Où le placer

Pour un parc distribué, comme une chaîne de secteur de la vente au détail comprenant des centaines de petits sites, un filtre fourni dans le cloud avec des emplacements Edge à proximité constitue généralement le choix le plus pratique. Pour un site unique de grande taille, comme un stade ou un centre de conférences, un résolveur hébergé sur site conserve les recherches totalement en dehors du WAN. Dans les deux cas, fournissez deux adresses de résolveur dans le DHCP afin qu'une seule panne ne puisse pas interrompre le réseau.

Deux paramètres qui déterminent la réussite

Tout d'abord, autorisez les domaines de votre portail captif dans le filtre. Un filtre qui bloque ou ralentit le portail reproduit exactement l'erreur que vous cherchiez à corriger. Deuxièmement, séparez le DNS invité du DNS d'entreprise. La norme PCI DSS considère la segmentation du réseau comme le moyen de maintenir un réseau invité hors de la portée de votre environnement de données des titulaires de cartes.

Comment résoudre ce problème sur chaque fournisseur et système d'exploitation ?

Sur vos points d'accès et votre contrôleur

Purple est indépendant du matériel et fonctionne comme une superposition cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Le correctif suit les trois mêmes étapes sur chacun d'entre eux :

1. Mettre à jour les serveurs DNS dans l'étendue DHCP invité vers votre filtre DNS d'entreprise.
2. Compléter le walled garden. Cisco Meraki, HPE Aruba et Ruckus utilisent tous le terme « walled garden ». Suivez l'article de configuration Purple correspondant à votre fournisseur, qui répertorie les domaines exacts à autoriser.
3. Vérifier le modelage du trafic invité (traffic shaping) afin que les limites par client ne brident pas le port UDP 53 lors d'un pic d'activité.

Ne copiez pas les paramètres d'un fournisseur à l'autre. Les noms de menus et les valeurs par défaut diffèrent ; utilisez donc la documentation propre au fournisseur en parallèle de l'article de configuration Purple.

Sur l'appareil de l'invité

Lorsqu'un seul invité est touché et que tout fonctionne pour les autres, votre équipe de support peut essayer ces étapes :

• Oublier le réseau et le rejoindre à nouveau pour déclencher une nouvelle vérification de la connectivité.
• Ouvrir une adresse http:// simple dans le navigateur pour forcer l'affichage du portail.
• Sur Android, régler le DNS privé sur Automatique. Un fournisseur de DNS privé fixe peut bloquer la recherche avant la connexion.
• Suspendre toute application VPN jusqu'à ce que l'invité se soit connecté.

Scénarios appliqués

Les chiffres ci-dessous sont présentés à titre illustratif et ne proviennent pas d'un déploiement spécifique. Utilisez-les comme modèle pour déterminer ce qu'il convient de mesurer sur votre propre site.

Un hôtel de 200 chambres au moment du petit-déjeuner

Situation. Les réclamations à la réception concernant l'absence d'Internet se concentrent entre 7 h et 9 h, lorsque les clients consultent leurs e-mails avant de régler leur départ. Les points d'accès affichent un signal de bonne qualité et du temps d'antenne disponible. Le DHCP invité fournit le résolveur du fournisseur d'accès Internet, situé à plusieurs sauts sur une ligne très sollicitée.

Mesures prises. Le responsable informatique a exécuté nslookup pendant la période de pointe et a constaté que les recherches échouaient systématiquement. L'équipe a orienté le DHCP invité vers un filtre DNS cloud, a ajouté les domaines du portail au walled garden et a maintenu le DNS invité séparé du réseau de gestion de l'établissement.

Résultat. Mesurées dans l'outil d'analyse WiFi Analytics et sur le registre de la réception, les finalisations de connexion au portail lors des pics d'affluence sont passées de 81 % à 97 %. Les réclamations liées au WiFi à la réception ont chuté, passant d'environ 15 par matinée à deux. Pour en savoir plus sur les réseaux invités pour l'hôtellerie, consultez nos pages consacrées au secteur hospitalité.

Un stade de 30 000 places à la mi-temps

Situation. Les supporters signalaient l'erreur « connecté sans accès à Internet » à chaque mi-temps, alors que les dix premières minutes de chaque période se déroulaient sans encombre. Les captures de paquets sur le VLAN invité ont révélé des requêtes DNS restées sans réponse pendant la hausse de trafic.

Action menée. L'architecte réseau a déployé un résolveur sur site avec une solution de secours dans le cloud. L'équipe a supprimé la limitation de débit par client qui bridait le port UDP 53 et a basculé l'étendue DHCP vers le nouveau résolveur.

Résultat. Les requêtes DNS sans réponse à la mi-temps sont passées de 12 % à moins de 1 % lors des captures de suivi. Les connexions de supporters pendant la pause ont augmenté de 40 % par rapport au match précédent.

Comment éviter que les erreurs de type connecté sans Internet ne se reproduisent ?

• Ne comptez jamais uniquement sur un résolveur public distant. Les serveurs DNS publics offrent généralement de bonnes performances, mais un résolveur situé à plusieurs sauts réseau ajoute un délai incontrôlable lors des pics d'affluence.
• Configurez des alertes sur les requêtes DNS sans réponse. Configurez votre pare-feu ou votre commutateur cœur de réseau pour signaler l'augmentation des rejets sur le port UDP 53 sur le réseau invité, lesquels révèlent des expirations de délai avant même que les visiteurs ne s'en aperçoivent.
• Révisez chaque mois les listes de blocage de votre filtre DNS. Des catégories trop agressives bloquent des applications légitimes et génèrent de nouveaux tickets d'assistance.
• Définissez une durée de conservation des journaux. Les journaux DNS associent des adresses IP aux domaines visités ; traitez-les donc comme des données à caractère personnel conformément au GDPR.
• Adoptez la norme RFC 8910 si votre matériel la prend en charge. Elle permet au serveur DHCP d'indiquer à l'équipement l'emplacement du portail captif, réduisant ainsi sa dépendance aux vérifications de connectivité.
• Pensez à Passpoint pour les visiteurs réguliers. Passpoint (également appelé Hotspot 2.0) et OpenRoaming permettent aux équipements de se connecter en toute sécurité sans portail captif, ce qui élimine complètement ce mode de défaillance.

Purple gère le WiFi invité dans plus de 80 000 sites actifs répartis dans plus de 90 pays, avec 500 millions d'utilisateurs et de connexions par an. Des salles d'attente du secteur de la santé jusqu'aux transports ferroviaires, le constat reste le même : réglez les problèmes de DNS avant d'investir dans de la bande passante.

Foire aux questions

Faut-il remplacer nos points d'accès pour résoudre les erreurs de type connecté sans Internet ?

Non, dans la plupart des cas, ce n'est pas nécessaire. Lorsque l'erreur survient lors des pics d'affluence, la cause provient généralement de la résolution DNS et non du matériel des points d'accès. La solution consiste à modifier la configuration : pointez le serveur DHCP invité vers un filtre DNS d'entreprise à proximité, finalisez le walled garden et révisez les règles de limitation de trafic. Ne remplacez le matériel qu'après avoir constaté, via des captures de paquets, que les points d'accès eux-mêmes rejettent du trafic en charge normale, et après avoir écarté tout dysfonctionnement DHCP et DNS.

La solution Purple est-elle compatible avec notre matériel existant ?

Oui, Purple fonctionne sur les points d'accès que vous possédez déjà. Purple est indépendant du matériel et se déploie sous forme de superposition cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Il n'y a pas besoin de tout remplacer. Purple publie un article de configuration pour chaque fournisseur, répertoriant les domaines de jardin captif dont votre contrôleur a besoin pour que le portail captif se charge avant que les invités ne se connectent.

Un filtre DNS d'entreprise ralentira-t-il notre WiFi invité ?

Non, un filtre DNS bien placé accélère généralement les recherches. Il est situé plus près du réseau invité qu'un FAI ou un résolveur public et répond aux recherches répétées à partir de son cache. Le risque réside dans l'emplacement et la configuration, pas dans le filtrage lui-même. Fournissez deux adresses de résolveur pour la redondance et autorisez les domaines de votre portail captif afin que le filtre ne retarde jamais la page de connexion.

Pourquoi ne pas simplement fournir aux invités un résolveur public tel que 8.8.8.8 ?

Vous pouvez le faire, mais cela ne résout pas les délais d'expiration liés à la congestion. Un résolveur public se trouve toujours de l'autre côté de votre liaison WAN, de sorte que chaque recherche entre en concurrence avec le pic de trafic qui cause la défaillance. Cela ne vous offre également aucun filtrage ni aucun journal de requêtes pour le dépannage. Un filtre d'entreprise proche répond à partir du cache, refuse les catégories non désirées et enregistre chaque recherche échouée, ce que le DNS public ne peut pas faire pour vous.

Comment gérer les journaux de requêtes DNS dans le cadre du GDPR ?

Traitez les journaux DNS comme des données personnelles, car ils lient les adresses IP aux domaines visités par un appareil. Définissez une durée de conservation précise, limitez l'accès à votre équipe réseau et sécurité, et inscrivez la finalité dans votre politique de confidentialité. Purple est certifié ISO 27001 et conforme au GDPR, et votre fournisseur de filtre DNS doit faire preuve d'une certification équivalente avant que vous ne routiez le trafic invité via son service.

Quel effort le déploiement nécessite-t-il ?

La modification elle-même est minime ; le test représente la majeure partie de l'effort. Vous mettez à jour les serveurs DNS dans l'étendue DHCP invité, ajoutez les domaines du portail à la liste d'autorisations du filtre et vérifiez le jardin captif. Prévoyez de tester lors d'un pic réel, comme le rush du petit-déjeuner ou la mi-temps, car un après-midi calme ne reproduira pas la congestion qui a causé l'erreur.

Passpoint ou OpenRoaming supprimeront-ils l'erreur ?

Oui, pour les appareils qui les utilisent. Passpoint et OpenRoaming permettent aux appareils de se connecter en toute sécurité sans portail captif, il n'y a donc pas de portail susceptible d'échouer. Les nouveaux visiteurs et les appareils sans profil Passpoint utilisent toujours le portail captif, vous avez donc toujours besoin d'un DNS rapide et d'un jardin captif complet. Exécutez les deux ensemble : Passpoint pour les visiteurs réguliers, et un portail optimisé pour tous les autres.