Comment améliorer la vitesse du WiFi sans acheter de nouveaux points d'accès

Comment améliorer la vitesse du WiFi sans acheter de nouveaux points d'accès Une fiche technique Purple — Environ 10 minutes --- INTRODUCTION ET CONTEXTE (environ 1 minute) --- Bienvenue dans la série des fiches techniques Purple. Je suis votre hôte, et aujourd'hui nous nous attaquons à l'une des conversations les plus courantes que j'ai avec les directeurs informatiques et les CTO de grands espaces : le problème de capacité du WiFi. Vous gérez un hôtel, un parc de points de vente, un centre de conférences ou un stade. Vos clients et votre personnel se plaignent de la lenteur du WiFi. Votre premier réflexe — et, pour être honnête, le réflexe sur lequel compte votre fournisseur d'infrastructure — est d'acheter plus de points d'accès. Nouveau matériel, déploiement plus important, facture plus élevée. Mais voilà. Dans la majorité des cas que j'ai étudiés, le problème ne vient pas du tout des points d'accès. Le problème vient de ce qui y transite. Et cela relève d'un problème logiciel, ce qui signifie qu'il existe une solution logicielle. Aujourd'hui, je vais vous expliquer exactement comment le filtrage DNS et l'optimisation de la couche logicielle peuvent vous permettre de récupérer 30 % ou plus de votre bande passante existante — sans toucher à un seul équipement matériel. Nous aborderons l'architecture technique, les scénarios de déploiement en conditions réelles et les arguments commerciaux que vous pourrez présenter à votre directeur financier. C'est parti. --- ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes) --- Tout d'abord, posons le problème de base. Lorsque l'on examine ce qui consomme réellement de la bande passante sur un réseau WiFi invité d'entreprise classique, la répartition est véritablement surprenante pour la plupart des gens. Les réseaux publicitaires et les traceurs tiers — la télémétrie d'arrière-plan que chaque application sur chaque appareil envoie constamment — représentent entre 25 et 40 % du volume des requêtes DNS sur un réseau invité type. Il ne s'agit pas de requêtes que vos invités effectuent consciemment. Elles sont automatiques. Chaque fois que quelqu'un ouvre une application d'actualités, une plateforme de réseau social ou une application de vente sur son téléphone, cette application lance des dizaines de requêtes DNS vers des serveurs publicitaires, des plateformes d'analyse et des pixels de suivi. Aucun de ces trafics n'apporte de valeur à vos invités. Tous consomment votre capacité de liaison montante. De plus, vous devez faire face au trafic de logiciels malveillants et de botnets. Les appareils compromis — et sur un grand réseau invité, vous en aurez forcément — tentent constamment de se connecter à des serveurs de commande et de contrôle. Ce trafic ne se contente pas de gaspiller de la bande passante, il constitue également un risque en matière de conformité et de sécurité. Ainsi, avant même qu'un seul octet de trafic légitime — un appel vidéo, une page web, une transaction de paiement — n'atteigne votre liaison montante, vous avez déjà consommé entre un tiers et la moitié de votre capacité disponible en bruit de fond. Le filtrage DNS intervient au niveau de la couche de résolution. Chaque requête Internet commence par une requête DNS — une recherche qui traduit un nom de domaine en adresse IP. Le filtrage DNS intercepte cette requête avant même qu'elle n'atteigne votre liaison montante. Si le domaine correspond à un réseau publicitaire, à un hôte de logiciels malveillants connu ou à une catégorie restreinte par votre politique, la requête est bloquée au niveau de la couche DNS. L'appareil reçoit une réponse nulle. Aucune donnée n'est transférée. Aucune bande passante n'est consommée. C'est fondamentalement différent d'un pare-feu ou d'un proxy. Un pare-feu inspecte les paquets après leur arrivée. Un proxy intercepte le trafic en cours de route. Le filtrage DNS arrête la requête avant qu'elle ne commence — c'est pourquoi la récupération de bande passante est si importante. Vous ne nettoyez pas le trafic déjà arrivé ; vous l'empêchez d'être demandé en premier lieu. D'un point de vue architectural, le déploiement est simple. Vous configurez votre serveur DHCP pour orienter les appareils clients vers votre résolveur de filtrage DNS plutôt que vers le DNS par défaut de votre FAI. Il s'agit généralement d'une modification de deux lignes dans votre configuration DHCP. Les règles de filtrage sont gérées de manière centralisée — soit dans le cloud, soit sur site selon vos exigences de conformité — et appliquées uniformément sur tous les appareils connectés, quel que soit le point d'accès auquel ils sont associés. C'est un point critique pour les opérateurs multi-sites. Une chaîne de vente au détail de deux cents magasins, ou un groupe hôtelier de cinquante établissements, peut déployer une politique de filtrage DNS cohérente sur l'ensemble du parc à partir d'une console de gestion unique. Pas de visites d'ingénieurs sur site. Pas de configuration par site. Les modifications de politique se propagent en quelques minutes. Il y a ici une considération technique importante que je souhaite signaler aux architectes présents. L'émergence du DNS over HTTPS — DoH — pose un défi au filtrage DNS traditionnel. Lorsqu'un appareil utilise le DoH, il chiffre ses requêtes DNS et les envoie directement à un résolveur spécifique — généralement géré par un éditeur de navigateur — contournant ainsi complètement votre DNS au niveau du réseau. Cela signifie que vos règles de filtrage sont contournées. La solution consiste à imposer l'interception du DoH au niveau du réseau. Cela implique d'identifier le trafic DoH — qui s'exécute sur le port 443 vers des plages d'adresses IP de résolveurs connus — et soit de le bloquer, soit de le rediriger vers votre propre résolveur de filtrage compatible DoH. Il s'agit d'une configuration plus avancée, mais elle est essentielle pour maintenir l'efficacité du filtrage sur les réseaux modernes où Chrome, Firefox et iOS adoptent de plus en plus le DNS chiffré par défaut. Purple a publié un guide détaillé sur les implications du DNS over HTTPS pour le filtrage du WiFi public, que je vous recommande de lire en parallèle de ce briefing. Au-delà du filtrage DNS, il existe plusieurs optimisations complémentaires au niveau de la couche logicielle qui valent la peine d'être implémentées en parallèle. Le band steering est l'un des leviers les plus efficaces. La plupart des points d'accès modernes prennent en charge les bandes 2,4 GHz et 5 GHz. La bande 5 GHz offre un débit nettement supérieur mais une portée plus courte. Sans band steering actif, les appareils s'associent souvent par défaut à la bande 2,4 GHz — en particulier les appareils plus anciens et le matériel IoT — ce qui crée une congestion sur une bande déjà encombrée par le trafic hérité. L'activation du band steering dans votre contrôleur sans fil pousse les appareils compatibles vers la bande 5 GHz, libérant ainsi la bande 2,4 GHz pour les appareils qui en ont réellement besoin. La consolidation des SSID est une autre victoire rapide. Chaque SSID que vous diffusez consomme du temps d'antenne via les trames de balise (beacon frames) — un trafic de gestion que chaque appareil à portée doit traiter. Un site exploitant huit ou dix SSID pour différents services, prestataires et niveaux d'invités consomme un pourcentage mesurable de temps d'antenne en frais de gestion. Consolider à trois ou quatre SSID — invités, personnel, IoT et gestion — et utiliser le marquage VLAN pour la segmentation plutôt que des SSID distincts permet de récupérer immédiatement ce temps d'antenne. L'application des politiques de QoS — Qualité de Service — est le troisième levier. Sans QoS, un seul invité diffusant une vidéo 4K peut saturer une cellule radio, dégradant ainsi l'expérience de tous les autres appareils connectés à ce point d'accès. La mise en œuvre d'une limitation de débit par client et d'une hiérarchisation du trafic — en élevant le trafic VoIP et les transactions POS au-dessus du streaming de masse — garantit la protection du trafic critique pour l'entreprise, même en période de pointe. Enfin, la planification des canaux et l'optimisation de la puissance de transmission. Ces paramètres sont souvent configurés une fois pour toutes lors du déploiement initial et ne sont plus jamais revus. À mesure que l'environnement RF évolue — nouveaux bâtiments, nouvelles sources d'interférences, modifications de la densité des appareils — vos attributions de canaux peuvent créer des interférences co-canal qui dégradent considérablement le débit. Réaliser une étude RF passive et réoptimiser l'attribution des canaux est une intervention sans coût qui peut générer des améliorations substantielles de débit. --- RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER (environ 2 minutes) --- Laissez-moi vous présenter une séquence de déploiement pratique pour un site de taille moyenne — par exemple, un hôtel de deux cents chambres ou un centre de distribution logistique régional. Commencez par une mesure de référence. Avant de modifier quoi que ce soit, configurez votre réseau pour capturer le volume de requêtes DNS par catégorie, la consommation de bande passante par client et l'utilisation de la liaison montante par heure de la journée. Cela vous donne l'état initial pour le calcul de votre ROI. La plupart des plateformes d'analyse WiFi d'entreprise affichent ces données de manière native — la plateforme d'analyse de Purple, par exemple, offre une visibilité au niveau de l'appareil qui facilite grandement cet exercice de référence. Étape deux : déployez le filtrage DNS en mode surveillance. La plupart des solutions de filtrage DNS d'entreprise prennent en charge un mode passif où les requêtes sont enregistrées et catégorisées mais non bloquées. Exécutez ce mode pendant quarante-huit à soixante-douze heures pour comprendre la composition de votre trafic avant d'appliquer une quelconque politique. Cela évite que des faux positifs ne perturbent le trafic légitime dès le premier jour. Étape trois : activez le blocage par phases. Commencez par les catégories de confiance la plus élevée — domaines de logiciels malveillants connus, serveurs de commande et de contrôle de botnets et réseaux publicitaires. Ce sont des blocages à faible risque avec un fort impact sur la bande passante. Examinez les journaux quotidiennement pendant la première semaine pour détecter tout blocage inattendu. Étape quatre : superposez la QoS et le band steering. Une fois le filtrage DNS stable, mettez en œuvre la limitation du débit par client et le band steering. Testez ces modifications en dehors des heures de pointe et validez que les terminaux de point de vente, les combinés VoIP et les autres appareils essentiels à l'activité fonctionnent correctement. Étape cinq : documentez et mesurez. Après trente jours, extrayez vos indicateurs d'utilisation de la bande passante et comparez-les à votre référence. Dans la plupart des déploiements, vous constaterez une réduction de vingt à quarante pour cent de l'utilisation de la liaison montante. C'est votre chiffre de ROI. Maintenant, les pièges. Le plus courant que je constate est le sur-blocage. Si vous activez des catégories de filtrage de contenu agressives sans examiner d'abord les journaux, vous bloquerez des services légitimes. Le stockage cloud, les applications SaaS d'entreprise et même certains domaines de traitement des paiements peuvent apparaître dans des blocs de catégories larges. Commencez toujours de manière conservatrice et élargissez ensuite. Le deuxième piège est d'ignorer le contournement DoH. Si vous déployez le filtrage DNS sans traiter le DoH, vous verrez l'efficacité de votre filtrage diminuer avec le temps à mesure que de plus en plus d'appareils utilisent par défaut un DNS chiffré. Traitez ce problème au niveau de la politique réseau dès le premier jour. Le troisième piège est de ne pas segmenter le trafic IoT. Les appareils IoT — téléviseurs intelligents, systèmes de gestion technique du bâtiment, signalisation numérique — génèrent souvent un trafic DNS important vers les serveurs de télémétrie des fabricants. Si vous ne segmentez pas l'IoT sur un VLAN distinct avec sa propre politique de filtrage, vous risquez de bloquer par inadvertance les fonctionnalités des appareils lorsque vous renforcerez vos règles de filtrage. --- QUESTIONS-RÉPONSES RAPIDES (environ 1 minute) --- Laissez-moi passer en revue les questions que je reçois le plus souvent. "Le filtrage DNS affectera-t-il l'expérience des invités ?" En pratique, les invités ne s'en rendent jamais compte. Les domaines bloqués sont de la télémétrie en arrière-plan, pas du contenu qu'ils demandent activement. Au contraire, leur expérience s'améliore car il y a plus de bande passante disponible pour ce qu'ils essaient réellement de faire. "Cela nécessite-t-il des modifications de nos points d'accès ?" Non. Le filtrage DNS est configuré au niveau de la couche DHCP et du résolveur DNS. Vos points d'accès restent inchangés. « Est-ce conforme au GDPR ? » Le filtrage DNS enregistre les requêtes de domaine, pas le contenu. Vous n'effectuez pas d'inspection approfondie des paquets. À condition d'avoir des politiques de conservation des données appropriées et que votre avis de confidentialité couvre la surveillance du réseau — ce qui devrait être le cas de toute façon —, le filtrage DNS est entièrement compatible avec le GDPR. Pour les déploiements dans le secteur public et de la santé, il s'agit souvent d'une exigence de conformité plutôt que d'un choix. « Qu'en est-il de PCI DSS ? » Le filtrage DNS renforce en réalité votre posture PCI DSS en empêchant les environnements de données des titulaires de cartes de communiquer avec des domaines malveillants connus. C'est un contrôle positif, pas un risque. --- RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) --- Pour résumer : la majorité des problèmes de performance du WiFi d'entreprise ne sont pas des problèmes matériels. Ce sont des problèmes logiciels — plus précisément, l'absence de gestion intelligente du trafic au niveau de la couche DNS. En déployant le filtrage DNS, vous pouvez récupérer trente pour cent ou plus de votre bande passante existante, prolonger la durée de vie opérationnelle de votre infrastructure de points d'accès actuelle de deux à quatre ans, et améliorer simultanément votre posture de sécurité et de conformité. Le calendrier de déploiement se mesure en heures, pas en mois. Les dépenses d'investissement ne représentent qu'une fraction du coût d'un renouvellement de matériel. Les prochaines étapes pratiques sont simples. Réalisez un audit du trafic DNS sur votre réseau cette semaine — la plupart des plateformes d'entreprise vous fourniront ces données sans aucun outil supplémentaire. Identifiez vos principales catégories de domaines consommatrices de bande passante. Évaluez ensuite une solution de filtrage DNS par rapport à ces catégories. Si vous gérez un réseau WiFi invité à grande échelle — hôtellerie, commerce de détail, événements, secteur public —, la plateforme de Purple intègre le filtrage DNS à la gestion et à l'analyse du WiFi invité au sein d'un seul déploiement. Cela signifie que vous bénéficiez de la récupération de bande passante, des contrôles de conformité et des informations sur les données des invités à partir d'une seule plateforme plutôt que de trois. Merci d'avoir écouté ce briefing technique de Purple. Un guide de mise en œuvre complet, des schémas d'architecture et des exemples concrets sont disponibles dans le guide écrit d'accompagnement. À la prochaine.