Gérer la pénurie d'adresses IP publiques dans les résidences étudiantes
Ce guide fournit une référence technique définitive pour les architectes réseau déployant le CGNAT (Carrier-Grade NAT) et le PAT (Port Address Translation) afin de gérer la pénurie d'IPv4 dans les environnements denses de résidences étudiantes et de WiFi multi-locataires. Il couvre l'architecture NAT444, l'espace d'adressage partagé RFC 6598, le dimensionnement de l'allocation de blocs de ports (PBA), les stratégies de journalisation conformes au GDPR et une trajectoire de migration double pile IPv6. Ce guide est indispensable pour tout opérateur gérant des centaines ou des milliers d'appareils simultanés sur un pool d'adresses IP publiques limité, offrant des conseils de configuration pratiques, des études de cas réels et des analyses de ROI.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide du WiFi multi-locataires →
Synthèse
Alors que l'épuisement des adresses IPv4 s'accélère, les responsables informatiques et les architectes réseau au sein des environnements multi-locataires denses - tels que les résidences étudiantes, l'hôtellerie et les grands espaces publics - sont confrontés à d'importants défis opérationnels. Un seul bâtiment de résidence étudiante de 1 000 résidents peut générer plus de 7 000 appareils connectés en IP simultanément. Les architectures de traduction d'adresses de port (PAT) standards échouent à cette échelle, ce qui entraîne l'épuisement des ports, des pertes de connexion et une expérience utilisateur dégradée.
Ce guide de référence technique présente l'architecture et le déploiement du CGNAT (Carrier-Grade NAT) basé sur le modèle NAT444 pour gérer l'épuisement des adresses IP. En exploitant l'espace d'adressage partagé de la RFC 6598 et en mettant en œuvre une allocation stratégique de blocs de ports (PBA), les opérateurs réseau peuvent atteindre une densité d'abonnés élevée - jusqu'à 128 utilisateurs par IP publique - tout en maintenant la conformité avec le GDPR et les réglementations en matière d'interception légale. Pour les sites utilisant des plateformes telles que le Guest WiFi et le WiFi Analytics, une architecture CGNAT robuste garantit une connectivité stable et une collecte de données précise sans les dépenses d'investissement (CapEx) liées à l'achat de blocs IPv4 supplémentaires.
Analyse technique approfondie
Le problème de dimensionnement dans les résidences étudiantes
La densité d'appareils dans les résidences étudiantes modernes ne ressemble à presque aucun autre environnement de réseau géré. Un seul résident connecte généralement un smartphone, un ordinateur portable, une smart TV, une console de jeux et au moins un appareil domestique connecté. À raison de cinq à sept appareils par résident, un campus de 1 000 lits présente une charge de sessions simultanées qui éclipse même un hôtel de taille comparable. Le défi est aggravé par les habitudes d'utilisation : les heures de pointe en soirée (18:00 - 23:00) voient une activité quasi simultanée et à large bande passante sur les jeux, le streaming vidéo et les réseaux sociaux, tout en maintenant des connexions en arrière-plan persistantes.
L'espace d'adressage IPv4 est pratiquement épuisé au niveau des registres Internet régionaux (RIR). Le RIPE NCC, qui gère les allocations en Europe et au Moyen-Orient, a atteint sa politique d'allocation finale /8 en 2019. Le coût d'acquisition de blocs IPv4 publics supplémentaires sur le marché libre se situe désormais entre 40 $ et 60 $ par adresse - un CapEx prohibitif pour tout opérateur gérant des centaines de sous-réseaux.
Limites du PAT standard
Dans les déploiements de sites uniques traditionnels, la traduction d'adresse de port (PAT) mappe l'ensemble d'un réseau local privé (espace RFC 1918 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) à une seule adresse IP publique. Une seule adresse IPv4 dispose de 65 535 ports disponibles pour TCP et UDP. Bien que cela soit suffisant pour un petit bureau, dans les résidences étudiantes denses, la prolifération des applications en arrière-plan - synchronisation cloud, plateformes de messagerie, services de streaming - signifie qu'un seul utilisateur peut facilement consommer des centaines de ports simultanés. Lorsque le routeur de bordure PAT épuise ses ports disponibles, les nouvelles demandes de session sont rejetées en silence. Cela se traduit par des expirations de délai d'application (timeouts), des échecs d'appels VoIP et une augmentation des tickets d'assistance.
Architecture CGNAT (NAT444)
Pour dépasser les limites du NAT à un seul niveau, les réseaux d'entreprise doivent adopter une architecture Carrier-Grade NAT, plus précisément le modèle NAT444. Ce nom fait référence aux trois couches d'espace d'adressage IPv4 impliquées dans la chaîne de traduction.
Niveau 1 - Couche CPE / Point d'accès : Les appareils des abonnés reçoivent des adresses IP privées de l'espace RFC 1918 (par exemple, 192.168.x.x). Le point d'accès ou l'équipement d'abonné (CPE) effectue la première traduction NAT.
Niveau 2 - Passerelle CGNAT : Le CPE traduit l'adresse privée RFC 1918 en espace d'adressage partagé RFC 6598 (100.64.0.0/10). Cet espace intermédiaire est spécifiquement réservé pour une utilisation entre l'infrastructure du fournisseur de services et la passerelle CGNAT. L'utilisation de RFC 6598 au lieu d'une autre plage RFC 1918 évite le chevauchement d'adresses et les conflits de routage dans les environnements multi-locataires complexes.
Niveau 3 - Internet public : La passerelle CGNAT effectue la traduction finale de l'adresse RFC 6598 vers une adresse IPv4 publique partagée. C'est l'adresse qui est visible par les services externes.
Allocation de blocs de ports : Décisions de conception critiques
Le choix de configuration le plus critique dans un déploiement CGNAT est la stratégie d'allocation des ports. Deux approches existent :
Allocation dynamique de ports (DPA) : Les ports sont alloués session par session à partir d'un pool partagé. Cela maximise l'efficacité de l'utilisation des ports, mais génère une entrée de journal pour chaque ouverture et fermeture de session - créant ainsi une charge de conformité et d'infrastructure massive à grande échelle.
Allocation de blocs de ports (PBA) : Chaque abonné se voit allouer un bloc de ports contigus dès le lancement de sa première session. Le bloc reste alloué jusqu'à ce que la session de l'abonné se termine. Cette approche ne génère des journaux que lorsqu'un bloc est alloué et libéré, réduisant ainsi le volume de logs jusqu'à 98 %.
| Paramètre de configuration | Valeur recommandée | Justification |
|---|---|---|
| Ports par abonné (Taille de bloc PBA) | 500 | Suffisant pour l'utilisation des applications web modernes sans épuisement du pool |
| Sessions simultanées maximales par abonné | 2 000 | Empêche un seul appareil infecté d'épuiser le pool |
| Délai d'attente de session (TCP établi) | 7 440 secondes (RFC 5382) | Aligne sur les recommandations de l'IETF pour le comportement NAT |
| Délai d'attente de session (UDP) | 300 secondes | Empêche les mappages UDP obsolètes de consommer de l'espace de port |
Référence de l'industrie : NFWare, un fournisseur CGNAT expert avec des déploiements dans plus de 100 FAI, recommande un maximum de 128 abonnés par IP publique avec 500 ports alloués par abonné. Dépasser cette limite - par exemple, pousser jusqu'à 256 abonnés par IP avec 250 ports chacun - augmente considérablement le risque d'abandons de session pendant les pics de charge.
Le Dual-Stack IPv6 comme voie de migration à long terme
Le CGNAT est une stratégie d'atténuation, pas une solution permanente. La bonne direction architecturale est un déploiement Dual-Stack : faire fonctionner l'IPv6 de manière native aux côtés de l'IPv4 avec CGNAT. Les appareils modernes et les principaux CDN (Google, Netflix, Meta, Cloudflare) préfèrent fortement l'IPv6 lorsqu'il est disponible. Dans un environnement dual-stack bien configuré, 60 à 70 % du trafic total peut être déchargé vers l'IPv6, réduisant considérablement la charge sur le pool CGNAT IPv4 et prolongeant sa durée de vie effective.
Pour les environnements de la santé et des transports où le support des appareils hérités est essentiel, le dual-stack offre également une voie de migration claire : les appareils compatibles IPv6 migrent de manière native, tandis que les anciens appareils uniquement IPv4 continuent de fonctionner via CGNAT sans aucune interruption pour l'utilisateur.
Guide d'implémentation
Étape 1 : Auditer votre allocation IP actuelle et la densité des appareils
Avant de déployer CGNAT, établissez une référence. Rassemblez les données suivantes à partir de vos systèmes de gestion de réseau existants :
- Nombre maximal d'appareils simultanés par sous-réseau
- Sessions moyennes et de pointe par appareil
- Pourcentage d'utilisation actuel des adresses IP publiques
- Configurations actuelles des délais d'expiration NAT
Ces données guident directement la taille de votre bloc PBA et vos besoins en pool d'adresses IP publiques.
Étape 2 : Concevoir le réseau de transit RFC 6598
Allouez le bloc 100.64.0.0/10 pour le réseau de transit de classe opérateur. Planifiez le sous-réseau pour qu'il corresponde à la topologie de votre campus - généralement un /24 ou /23 par bâtiment ou segment de couche d'accès. Assurez-vous que votre infrastructure de routage ne laisse pas échapper les préfixes RFC 6598 vers l'internet public ou les partenaires d'appairage.
Étape 3 : Déployer et configurer les passerelles CGNAT
La passerelle CGNAT est généralement un équipement matériel dédié ou une fonction réseau virtualisée (VNF) s'exécutant sur du matériel serveur standard. Paramètres de configuration clés :
- Pool NAT : Attribuez votre bloc IPv4 public au pool NAT. Assurez-vous que la taille du pool est appropriée pour votre ratio abonnés/IP cible.
- Configuration PBA : Définissez la taille du bloc à 500 ports. Configurez le nombre maximal de blocs par abonné à 1 (avec la possibilité de l'étendre à 2 si un abonné épuise son bloc initial, au lieu d'augmenter la taille du bloc de base).
- Journalisation : Configurez la sortie syslog vers votre SIEM. Avec le PBA, chaque entrée de journal enregistre : l'IP interne de l'abonné, l'IP publique attribuée, le début du bloc de ports attribué, la fin du bloc, l'horodatage de l'allocation et l'horodatage de la libération.
- Limites de session : Appliquez un maximum de 2 000 sessions simultanées par abonné pour éviter les abus.
Étape 4 : Intégrer avec la couche d'identité et d'authentification
Dans les environnements utilisant la plateforme de Guest WiFi, l'authentification par Captive Portal doit s'effectuer au niveau ou avant la limite NAT de niveau 1. Cela garantit que le fournisseur d'identité peut mapper avec précision les adresses MAC et les identifiants utilisateur aux adresses IP internes uniques avant que le trafic ne soit agrégé dans le pool CGNAT. La plateforme de Purple gère cela au niveau du point d'accès, maintenant une liaison utilisateur-IP claire qui persiste tout au long de la chaîne de traduction NAT.
Pour les déploiements d'accès sans mot de passe - comme décrit dans How a WiFi Assistant Enables Passwordless Access in 2026 - le même principe s'applique : la liaison d'identité doit être établie en amont de la passerelle CGNAT pour garantir une attribution précise des sessions.
Étape 5 : Configurer le double-pile (Dual-Stack) IPv6
Activez IPv6 sur tous les points d'accès et distribuez un préfixe /64 par VLAN via DHCPv6 ou SLAAC. Déclarez les routes IPv6 via votre fournisseur amont. Avant de réduire la taille de votre pool NAT IPv4, vérifiez que le trafic des principaux CDN (Google, Netflix, YouTube) se résout bien vers des enregistrements AAAA et s'achemine via IPv6.
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
Implémentez le NAT déterministe dans la mesure du possible. Le NAT déterministe utilise un mappage algorithmique entre l'adresse IP interne d'un abonné et son adresse IP publique et son bloc de ports attribués. Comme le mappage est calculable mathématiquement, il n'est pas nécessaire de maintenir ou d'enregistrer une table de session - le mappage peut être reconstitué à la demande à des fins d'interception légale. C'est la référence absolue pour les déploiements soucieux de la conformité.
Distribuez la charge de la passerelle CGNAT. Évitez de concentrer tout le trafic CGNAT à travers un seul équipement. Distribuez les passerelles sur le campus ou les bâtiments pour éviter un point de défaillance unique. Les passerelles distribuées atténuent également le risque de réputation IP : si une IP publique du pool est signalée par un CDN pour des modèles de trafic suspects (problèmes de CAPTCHA), seule une partie des utilisateurs est affectée.
Surveillez activement la réputation des adresses IP. Abonnez-vous à des flux de réputation IP (par exemple, Spamhaus, SURBL) et surveillez les adresses IP de votre pool NAT public. Maintenez un pool de réserve d'adresses IP propres pour effectuer une rotation si une adresse active est mise sur liste noire. Ceci est particulièrement critique dans les résidences étudiantes, où un petit nombre d'utilisateurs peut s'engager dans des activités qui déclenchent des signalements d'abus.
Appliquez des limites de session par abonné. Une limite stricte de 2 000 sessions simultanées par abonné empêche un seul appareil infecté - par exemple, un appareil participant à une attaque par déni de service distribué (DDoS) - d'épuiser l'intégralité du bloc de ports alloué à cette IP publique. Pour plus de détails sur la surveillance des performances réseau, consultez notre guide sur la mesure de la force du signal et de la couverture WiFi.
Alignez-vous sur la norme 802.1X pour le contrôle d'accès. Le déploiement de l'authentification basée sur les ports 802.1X au niveau de la couche d'accès garantit que seuls les appareils authentifiés reçoivent des allocations IP. Cela atténue le risque que des appareils malveillants consomment des allocations de ports et fournit une piste d'audit claire à des fins d'interception légale.
Dépannage et atténuation des risques
Charge de journalisation et de conformité
Au Royaume-Uni et en Europe, en vertu du GDPR et de l'Investigatory Powers Act 2016, les opérateurs de réseau doivent être en mesure de lier une adresse IP publique et un numéro de port à un utilisateur spécifique à un horodatage précis. Il s'agit d'une obligation légale non négociable.
Risque : Avec le CGNAT dynamique, la journalisation de chaque établissement et fermeture de session génère des téraoctets de données syslog quotidiennement. Un déploiement de 1 000 utilisateurs avec allocation dynamique peut générer 500 millions d'entrées de journal par jour. Cela sature l'infrastructure SIEM, gonfle les coûts de stockage et rend les enquêtes médico-légales impraticables.
Atténuation : L'allocation de blocs de ports (PBA) réduit le volume de journalisation jusqu'à 98 %. Avec la PBA, vous ne journalisez que les événements d'allocation et de libération de blocs - généralement deux entrées de journal par session utilisateur, au lieu de centaines ou de milliers. Assurez-vous que votre SIEM conserve ces journaux pendant un minimum de 12 mois pour vous conformer aux exigences britanniques de conservation des données.
Problèmes de CAPTCHA et de réputation IP
Lorsque 128 utilisateurs partagent une seule IP publique, le volume de trafic agrégé peut déclencher des limitations de débit ou des protections anti-bot sur les sites web majeurs. Les systèmes comme reCAPTCHA de Google, la gestion des bots de Cloudflare et d'autres solutions similaires utilisent des heuristiques basées sur l'IP qui risquent de classer à tort une IP CGNAT partagée comme une source de bots.
Atténuation : Répartissez votre pool CGNAT sur plusieurs IP publiques. Surveillez activement les scores de réputation. Envisagez de déployer le DNS-over-HTTPS (DoH) ou le DNS-over-TLS (DoT) pour éviter les problèmes de réputation liés au DNS. Informez les utilisateurs que l'apparition occasionnelle de CAPTCHA est un comportement connu dans les environnements à IP partagée.
Problèmes de compatibilité des applications
Certaines applications - en particulier les protocoles peer-to-peer, certaines implémentations VoIP et les anciennes plateformes de jeu - reposent sur un mappage de ports persistant ou sur l'initiation de connexions entrantes. Celles-ci peuvent ne pas fonctionner sous un double NAT.
Atténuation : Pour la VoIP, assurez-vous que votre passerelle CGNAT prend en charge l'ALG (Application Layer Gateway) pour le SIP. Pour le jeu en ligne, envisagez de mettre en œuvre un proxy UPnP ou un VLAN de jeu dédié avec un pool NAT distinct et moins dense. Pour les environnements de commerce de détail où les systèmes de point de vente nécessitent une connectivité entrante, placez ces appareils sur un VLAN distinct qui contourne entièrement la couche CGNAT.
ROI et impact commercial
Économies sur les dépenses d'investissement (CapEx)
Le déploiement du CGNAT permet de réaliser des économies de CapEx immédiates et substantielles. Au tarif du marché de 50 $ par adresse IPv4, une université de 5 000 lits nécessitant un ratio appareil/IP de 1:1 devrait acheter environ 35 000 adresses IP - pour un coût de 1,75 million de dollars. En déployant le CGNAT avec un ratio de 128:1, ce même déploiement nécessite moins de 300 IP publiques, réduisant les coûts d'acquisition d'IP à environ 15 000 $.
Même après avoir pris en compte le coût du matériel de passerelle CGNAT ou des fonctions réseau virtualisées (généralement entre 20 000 $ et 80 000 $ pour un déploiement à l'échelle d'un campus), les économies nettes restent considérables.
Réduction des dépenses d'exploitation (OpEx)
Une connectivité stable réduit directement la charge de travail du support technique. Les événements d'épuisement des ports - le principal mode de défaillance du PAT standard à grande échelle - génèrent un volume excessif de tickets d'assistance. Un déploiement CGNAT bien configuré avec des limites de session appropriées et un PBA élimine ce mode de défaillance, ce qui entraîne une réduction estimée de 30 à 40 % du volume de tickets de support liés au réseau.
Avantage concurrentiel dans les logements étudiants
Dans un marché compétitif du logement étudiant, la qualité du réseau est un critère de sélection majeur pour les futurs locataires. Les opérateurs capables de démontrer une connectivité constante et à haut débit - validée par des tableaux de bord WiFi Analytics affichant le taux de disponibilité, la qualité des sessions et la densité des appareils - exigent des loyers plus élevés et affichent un taux d'occupation supérieur. Cette stabilité d'infrastructure est également le fondement du déploiement de services géolocalisés avancés, comme le souligne l'article Purple launched offline maps mode for seamless, secure navigation for WiFi hotspots.
Étude de cas 1 : Résidence universitaire de 800 lits
Une résidence universitaire de 800 lits gérée par une université britannique rencontrait des problèmes de connectivité chroniques pendant les heures de pointe en soirée. L'enquête a révélé que leur configuration PAT à niveau unique, qui utilisait un sous-réseau public /29 (6 IP utilisables), épuisait les ports disponibles dès 19 h 30 chaque soir. L'opérateur a déployé une solution CGNAT avec PBA (500 ports par abonné, 128 abonnés par IP), a migré vers un sous-réseau public /27 (30 IP utilisables) et a activé la double pile IPv6. Les indicateurs post-déploiement ont montré une réduction de 94 % des incidents d'épuisement de ports par rapport au pilote initial d'allocation dynamique, une diminution de 38 % des tickets d'assistance liés au réseau et une réduction de 65 % du volume des journaux CGNAT. Dans les 60 jours suivant le déploiement, le taux de déchargement IPv6 a atteint 62 %.
Étude de cas 2 : Opérateur de résidences étudiantes privées (PBSA) de 1 200 chambres
Un opérateur privé de PBSA gérant trois sites dans deux villes britanniques devait standardiser son architecture réseau avant d'ouvrir un quatrième site. Son infrastructure existante utilisait un mélange de NAT à niveau unique et de segmentation VLAN ad hoc, sans stratégie de journalisation cohérente. Un déploiement CGNAT avec NAT déterministe a été mis en œuvre sur les trois sites, permettant un mappage abonné-IP calculable mathématiquement sans la charge de la journalisation des sessions. Cette approche a satisfait l'équipe juridique de l'opérateur concernant la conformité aux interceptions légales, a éliminé les coûts de stockage SIEM pour les journaux de session et a fourni un modèle d'architecture cohérent pour le quatrième site. L'opérateur a également intégré la plateforme Guest WiFi de Purple pour l'authentification par Captive Portal, établissant la liaison d'identité en amont de la passerelle CGNAT afin de garantir une attribution d'utilisateur précise dans les rapports d'analyse.
Définitions clés
CGNAT (Carrier-Grade NAT)
Une architecture réseau dans laquelle un opérateur effectue une traduction d'adresses réseau (NAT) au niveau d'une passerelle centralisée, permettant à plusieurs abonnés de partager une seule adresse IPv4 publique. Définie dans la RFC 6264 et la RFC 6888. Également connue sous le nom de Large-Scale NAT (LSN) ou CGN.
Les équipes IT rencontrent le CGNAT lorsqu'une seule IP publique est insuffisante pour desservir tous les appareils d'un réseau. Dans les résidences étudiantes, le CGNAT est le mécanisme principal pour gérer l'épuisement de l'IPv4 sans acheter d'espace d'adressage public supplémentaire.
NAT444
Une topologie CGNAT spécifique impliquant trois couches d'espace d'adressage IPv4 : les adresses privées de l'abonné (RFC 1918), les adresses partagées de classe opérateur (RFC 6598) et les adresses internet publiques. Le nom fait référence aux trois réseaux IPv4 traversés.
Le NAT444 est l'architecture standard pour les déploiements CGNAT dans les environnements multi-locataires. Les architectes réseau doivent comprendre le modèle à trois couches pour concevoir correctement le réseau intermédiaire et éviter le chevauchement d'adresses.
Espace d'adressage partagé RFC 6598
Le bloc d'adresses IPv4 100.64.0.0/10 (100.64.0.0 à 100.127.255.255) réservé par l'IANA pour une utilisation dans le réseau intermédiaire entre un CPE et une passerelle CGNAT. Cet espace n'est pas routable sur l'internet public et est spécifiquement conçu pour éviter les conflits d'adresses dans les déploiements NAT444.
Les équipes IT doivent utiliser la norme RFC 6598 - et non la RFC 1918 - pour le réseau intermédiaire CGNAT. L'utilisation de la RFC 1918 pour ce segment crée des risques de chevauchement d'adresses lorsque les mêmes plages RFC 1918 sont utilisées dans les réseaux d'abonnés.
Port Block Allocation (PBA)
Une stratégie d'attribution de ports CGNAT dans laquelle un bloc de ports contigus (par exemple, 500 ports) est attribué à chaque abonné pour la durée de sa session, plutôt que d'allouer des ports individuellement par connexion. Définie dans la RFC 7422.
L'allocation de blocs de ports (PBA) est l'approche recommandée pour les déploiements CGNAT conformes au GDPR. Elle réduit la surcharge de journalisation jusqu'à 98 % par rapport à l'allocation dynamique de ports, rendant la conformité aux interceptions légales opérationnellement réalisable à grande échelle.
NAT déterministe
Une configuration CGNAT dans laquelle la correspondance entre l'adresse IP interne d'un abonné et son IP publique et bloc de ports attribués est calculée de manière algorithmique, sans maintenir de table de session. La correspondance est mathématiquement réversible, ce qui permet d'identifier l'abonné sans récupération de journaux.
Le NAT déterministe est la référence absolue pour les déploiements soucieux de la conformité. Il élimine entièrement la surcharge de journalisation tout en répondant aux exigences d'interception légale, car l'abonné peut être identifié à partir d'une IP publique, d'un port et d'un horodatage à l'aide de l'algorithme connu.
PAT (Port Address Translation)
Une forme de traduction d'adresses réseau dans laquelle plusieurs adresses IP privées sont mappées vers une seule adresse IP publique en différenciant les connexions à l'aide de numéros de ports sources uniques. Également appelé NAT overload ou NAT many-to-one.
Le PAT est le NAT à niveau unique standard utilisé dans la plupart des routeurs d'entreprise en périphérie. C'est le prédécesseur du CGNAT et il est insuffisant pour les environnements multi-locataires denses en raison de l'épuisement des ports à grande échelle.
Table de session
Une structure de données gérée par une passerelle NAT qui enregistre l'association entre l'adresse IP et le port internes (privés), et l'adresse IP et le port externes (publics), pour chaque connexion active. La table de session constitue la principale ressource de mémoire et de traitement consommée par le CGNAT.
Le dimensionnement de la table de session est un paramètre critique de planification de capacité pour les passerelles CGNAT. Un déploiement de 1 000 abonnés avec un maximum de 2 000 sessions par abonné nécessite une capacité de table de session d'au moins 2 millions d'entrées. Un sous-dimensionnement de la table de session entraîne des échecs de connexion.
Dual-Stack
Une configuration réseau dans laquelle les protocoles IPv4 et IPv6 sont actifs simultanément sur la même infrastructure réseau et les mêmes terminaux. Les appareils dotés de la fonctionnalité Dual-stack préféreront IPv6 pour les connexions vers des destinations compatibles IPv6.
Le Dual-stack est la stratégie de transition recommandée pour les déploiements CGNAT. En déchargeant le trafic compatible IPv6 vers le chemin IPv6 natif, le Dual-stack réduit la charge sur le pool CGNAT IPv4 et offre une voie de migration vers un réseau principalement IPv6.
Espace d'adressage privé RFC 1918
Les trois plages d'adresses IPv4 réservées à l'usage des réseaux privés : 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Ces adresses ne sont pas routables sur l'internet public et sont utilisées pour l'adressage réseau interne.
Les adresses RFC 1918 sont utilisées pour l'adressage des appareils des abonnés dans les déploiements CGNAT. Les architectes réseau doivent s'assurer que les plages RFC 1918 utilisées dans les réseaux d'abonnés ne chevauchent pas celles utilisées dans le réseau CGNAT intermédiaire - c'est pourquoi la RFC 6598 est utilisée pour la couche intermédiaire.
Interception légale
L'interception de communications légalement autorisée par les forces de l'ordre. Au Royaume-Uni, elle est régie par l'Investigatory Powers Act 2016. Les opérateurs réseau doivent être en mesure d'identifier l'abonné associé à une adresse IP publique, un port et un horodatage spécifiques lors de la réception d'une demande d'interception légale.
La conformité en matière d'interception légale est le principal moteur des exigences de journalisation CGNAT. Les opérateurs doivent conserver des journaux suffisants pour identifier les abonnés à partir de l'IP publique et des données de port. Le PBA et le NAT déterministe sont les deux architectures qui rendent cela possible à grande échelle sans surcharger l'infrastructure de journalisation.
Exemples concrets
Une résidence étudiante de 600 lits utilise actuellement un unique sous-réseau public /29 (6 IP utilisables) avec du PAT standard. Pendant les heures de pointe en soirée (19:00-23:00), les utilisateurs signalent de nombreuses pannes de connectivité. L'équipe réseau a confirmé la saturation des ports sur le routeur PAT. L'opérateur dispose d'un budget pour du matériel de passerelle CGNAT mais ne peut pas acquérir d'adresses IP publiques supplémentaires au-delà d'un /27 (30 IP utilisables). Concevez un déploiement CGNAT qui élimine le problème de saturation des ports et soutient la croissance future jusqu'à 900 lits.
Étape 1 - Évaluation initiale : Avec 600 lits à raison de 5 appareils par occupant, le nombre maximal d'appareils connectés simultanément est d'environ 3 000. À raison de 500 ports par abonné (PBA), chaque IP publique prend en charge 128 abonnés. Avec 30 IP utilisables dans le /27, la capacité maximale théorique d'abonnés est de 3 840, ce qui est suffisant pour 900 lits à 4,3 appareils par occupant. Étape 2 - Réseau intermédiaire RFC 6598 : Allouer 100.64.0.0/20 pour le réseau intermédiaire de classe opérateur, fournissant 4 096 adresses pour le trafic entre l'équipement d'abonné (CPE) et la passerelle CGNAT. Sous-réseau par aile de bâtiment : 100.64.0.0/24, 100.64.1.0/24, etc. Étape 3 - Dimensionnement de la passerelle CGNAT : Déployer une passerelle CGNAT avec une capacité de table de session d'au moins 768 000 entrées (3 000 abonnés × 2 000 sessions max par abonné, avec une marge de sécurité de 20 %). Configurer la PBA avec des blocs de 500 ports. Définir le nombre maximum de blocs par abonné à 1, avec un dépassement autorisé à 2 blocs pour les abonnés dépassant 500 sessions simultanées. Étape 4 - Double pile IPv6 : Activer l'IPv6 sur tous les points d'accès. Distribuer les préfixes /64 via SLAAC. Viser un déchargement IPv6 de 60 % sous 90 jours, ce qui réduit efficacement la charge CGNAT IPv4 à 1 200 abonnés IPv4 simultanés, ce qui correspond tout à fait à la capacité du /27. Étape 5 - Journalisation : Configurer le syslog vers le SIEM avec uniquement les événements d'attribution et de libération de blocs PBA. Conserver les journaux pendant 12 mois minimum. Étape 6 - Limites de sessions : Imposer un maximum de 2 000 sessions par abonné au niveau de la passerelle CGNAT pour éviter les abus.
Un opérateur de résidences étudiantes de type PBSA a déployé le CGNAT sur un site de 1 000 lits en utilisant l'allocation dynamique de ports. Son équipe juridique a signalé que l'approche actuelle de journalisation génère 400 Go de données syslog par jour, ce qui sature le SIEM et rend impossible le traitement des demandes d'interception légale émanant des forces de l'ordre. Revoir la stratégie de journalisation afin de respecter les obligations d'interception légale du Royaume-Uni (UK GDPR) tout en réduisant le volume des journaux à un niveau gérable.
Étape 1 - Migration vers l'allocation de blocs de ports (PBA) : Remplacez l'allocation dynamique de ports par l'allocation PBA à 500 ports par abonné. Cela réduit immédiatement les événements de journalisation d'un par session à un par attribution de bloc et un par libération de bloc. Pour un déploiement de 1 000 utilisateurs avec une moyenne de 3 cycles d'attribution/libération de blocs par utilisateur et par jour, cela génère environ 6 000 entrées de journal par jour - une réduction de plus de 99 % par rapport au modèle d'allocation dynamique. Étape 2 - Schéma des journaux : Assurez-vous que chaque entrée de journal PBA capture : (a) l'adresse IP interne de l'abonné, (b) l'adresse IP publique attribuée, (c) le début et la fin du bloc de ports attribué, (d) l'horodatage de l'attribution du bloc (UTC), (e) l'horodatage de la libération du bloc (UTC), (f) l'identifiant de l'abonné (adresse MAC ou nom d'utilisateur RADIUS). Étape 3 - Option NAT déterministe : Si la plateforme CGNAT le prend en charge, migrez vers le NAT déterministe. Cela élimine complètement la journalisation pour les opérations de routine, car la correspondance est calculable mathématiquement. Conservez les journaux PBA uniquement pour les cas de débordement non déterministes. Étape 4 - Politique de conservation : Conservez les journaux pendant 12 mois dans un espace de stockage de journaux inviolable (par exemple, un stockage d'objets compatible S3 à écriture unique). Mettez en œuvre des contrôles d'accès afin que la récupération des journaux pour les demandes d'interception légale nécessite une double autorisation. Étape 5 - Procédure de réponse aux incidents : Documentez la procédure de réponse aux demandes d'interception légale, y compris la formule de calcul inverse pour identifier l'abonné à partir d'une IP publique, d'un port et d'un horodatage sous NAT déterministe.
Une équipe informatique universitaire signale que les étudiants sont confrontés à de fréquents défis CAPTCHA et à des limitations de débit de la part de Google, Netflix et de plateformes de jeux. L'enquête révèle que 200 étudiants partagent une seule adresse IP publique via CGNAT. On a indiqué à l'équipe qu'il n'est pas possible d'acquérir plus d'adresses IP publiques à court terme. Quelles mesures d'atténuation immédiates peuvent être mises en œuvre sans modifier l'allocation d'adresses IP ?
Étape 1 - Réduire la densité d'abonnés : Le ratio de 200:1 est la cause principale. Même sans adresses IP publiques supplémentaires, vérifiez si le pool CGNAT est utilisé efficacement. Assurez-vous que le dual-stack IPv6 est entièrement activé - si 60 % du trafic est déchargé vers l'IPv6, le nombre effectif d'abonnés IPv4 tombe à environ 80 par IP, ce qui est bien en dessous du seuil recommandé de 128:1. Étape 2 - Rotation des adresses IP : Mettez en œuvre une politique de rotation pour le pool d'adresses IP publiques. Si la passerelle CGNAT le prend en charge, configurez une rotation périodique de l'adresse IP publique attribuée à chaque groupe d'abonnés. Cela évite qu'une seule adresse IP n'accumule une réputation négative persistante. Étape 3 - Optimisation DNS : Assurez-vous que les résolveurs DNS fournis aux clients renvoient de préférence des enregistrements AAAA. De nombreux déclencheurs de CAPTCHA sont basés sur le DNS - si un client résout inutilement un service vers une adresse IPv4, il passe par le CGNAT alors qu'il pourrait utiliser l'IPv6 de manière native. Étape 4 - Ajustement du délai d'expiration des sessions : Réduisez les délais d'expiration des sessions UDP par défaut (souvent 300 secondes) à 60 secondes pour le trafic UDP non-DNS. Cela libère de l'espace de ports plus rapidement et réduit le volume apparent de sessions du point de vue des services externes. Étape 5 - Communiquer avec les plateformes concernées : Pour les problèmes persistants de mise sur liste noire, soumettez des demandes de retrait des listes aux principales bases de données de réputation d'adresses IP (Spamhaus, SURBL). Documentez le fait que l'adresse IP est une adresse CGNAT partagée desservant un établissement d'enseignement légitime.
Questions d'entraînement
Q1. Un campus d'hébergement étudiant de 2 000 lits dispose d'un sous-réseau public /26 (62 adresses IP utilisables). L'équipe réseau planifie un déploiement CGNAT. Calculez : (a) le nombre maximum d'abonnés pouvant être pris en charge au ratio recommandé de 128:1, (b) la capacité totale de ports disponibles, (c) la taille recommandée du bloc PBA, et (d) si le /26 existant est suffisant ou si des adresses IP supplémentaires sont nécessaires.
Conseil : Commencez par le nombre total d'adresses IP utilisables dans un /26, puis appliquez le ratio d'abonnés de 128:1. Comparez le résultat au nombre d'appareils pour 2 000 lits avec un ratio réaliste d'appareils par occupant. Prenez en compte le déchargement IPv6 Dual-stack dans votre recommandation finale.
Voir la réponse type
Un /26 fournit 62 adresses IP publiques utilisables. À 128 abonnés par IP, la capacité maximale CGNAT IPv4 est de 62 × 128 = 7 936 abonnés. À raison de 5 appareils par occupant, 2 000 lits génèrent environ 10 000 appareils simultanés. Sans IPv6, le /26 est insuffisant (7 936 < 10 000). Cependant, avec un déchargement IPv6 Dual-stack atteignant 60 %, la charge IPv4 effective chute à environ 4 000 appareils - ce qui est largement inférieur à la capacité du /26 qui est de 7 936. La taille de bloc PBA recommandée est de 500 ports par abonné. Capacité totale de ports : 62 IP × 64 000 ports utilisables = 3 968 000 ports. À 500 ports par abonné : 3 968 000 / 500 = 7 936 abonnés maximum. Recommandation : Déployer le CGNAT avec PBA à 500 ports/abonné, activer le Dual-stack IPv6 comme condition préalable, et le /26 existant sera suffisant. Si le déchargement IPv6 ne peut pas être garanti au-dessus de 50 %, acquérir un /27 supplémentaire comme tampon.
Q2. Un déploiement CGNAT dans une résidence étudiante de 500 lits génère des inquiétudes en matière de conformité. L'équipe juridique de l'opérateur a reçu une demande d'interception légale de la part des forces de l'ordre pour une adresse IP publique spécifique (203.0.113.45), port 51432, à l'horodatage 2025-11-15 21:47:33 UTC. La passerelle CGNAT est configurée avec une allocation dynamique de ports. Le SIEM contient 180 jours de journaux, mais l'équipe forensique signale que la localisation de l'abonné spécifique à partir des journaux prend plus de 4 heures par demande. Identifiez la cause d'origine et proposez une solution qui réduit le temps de réponse à moins de 15 minutes.
Conseil : Le temps de réponse de 4 heures est un symptôme de l'architecture de journalisation, et non un problème de rétention des données. Examinez quelles informations sont enregistrées dans le cadre d'une allocation dynamique par rapport au PBA, et comment le NAT déterministe modifierait entièrement le processus de réponse.
Voir la réponse type
Cause d'origine : L'allocation dynamique de ports génère une entrée de journal par session. Avec 500 utilisateurs × des centaines de sessions par utilisateur et par heure, le SIEM contient des millions d'entrées de journal par jour. Localiser une seule entrée par IP, port et horodatage nécessite une recherche plein texte sur potentiellement des milliards d'enregistrements - d'où le temps de réponse de 4 heures. Option de remédiation 1 (PBA) : Migrer vers l'allocation de blocs de ports (Port Block Allocation). Avec la PBA, l'entrée de journal pour le port 51432 enregistrerait l'attribution du bloc (par ex. ports 51001-51500 attribués à l'abonné 192.168.1.23 à 21:30:00 UTC, libérés à 23:15:00 UTC). Une seule requête indexée sur l'IP publique + plage de ports + horodatage renvoie le résultat en quelques secondes. Temps de réponse estimé : moins de 2 minutes. Option de remédiation 2 (NAT déterministe) : Si la plateforme le prend en charge, migrer vers le NAT déterministe. Le port 51432 peut être recalculé mathématiquement à l'envers vers l'IP interne de l'abonné sans aucune requête de journal. Temps de réponse : moins de 30 secondes. Action immédiate : Indexer les journaux SIEM existants sur (public_ip, port, timestamp) pour réduire le temps de réponse actuel pendant la planification de la migration PBA.
Q3. Un architecte réseau conçoit l'infrastructure CGNAT pour un nouveau projet de résidence étudiante de 800 lits. Le FAI amont a fourni un sous-réseau public /27 et a confirmé que le transit IPv6 est disponible. L'opérateur souhaite également déployer la plateforme Purple de WiFi invité pour l'authentification par Captive Portal. Décrivez le positionnement correct de l'authentification par Captive Portal par rapport à la passerelle CGNAT, et expliquez pourquoi un positionnement incorrect crée un risque de conformité.
Conseil : Considérez les informations que le Captive Portal doit capturer (identité de l'utilisateur, MAC du terminal, IP interne) et à quel moment de la chaîne de traduction NAT ces informations sont encore disponibles. Pensez à ce qui arrive à l'adresse IP interne après son passage par la passerelle CGNAT.
Voir la réponse type
L'authentification par Captive Portal doit avoir lieu au niveau ou avant la limite NAT de niveau 1 - c'est-à-dire au niveau du point d'accès ou de la couche CPE, avant que le trafic n'entre dans le réseau intermédiaire RFC 6598. Positionnement correct : La plateforme de WiFi invité de Purple authentifie l'utilisateur au niveau du point d'accès. La plateforme enregistre l'association : identité de l'utilisateur → adresse MAC → IP interne RFC 1918 → horodatage. Cette association est établie avant que la passerelle CGNAT n'effectue sa traduction. La passerelle CGNAT associe ensuite l'IP RFC 1918 à une IP publique et un bloc de ports, et le journal PBA enregistre : IP RFC 1918 → IP publique → bloc de ports → horodatage. Les deux enregistrements de journal peuvent être joints sur l'IP RFC 1918 et l'horodatage pour produire une chaîne complète : identité de l'utilisateur → IP publique + port. Positionnement incorrect (Captive Portal après la passerelle CGNAT) : Si l'authentification a lieu après la passerelle CGNAT, la plateforme ne voit que l'IP publique et le port - pas l'IP interne. Plusieurs utilisateurs derrière la même IP CGNAT sont alors impossibles à distinguer. La plateforme ne peut pas créer d'association fiable entre l'utilisateur et l'IP, ce qui rend l'attribution de l'interception légale impossible et enfreint les exigences de responsabilité du GDPR. C'est là que réside le risque de conformité. Avec l'architecture de Purple, l'association d'identité est établie en amont de la couche CGNAT, garantissant une attribution précise de l'utilisateur tant dans la plateforme d'analyse que dans la chaîne de journaux de conformité.
Continuer la lecture de cette série
Pourquoi le WiFi pour invités de type hôtelier échoue dans les bâtiments résidentiels
Vous serez en mesure de diagnostiquer pourquoi les résidents des immeubles BTR, des résidences étudiantes et des MDU signalent constamment des pannes WiFi, et de choisir le modèle d'authentification qui les résout. La solution consiste à utiliser une clé iPSK par foyer sur vos points d'accès existants, tout en conservant un réseau Captive Portal distinct pour les visiteurs.
Conception de réseaux WiFi pour les immeubles de bureaux multi-locataires
Ce guide fournit aux responsables informatiques, architectes réseau et CTO un plan indépendant des fournisseurs pour concevoir des réseaux WiFi évolutifs, sécurisés et isolés dans les immeubles de bureaux multi-locataires. Il traite de la segmentation VLAN sous IEEE 802.1Q, de l'attribution dynamique de VLAN via 802.1X et RADIUS, de la planification RF pour les environnements à haute densité et des considérations de conformité dans le cadre du GDPR et du PCI DSS. Les exploitants de sites et gestionnaires d'immeubles y trouveront des conseils d'architecture concrets, des études de cas réels et des pièges de configuration à éviter avant le déploiement.
Temps moyen d'innocence : comment prouver que le problème ne vient pas du WiFi
Le temps moyen d'innocence (MTTI) est la métrique critique définissant le temps que les équipes informatiques passent à prouver qu'un problème de réseau n'est pas de leur faute. Ce guide détaille une méthodologie d'observabilité en cinq étapes pour éliminer les accusations mutuelles dans les environnements multi-locataires, en remplaçant les reproches par des preuves partagées pour réduire le temps moyen de résolution (MTTR).
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.