Passer au contenu principal
Français

Pourquoi votre Captive Portal ne se charge pas sur iPhone : Résoudre les erreurs CNA Apple

Dépannez et résolvez les échecs d'affichage des fenêtres contextuelles de Captive Portal sur iPhone et iOS. Découvrez comment Apple CNA, iCloud Private Relay et la randomisation MAC perturbent les connexions WiFi, et comment y remédier.

Par Tom HackettPublié le
📖 10 min de lecture1,943 mots2 exemples concrets3 questions d'entraînement6 définitions clés

Video overview

Écouter ce guide

Voir la transcription du podcast
[Musique d'introduction : Synth-pop électronique moderne et entraînante avec des touches de piano épurées, établissant un ton professionnel et axé sur la technologie] **Hôte (Consultant Senior)** : Bonjour et bienvenue dans ce Point Technique Purple. Je suis votre hôte, et aujourd'hui, nous plongeons au cœur de l'un des problèmes les plus courants - et franchement, les plus frustrants - auxquels sont confrontés les administrateurs réseau, les responsables informatiques et les directeurs d'exploitation de sites aujourd'hui. Nous sommes tous passés par là. Vous avez passé des semaines à planifier, configurer et déployer un réseau WiFi invité de pointe pour votre hôtel, votre centre commercial ou votre stade. Vous disposez des derniers points d'accès, d'un contrôleur robuste et d'une magnifique page d'accueil prête à capturer les données des invités et à stimuler l'engagement. Mais ensuite, les tickets d'assistance commencent à affluer. Et ils disent tous exactement la même chose : "Je me suis connecté au WiFi invité sur mon iPhone, mais la page de connexion ne se charge pas." Pour l'invité, votre WiFi est tout simplement en panne. Mais pour nous, en tant qu'ingénieurs et architectes réseau, nous savons qu'une bataille technique complexe se joue sous le capot d'iOS. Aujourd'hui, nous allons analyser exactement pourquoi votre Captive Portal ne se charge pas sur les iPhones, comment fonctionne la logique de détection en arrière-plan d'Apple, et les étapes d'atténuation que vous pouvez mettre en œuvre sur votre réseau ce trimestre. [Brève transition musicale] **Hôte** : Commençons par l'analyse technique approfondie. Pourquoi un iPhone se connecte-t-il au WiFi invité mais ne parvient-il pas à afficher l'écran de connexion ? Pour comprendre cela, nous devons nous intéresser au **Captive Network Assistant** d'Apple, ou **CNA**. Lorsqu'un iPhone s'associe à un SSID ouvert et reçoit une adresse IP via DHCP, il n'attend pas simplement que l'utilisateur ouvre un navigateur. Au lieu de cela, un démon système en arrière-plan lance immédiatement une requête HTTP GET classique vers une URL très spécifique : `http://captive.apple.com/hotspot-detect.html`. Cette sonde en arrière-plan utilise un User-Agent système unique appelé `CaptiveNetworkSupport`. Le démon CNA attend une réponse très spécifique. Si les serveurs d'Apple renvoient un code d'état HTTP **200 OK** avec un corps contenant exactement le mot "Success", iOS en conclut que le réseau dispose d'un accès internet illimité. Il établit discrètement le WiFi comme interface de routage principale, et l'utilisateur poursuit sa navigation. Cependant, si votre passerelle réseau intercepte cette requête HTTP et renvoie un autre résultat - comme une redirection HTTP 302 ou 307, ou une page HTML personnalisée - iOS reconnaît instantanément qu'il se trouve derrière un Captive Portal. Il lance immédiatement l'application native **Websheet**. C'est cette fenêtre modale coulissante familière qui affiche votre page de connexion invité. À présent, voici le premier piège technique majeur : **Le Walled Garden** (jardin privé). De nombreux ingénieurs réseau commettent l'erreur d'ajouter les domaines de succès d'Apple, comme `captive.apple.com`, à la liste blanche de leurs listes de contrôle d'accès de pré-authentification. Ils se disent : "C'est un domaine Apple, je devrais le laisser passer." Mais si vous l'ajoutez à la liste blanche, la requête d'arrière-plan atteint avec succès les serveurs d'Apple, reçoit la réponse "Success", et iOS suppose qu'il n'y a pas de Captive Portal. La Websheet ne se déclenche jamais ! Pendant ce temps, l'utilisateur est bloqué pour accéder à tout autre site web. Donc, règle numéro un : **N'ajoutez jamais captive.apple.com à la liste blanche de votre walled garden.** [Bref effet sonore de transition] **Hôte** : Mais qu'en est-il des fonctionnalités modernes de confidentialité d'iOS ? Même avec un walled garden parfait, des fonctionnalités telles que **iCloud Private Relay** et les **adresses MAC privées** changent la donne. Parlons d'iCloud Private Relay, introduit dans iOS 15. Cette fonctionnalité chiffre et achemine le trafic DNS et HTTP de Safari via une architecture de proxy à double saut. Lorsqu'un utilisateur avec un Private Relay actif se connecte à votre WiFi invité, la requête HTTP d'arrière-plan est encapsulée dans un tunnel chiffré. Comme votre passerelle réseau ne peut pas inspecter ou intercepter ce paquet chiffré, elle ne peut pas injecter la redirection. La requête échoue silencieusement et l'iPhone affiche simplement un avertissement "Pas de connexion Internet". Pas de portail, pas de connexion, juste de la friction. Heureusement, il existe une atténuation programmatique au niveau du réseau pour cela. Apple a conçu Private Relay pour respecter les blocages au niveau du réseau. Si votre serveur DNS local renvoie une réponse **NXDOMAIN** pour les domaines Private Relay d'Apple - spécifiquement `mask.icloud.com` et `mask-h2.icloud.com` - iOS reconnaît que le réseau est incompatible avec Private Relay. Il affichera immédiatement une invite système demandant à l'utilisateur s'il souhaite "Utiliser sans Private Relay" pour ce réseau. Dès qu'il appuie sur cette option, le tunnel chiffré est contourné, la requête HTTP est interceptée et votre Captive Portal se charge parfaitement. Viennent ensuite les **adresses MAC privées** et les nouvelles **adresses MAC rotatives** dans iOS 18. Par défaut, les iPhones génèrent une adresse MAC aléatoire pour chaque SSID. Dans iOS 18, cette adresse tourne périodiquement même en étant connecté au même réseau. Si votre contrôleur sans fil suit les sessions d'invités authentifiées uniquement par l'adresse MAC, une rotation soudaine amènera la passerelle à traiter l'iPhone comme un tout nouvel appareil non authentifié. L'invité est brusquement déconnecté et obligé de se reconnecter. Pour atténuer ce problème, les sites d'entreprise doivent abandonner le simple suivi basé sur l'adresse MAC. Des plateformes comme **Purple** résolvent ce problème en déposant un cookie sécurisé et persistant dans la session du navigateur, ou mieux encore, en faisant passer les sites à **Passpoint**, également connu sous le nom de Hotspot 2.0. Passpoint utilise des profils 802.1X sécurisés pour authentifier automatiquement et en toute sécurité les invités de retour sans jamais afficher de page de Captive Portal. C'est sécurisé, c'est fluide et cela contourne complètement les limites du CNA. [Bref intermède musical de transition] **Animateur** : À présent, abordons les profils DNS personnalisés et les VPN locaux. De nombreux utilisateurs techniques installent des profils DNS personnalisés comme NextDNS ou AdGuard qui imposent un protocole DNS-over-HTTPS chiffré. Comme ces profils contournent vos serveurs DNS locaux attribués par DHCP, votre passerelle ne peut pas usurper la requête DNS pour `captive.apple.com`. De même, les profils VPN "Toujours actif" tenteront d'établir un tunnel chiffré dès qu'une adresse IP est attribuée. Si le VPN réussit, il contourne votre redirection ; s'il est bloqué, il bloque complètement la connexion. Pour ces utilisateurs, l'ultime solution manuelle est l'astuce de **neverssl.com**. Si un visiteur est connecté à votre WiFi mais que le portail ne se charge pas, dites-lui d'ouvrir Safari et de saisir `neverssl.com` dans la barre d'adresse. Comme ce domaine utilise un protocole HTTP strictement non chiffré, la passerelle est assurée d'intercepter le trafic du port 80 et de forcer le chargement de la redirection, contournant ainsi toute interférence liée à un VPN ou un DNS personnalisé. [Effet sonore : Carillon de transition rapide] **Animateur** : Passons maintenant à une session de questions-réponses rapide sur les questions les plus fréquemment posées par les équipes d'assistance sur site. *Question 1 : Pourquoi mon iPhone affiche-t-il "Pas de connexion Internet" en orange sous le nom du réseau WiFi ?* **Réponse** : Cela signifie que l'iPhone a terminé l'association WiFi et a obtenu une adresse IP, mais que le test de détection automatique en arrière-plan (CNA) n'a pas reçu de réponse des serveurs de validation d'Apple et n'a pas été redirigé avec succès, souvent en raison du Relais privé iCloud ou d'un VPN actif. *Question 2 : Pouvons-nous simplement désactiver complètement le mini-navigateur CNA sur notre réseau ?* **Réponse** : Oui, la plupart des contrôleurs LAN sans fil d'entreprise disposent d'un paramètre appelé "CNA Bypass" ou "Contournement du Captive Portal". Lorsqu'il est activé, le contrôleur simule le test de validation d'Apple, indiquant à l'iPhone qu'il dispose d'un accès internet complet. Cela empêche l'ouverture automatique de la page d'accueil, mais l'utilisateur doit alors ouvrir manuellement Safari pour déclencher la redirection, ce qui peut parfois générer encore plus de confusion pour l'utilisateur. *Question 3 : Qu'est-ce que le problème du test post-authentification ?* **Réponse** : Une fois que le visiteur s'est connecté, la page d'accueil CNA effectue un second test pour vérifier l'accès internet. Si votre passerelle le redirige vers une page de destination mais continue de bloquer les domaines de validation d'Apple, le bouton en haut à droite reste bloqué sur "Annuler". Cliquer sur "Annuler" déconnecte l'utilisateur du WiFi. Vous devez vous assurer que les domaines de validation d'Apple sont entièrement accessibles après l'authentification. [Court intermède musical de transition] **Animateur** : Pour conclure, examinons l'impact concret sur l'activité des entreprises. Optimiser votre captive portal n'est pas seulement une question d'élégance technique ; c'est une question de rentabilité. Nous avons récemment collaboré avec un groupe de complexes hôteliers 5 étoiles de luxe qui subissait un taux d'échec de 35 % lors des connexions au WiFi des clients, ce qui générait plus de 450 plaintes à la réception chaque semaine. En restructurant leur walled garden, en bloquant les domaines Private Relay au niveau DNS pour forcer le routage local, et en déployant la solution **Guest WiFi de Purple**, ils ont vu les tickets WiFi à la réception chuter de **92 %** en seulement 30 jours. Leurs scores de satisfaction client ont grimpé en flèche, et ils ont collecté des milliers de profils de clients vérifiés. Si vous souhaitez vous assurer que votre réseau WiFi invité interagit parfaitement avec le Captive Network Assistant d'Apple tout en maximisant la collecte de données et en minimisant les coûts de support, rendez-vous sur **purple.ai**. Notre plateforme est conçue pour gérer toutes ces nuances spécifiques à iOS dès l'installation. Merci d'avoir écouté ce briefing technique Purple. Implémentez ces stratégies de walled garden et de DNS cette semaine, et regardez vos tickets de support disparaître. D'ici la prochaine fois, gardez vos connexions sécurisées et votre accueil client fluide. [Musique d'intro/outro : Synth-pop électronique rythmée qui s'estompe lentement]

Fait partie de notre série principale : Guide du Captive Portal →

Résumé opérationnel

L'échec de la connexion au Captive Portal sur les appareils iOS (iPhone et iPad) est l'une des principales causes de plaintes concernant la connexion WiFi invité dans les secteurs de l'hôtellerie, du commerce de détail, de la santé et des entreprises. Lorsqu'un appareil iOS s'associe à un réseau sans fil ouvert ou authentifié par le web, le démon Captive Network Assistant (CNA) d'Apple lance une série de requêtes HTTP en arrière-plan. Si ces requêtes sont bloquées, mal acheminées ou mal interceptées, la page d'accueil du Captive Portal ne se charge pas, ce qui prive l'utilisateur d'accès à Internet sans moyen évident de se connecter.

Ce guide technique détaille les mécanismes sous-jacents de la détection CNA d'Apple, analyse les principales fonctionnalités de confidentialité d'iOS - notamment iCloud Private Relay, les adresses WiFi privées (randomisation des adresses MAC) et le DNS chiffré - et fournit des stratégies d'atténuation étape par étape pour les ingénieurs réseau et les gestionnaires de sites.

Difficultés avec l'abandon du WiFi invité sur iOS ?

La plateforme WiFi invité gérée dans le cloud de Purple gère automatiquement les requêtes CNA d'Apple, iCloud Private Relay et la randomisation MAC - offrant une intégration fluide au Captive Portal sur tous les appareils iOS et Android.

Découvrir Purple Guest WiFi →

Analyse technique approfondie

Logique de détection et mécanisme de requêtes d'Apple

Lorsqu'un iPhone se connecte à un point d'accès sans fil, la pile réseau iOS distribue immédiatement un démon appelé captivenetworkd. Ce démon émet des requêtes HTTP GET simples vers des URL de vérification Apple prédéfinies, notamment :

  • http://captive.apple.com/hotspot-detect.html
  • http://www.apple.com/library/test/success.html
  • http://gsp1.apple.com/pep/gcc
+-------------------+       HTTP GET captive.apple.com       +----------------------+
|   iPhone (iOS)    | -------------------------------------> |  Network Controller  |
+-------------------+                                        +----------------------+
          |                                                             |
          | <--- HTTP 302 Redirect (https://portal.purple.ai) ---------+
          |
          v
[ Launch CNA Websheet ] ---> [ Render Purple Captive Portal ]

Le démon évalue le statut et le corps de la réponse HTTP :

  1. Réponse de réussite (HTTP 200 avec <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>") : l'appareil en conclut que le réseau fournit un accès internet illimité. Aucune page d'accueil ne s'affiche.
  2. Réponse de redirection (HTTP 302 / 307) : la passerelle réseau intercepte la requête HTTP du port 80 et redirige le client vers l'URL du Captive Portal. iOS reconnaît la redirection et lance la CNA Websheet (une fenêtre de navigation modale spécialisée).
  3. Dépassement de délai de connexion ou réinitialisation : si la passerelle rejette les paquets du port 80 ou ne répond pas aux requêtes DNS, la sonde expire. iOS affiche un avertissement "Pas de connexion Internet" sous le nom du SSID dans les Réglages, mais ne parvient pas à afficher la page de connexion.

Sondage post-authentification (le défi du bouton "Terminé")

Une fois qu'un utilisateur a soumis ses identifiants ou accepté les conditions d'utilisation sur la page d'accueil, le contrôleur LAN sans fil (WLC) met à jour l'état ACL du client sur "authentifié". Le démon CNA émet immédiatement une sonde HTTP de suivi vers captive.apple.com.

Si la seconde sonde renvoie HTTP 200 "Success", le bouton en haut à droite de la CNA Websheet passe de "Annuler" à "Terminé". Si le réseau ne parvient pas à autoriser l'accès HTTP hors bande immédiatement après l'authentification, le bouton reste bloqué sur "Annuler", et appuyer dessus peut déconnecter complètement l'appareil du réseau WiFi.

Facteurs d'interférence spécifiques à iOS

1. Relais privé iCloud

Introduit dans iOS 15, le Relais privé iCloud est un service Apple conçu pour protéger la confidentialité de la navigation web. Lorsqu'il est activé, Safari et le trafic HTTP non chiffré sont chiffrés et acheminés via deux relais Internet distincts :

[ iPhone ] === QUIC/TLS Chiffré ===> [ Proxy d'entrée Apple ] ---> [ Proxy de sortie ] ---> [ Cible Web ]
  • Le problème : le Relais privé chiffre les requêtes DNS via Oblivious DNS-over-HTTPS (ODoH) et tunnelise le trafic HTTP via QUIC (port UDP 443). Étant donné que les routeurs de la passerelle locale ne peuvent pas inspecter ou intercepter le trafic QUIC chiffré, ils ne peuvent pas injecter la redirection HTTP 302 standard.
  • Impact : la sonde HTTP initiale vers captive.apple.com est tunnelisée hors de la passerelle locale, ce qui entraîne des dépassements de délai de connexion et l'absence de pages d'accueil.

2. Adresses MAC privées et identifiants rotatifs

Depuis iOS 14 et avec une extension dans iOS 18, Apple active par défaut l'adresse WiFi privée. Plutôt que d'utiliser l'adresse MAC matérielle permanente de l'appareil, iOS génère une adresse MAC aléatoire pour chaque SSID.

  • Le problème : sur les réseaux utilisant l'autorisation de session basée sur l'adresse MAC (où les utilisateurs authentifiés bénéficient d'un accès de 24 heures basé sur l'adresse MAC), la rotation de l'adresse MAC amène la passerelle réseau à considérer les appareils qui reviennent comme de nouveaux clients non authentifiés.
  • Impact : la page d'accueil du Captive Portal s'affiche à plusieurs reprises pour les utilisateurs, ce qui entraîne une mauvaise expérience utilisateur et des tickets de support à la réception.

3. Profils DNS chiffrés (DoH / DoT)

Les utilisateurs disposant de profils de configuration iOS personnalisés (tels que NextDNS, Cloudflare 1.1.1.1 ou les paramètres DNS MDM d'entreprise) transmettent toutes les requêtes DNS via HTTPS chiffré (DoH) ou TLS (DoT) directement vers des résolveurs externes.

  • Le Problème : Le serveur DNS du réseau local ne peut pas intercepter ou falsifier les requêtes DNS pour captive.apple.com ou les domaines inexistants.
  • L'Impact : La résolution DNS initiale contourne entièrement le contrôleur local, empêchant le déclenchement de la redirection vers le portail.

Guide de mise en œuvre et d'atténuation

Conception du Walled Garden (ACL de pré-authentification)

Pour garantir un affichage fiable du Captive Portal sur iOS, les ingénieurs réseau doivent configurer avec précision la liste de contrôle d'accès (ACL) du Walled Garden de pré-authentification :

Type de règle Destination / Domaine Objectif
Autoriser *.purple.ai, *.purpleshield.com Permet aux clients non authentifiés d'accéder à l'infrastructure et aux ressources du portail Purple.
Intercepter HTTP (Port TCP 80) vers n'importe quelle destination Intercepte le trafic web HTTP en clair pour déclencher la redirection 302.
Bloquer / NXDOMAIN mask.icloud.com, mask-h2.icloud.com Renvoie NXDOMAIN pour signaler que Relais privé n'est pas disponible sur le réseau local.
NE PAS mettre sur liste blanche captive.apple.com, www.apple.com Ne doit PAS être mis sur liste blanche. La mise sur liste blanche permet aux requêtes de test de réussir sans lancer le portail.

Configuration étape par étape du WLC (Exemple Cisco Catalyst / Meraki)

  1. Configurer l'interception DNS : Configurez le serveur DHCP pour attribuer l'adresse IP de la passerelle comme serveur DNS principal pour les clients non authentifiés.
  2. Configurer la signalisation du Relais privé : Ajoutez une règle de réécriture DNS sur les serveurs DNS locaux :
    mask.icloud.com      IN A 0.0.0.0 (ou NXDOMAIN)
mask-h2.icloud.com   IN A 0.0.0.0 (ou NXDOMAIN)
    Lorsqu'iOS reçoit un NXDOMAIN pour ces noms d'hôtes, il affiche l'invite système : "Ce réseau bloque le relais privé iCloud. Souhaitez-vous utiliser ce réseau sans le relais privé ?" Appuyer sur Utiliser sans le relais privé rétablit la redirection standard vers le portail.
  3. Configurer le délai d'expiration de la session : Définissez le délai d'expiration de la session de la passerelle en fonction des paires IP/MAC ou supprimez les cookies d'autorisation persistants.

Vous avez des questions sur votre configuration spécifique ?

Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.

Bonnes pratiques et normes de l'industrie

La gestion de l'accueil des invités WiFi à grande échelle nécessite le respect des normes réseau modernes :

  • Transition vers WPA3-Personal (OWE) : Les portails d'invités existants fonctionnent sur des SSID ouverts et non chiffrés. Les sites d'entreprise devraient adopter le chiffrement sans fil opportuniste Opportunistic Wireless Encryption (OWE) (IEEE 802.11aq) pour offrir un chiffrement individualisé sans mot de passe.
  • Conformité PCI DSS et GDPR : Les portails d'invités doivent isoler le trafic des invités des réseaux de paiement PCI DSS. Lors de la collecte des coordonnées, les portails doivent présenter des cases à cocher de consentement GDPR explicites et non groupées - gérées facilement via une plateforme de WiFi Analytics.
  • Déployer Passpoint (Hotspot 2.0) : Pour éliminer complètement les frictions liées au Captive Portal, les sites peuvent déployer Passpoint (Hotspot 2.0). Passpoint utilise une authentification de type cellulaire pour connecter les appareils iOS de manière sécurisée et automatique via un profil préinstallé, contournant ainsi complètement le démon CNA.

Dépannage et atténuation des risques

Parcours d'auto-résolution de l'utilisateur final

  1. Désactiver le Relais privé iCloud pour le réseau : Ouvrez Réglages > WiFi, appuyez sur l'icône (i) à côté du nom du réseau, puis désactivez Limiter le suivi de l'adresse IP.
  2. Désactiver l'adresse WiFi privée : Dans le même menu de paramètres réseau, désactivez Adresse WiFi privée si un accès basé sur l'adresse MAC est requis.
  3. Forcer la redirection du portail via Safari : Ouvrez Safari et saisissez l'adresse HTTP simple : http://neverssl.com Comme neverssl.com n'utilise pas le protocole HTTPS, le routeur local interceptera de manière fiable la requête et chargera le portail.

Parcours de diagnostic de l'ingénieur réseau

                  [ Connexion de l'iPhone au SSID invité ]
                                  |
                                  v
                        [ IP DHCP attribuée ? ]
                        /                   \
                     (Non)                 (Oui)
                      /                       \
      [ Vérifier le pool DHCP ]         [ Résout captive.apple.com ? ]
                                        /                             \
                                     (Non)                           (Oui)
                                      /                                 \
                         [ Vérifier ACL DNS ]               [ Apple est-il sur liste blanche ? ]
                                                             /                       \
                                                          (Oui)                      (Non)
                                                           /                           \
                                             [ RETIRER du Walled Garden ]    [ Redirection Port 80 ? ]
                                                                               /                   \
                                                                            (Non)                  (Oui)
                                                                             /                       \
                                                              [ Corriger redir. WLC ] [ Chargement CNA Websheet ]

ROI et impact commercial

L'optimisation de l'expérience d'intégration WiFi pour les invités utilisant iOS a un impact direct et mesurable sur les opérations des sites et sur les indicateurs commerciaux.

Étude de cas secteur hôtelier : Groupe de complexes hôteliers cinq étoiles

  • Défi : Un groupe d'hôtels de luxe comptant 12 établissements enregistrait un taux d'échec de connexion WiFi des invités de 35 %, ce qui générait plus de 450 plaintes à la réception par semaine.
  • Mise en œuvre : L'équipe informatique a restructuré son walled garden, désactivé le suivi des sessions basé sur le MAC et déployé la solution de Guest WiFi de Purple avec une gestion optimisée du CNA.
  • Résultats : Les plaintes relatives au WiFi à la réception ont chuté de 92 % en l'espace de 30 jours. Les scores de satisfaction client (CSAT) ont augmenté de 18 points et le site a enregistré 40 000 adresses e-mail nouvellement vérifiées au cours du premier trimestre.

Étude de cas Retail : Opérateur national de centres commerciaux

  • Défi : Un opérateur de vente au détail possédant 45 centres commerciaux avait du mal à stimuler l'engagement des visiteurs, car iCloud Private Relay empêchait le chargement du Captive Portal sur 40 % des appareils iOS.
  • Mise en œuvre : Blocage de Private Relay au niveau du réseau (renvoi de NXDOMAIN pour les domaines relais d'Apple afin de forcer le routage local) et déploiement de WiFi Analytics.
  • Résultats : Les taux de complétion du portail sont passés de 58 % à 94 %. L'équipe marketing a monétisé l'inventaire du portail récupéré grâce à des campagnes média de vente au détail localisées, générant 120 000 $ de revenus publicitaires supplémentaires par trimestre.

Ressources associées

Pour les équipes réseau qui déploient du sans-fil invité d'entreprise, ces ressources fournissent un contexte technique plus approfondi :

La plateforme de Guest WiFi de Purple est au service des secteurs de l'hôtellerie, du retail, de la santé et des transports à l'échelle mondiale, offrant des expériences de connexion invité optimisées pour le CNA à grande échelle.

Définitions clés

Apple Captive Network Assistant (CNA)

Un démon du système d'exploitation iOS et macOS qui teste la connectivité internet et lance automatiquement une fenêtre modale WebKit restreinte (WebSheet) lorsqu'un Captive Portal est détecté.

Détermine si la page d'accueil de connexion s'affiche automatiquement sur les iPhones lors de la connexion à un réseau WiFi invité.

URL de la sonde Canary

Un point de terminaison HTTP léger (comme http://captive.apple.com/hotspot-detect.html) interrogé par les systèmes d'exploitation clients pour vérifier l'accessibilité d'un internet non restreint.

Si la réponse à la sonde est modifiée ou redirigée, le système d'exploitation déclenche son gestionnaire de Captive Portal.

API Captive Portal RFC 8908

Un protocole standard IETF qui fournit un point de terminaison API permettant aux appareils d'interroger l'état de captivité du réseau, les conditions d'utilisation du lieu de connexion et le temps de session restant via JSON.

Remplace le piratage HTTP traditionnel par une détection structurée et cryptographiquement sécurisée des réseaux captifs.

Option DHCP 114 (Captive-Portal)

Une option DHCP (RFC 8910) qui transmet l'URI de l'API Captive Portal RFC 8908 à l'appareil client lors de l'attribution initiale de l'adresse de niveau 3 (Layer 3).

Signale immédiatement l'état captif à iOS 14+ lors de l'attribution de l'IP, en contournant les modifications DNS.

iCloud Private Relay

Un service de confidentialité Apple qui achemine le trafic Safari et le DNS non chiffré via une architecture de proxy chiffré à double saut.

Peut masquer les requêtes DNS pré-authentification à moins que le réseau local n'émette un signal explicite d'altération du réseau (NXDOMAIN).

Adresse WiFi privée (randomisation MAC)

Une fonctionnalité de confidentialité dans iOS 14+ qui génère une adresse MAC aléatoire unique par SSID pour empêcher le suivi physique d'un site à l'autre.

Peut désynchroniser les sessions de comptabilité RADIUS si les adresses MAC tournent en milieu de session ou lors de la ré-authentification.

Exemples concrets

Un hôtel de luxe déployant des WLC Cisco Catalyst 9800 constate que les utilisateurs de smartphones iPhone ne reçoivent jamais la page de démarrage du Captive Portal lors de la connexion au SSID WiFi invité ouvert. Les ordinateurs portables Android et Windows chargent le portail immédiatement. Comment l'équipe réseau doit-elle diagnostiquer et résoudre ce problème de détection Apple CNA ?

  1. Inspecter l'ACL de redirection de pré-authentification : Vérifiez que l'ACL de redirection du Cisco 9800 refuse (contourne) le DNS UDP 53 et autorise le trafic HTTP TCP 80 pour déclencher la redirection. 2. Vérifier la liste blanche des sondes Apple : Assurez-vous que captive.apple.com n'est PAS inscrit sur la liste blanche du walled garden avant la redirection ; l'inscription sur liste blanche fait croire à iOS que l'accès internet est ouvert et supprime le portail. 3. Vérifier HTTP 302 vs 307 : Configurez la carte des paramètres webauth du WLC pour renvoyer une redirection HTTP 302 Found avec le FQDN du portail. 4. Désactiver l'interception HTTPS : Assurez-vous que le trafic HTTPS sur le port 443 est rejeté ou abandonné plutôt que détourné avec un certificat non approuvé. 5. Déployer l'option DHCP 114 : Ajoutez l'option 114 ascii https://app.purplewifi.net/api/v1/capport au pool DHCP invité pour une détection native par iOS 14 à 18.
Commentaire de l'examinateur : Les appareils Apple s'appuient sur une correspondance stricte pour le jeton Success de captive.apple.com. Si le domaine de la sonde est prématurément autorisé à travers le walled garden, iOS suppose à tort que l'accès internet est ouvert et ne déclenchera jamais le WebSheet.

L'administrateur réseau d'un stade observe que les utilisateurs d'iOS 17 et iOS 18 font face à une boucle de redirection infinie : la page CNA s'affiche, l'utilisateur accepte les conditions et clique sur Se connecter, la fenêtre modale se ferme, mais 30 secondes plus tard, elle s'ouvre à nouveau pour demander une nouvelle connexion. Quelle est la cause racine et comment y remédier ?

  1. Suivi de session RADIUS : Sur iOS 17/18, l'option Private Wi-Fi Addresses utilise des adresses MAC tournantes si configurée, ou l'appareil peut renégocier le DHCP lors de la fermeture de la fenêtre modale. 2. Configuration RADIUS CoA : Vérifiez que le contrôleur traite les requêtes RFC 3576 RADIUS Change of Authorization (CoA) Disconnect sur le port UDP 3799 afin que l'ACL de pré-authentification soit supprimée immédiatement après l'authentification. 3. Délai d'expiration de session et période de grâce : Augmentez le délai d'expiration du cache MAB (MAC authentication bypass) à 1440 minutes (24 heures) avec une période de grâce de bail DHCP de 15 minutes. 4. Ressources OAuth du walled garden : Vérifiez que tous les points de terminaison OAuth (Google, Apple, Microsoft) ainsi que les polices/feuilles de style sont intégrés au walled garden afin que la session se charge complètement avant la fermeture du WebSheet.
Commentaire de l'examinateur : Les boucles de redirection infinies proviennent généralement de retards de traitement RADIUS CoA où le contrôleur n'a pas encore mis à jour l'état du client de pré-authentification à post-authentification au moment où iOS envoie sa sonde de vérification après connexion.

Questions d'entraînement

Q1. Pourquoi la tentative de redirection du trafic HTTPS (port 443) provoque-t-elle des erreurs de Captive Portal sur les appareils iOS plutôt que d'ouvrir la page de connexion ?

Conseil : Considérez comment le chiffrement TLS, la vérification des certificats et HSTS protègent le trafic web.

Voir la réponse type

HTTPS établit un tunnel TLS chiffré de bout en bout entre le navigateur client et le serveur web de destination. Lorsqu'une passerelle sans fil tente d'intercepter le port 443 et de fournir une redirection, le certificat SSL/TLS fourni par la passerelle ne correspond pas au nom d'hôte demandé (par exemple google.com ou apple.com). iOS applique la sécurité HTTP Strict Transport Security (HSTS), ce qui oblige Safari et WebKit à abandonner la connexion avec un avertissement de sécurité grave au lieu de suivre la redirection.

Q2. Comment un réseau WiFi invité d'entreprise doit-il gérer iCloud Private Relay pour assurer une redirection fluide vers le Captive Portal sur les appareils iOS ?

Conseil : Consultez les directives réseau officielles d'Apple concernant les réponses DNS de mask.icloud.com.

Voir la réponse type

Les administrateurs réseau doivent configurer leurs serveurs DNS récursifs locaux pour renvoyer une réponse NXDOMAIN (ou un échec de résolution DNS) pour les noms de domaine mask.icloud.com et mask-h2.icloud.com. Lorsqu'iOS reçoit une réponse NXDOMAIN pour ces domaines canaris, il affiche une alerte système informant l'utilisateur que le réseau ne prend pas en charge Private Relay et bascule proprement vers la gestion standard des sondes DNS et HTTP.

Q3. Quel est l'avantage de déployer l'API Captive Portal RFC 8908 par rapport aux techniques traditionnelles de détournement DNS et HTTP ?

Conseil : Pensez à la clarté du protocole, à la signalisation de Couche 3 et à l'expérience utilisateur.

Voir la réponse type

La RFC 8908 fournit une API REST JSON standardisée communiquée via l'Option DHCP 114 ou les annonces de routeur IPv6. Au lieu d'intercepter le trafic web de l'utilisateur, l'OS client interroge directement l'API en HTTPS pour savoir si le réseau requiert un Captive Portal, obtenir l'URL de connexion, inspecter le quota restant et recevoir une notification personnalisée aux couleurs de l'établissement. Cela élimine les avertissements de certificat SSL, prend en charge les gestionnaires de mots de passe et préserve l'intégrité de la sécurité du navigateur.

Questions fréquentes

Why is my captive portal not popping up on iPhone?

Captive portals fail to pop up on iPhones when the Apple Captive Network Assistant (CNA) cannot complete its probe to http://captive.apple.com/hotspot-detect.html. Common causes include: 1) Pre-authentication firewalls blocking UDP port 53 DNS; 2) The network prematurely whitelisting captive.apple.com in the walled garden; 3) Gateways attempting HTTPS interception instead of HTTP 302 redirection; or 4) iCloud Private Relay interfering with DNS resolution.

How do I force the WiFi login screen to appear on iOS?

To manually trigger the captive portal on iPhone: 1) Open Safari and navigate to a plaintext HTTP URL such as http://captive.apple.com, http://neverssl.com, or http://1.1.1.1; 2) Go to Settings > Wi-Fi, tap the info (i) icon next to the network, and ensure Auto-Join and Auto-Login are toggled ON; 3) Turn Wi-Fi off and back on to trigger the CNA probe daemon.

What domains must be in the walled garden for Apple devices?

To support Apple iOS and macOS captive portal detection and assets, whitelist: captive.apple.com, www.airport.us, appleiphonecell.com, *.apple.com, *.purple.ai, *.purplewifi.net, and any third-party OAuth provider domains (e.g. accounts.google.com) or CDN assets used on the splash page.

How does RFC 8908 solve iOS captive portal issues?

RFC 8908 (Captive Portal API) and RFC 8910 (DHCP Option 114) pass the captive portal URL directly to iOS during the DHCP IP lease negotiation. This allows iOS 14+ to recognize network captivity instantly at Layer 3 without relying on fragile HTTP redirection or DNS hijacking.

How does MAC address randomisation affect captive portal authentication?

iOS Private Wi-Fi Addresses use unique MAC addresses per SSID. If the device rotates its MAC address or if session caching is tied strictly to physical MAC addresses without RADIUS accounting grace periods, the user may be forced to re-authenticate repeatedly. Configuring a 24-hour lease grace period and deploying Passpoint (Hotspot 2.0) resolves this issue.

Sources

  1. Apple Developer Documentation - Captive Network Architecture and CNA
  2. Apple Support - Prepare Your Network for iCloud Private Relay
  3. IETF RFC 8908 - Captive Portal API Specification
  4. IETF RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements
  5. Wireless Broadband Alliance (WBA) - Captive Portal Standards and Best Practices
  6. Purple - Captive Portal Architecture & Troubleshooting Guide
  7. Purple - MAC Address Randomisation Impact Guide

Continuer la lecture de cette série

Le portail captif Ubiquiti UniFi ne redirige pas : causes et correctifs

Ce guide isole un échec de redirection du portail captif UniFi en suivant dans l'ordre l'état de l'invité, la redirection, la route de pré-autorisation et l'autorisation du contrôleur. Il offre aux équipes informatiques des sites une méthode éprouvée pour résoudre la confusion entre réseau invité et Hotspot, les transferts vers un portail externe, les exigences actuelles de compte UniFi OS et les tests d'isolation DNS.

Lire le guide →

La page splash Cisco Meraki ne fonctionne pas : un organigramme de dépannage

Ce guide pratique de niveau 2 permet d'isoler l'endroit où un flux de splash Cisco Meraki a échoué : autorisation du client, initiation de la redirection HTTP, accessibilité du walled garden ou authentification RADIUS. Il offre aux équipes informatiques des sites un parcours de vérification contrôlé pour restaurer le WiFi invité sans modifier l'ensemble du parc de production.

Lire le guide →

Guide de configuration d'un réseau Guest WiFi d'entreprise : segmentation VLAN, sécurité et portails captifs

Ce guide technique explique aux équipes informatiques comment configurer un réseau Guest WiFi en tant que service d'accès internet contrôlé, en utilisant la segmentation VLAN, les politiques de pare-feu et un portail captif. Il montre également comment les formulaires d'inscription et les contrôles d'accès de Purple permettent de proposer une expérience visiteur fluide sans affaiblir la sécurité autour des systèmes du personnel, de paiement et opérationnels.

Lire le guide →

Vous avez des questions sur votre configuration spécifique ?

Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.