Qu’est-ce que CGNAT ? Pourquoi la redirection de port échoue et comment contourner le problème

Quand un Port Forward Correct ne Mène Nulle Part

Votre NAS s’ouvre normalement à la maison. Le service fonctionne, et la règle de port-forwarding pointe vers la bonne adresse locale. Ensuite, vous basculez votre téléphone sur les données mobiles, réessayez et obtenez un timeout. Le même schéma peut affecter un serveur de jeu domestique, un serveur VPN, un flux CCTV ou une application auto-hébergée.

La réponse rapide est que la règle peut être correcte mais se situer derrière une autre limite. Avec Carrier-Grade NAT (CGNAT), le FAI partage les adresses IPv4 publiques et prend la première décision entrante en amont. Vous contrôlez la règle sur votre routeur domestique, mais une nouvelle connexion Internet ne l’atteint jamais à moins que le traducteur du fournisseur ne sache où l’envoyer.

Cela ne prouve pas que CGNAT en est responsable ; les problèmes locaux peuvent sembler identiques. Le service peut écouter uniquement sur localhost, ou un pare-feu hôte peut le bloquer. Une règle de routeur peut utiliser le mauvais protocole TCP/UDP ou une adresse cible obsolète, tandis qu’un second routeur local peut ajouter une autre limite. Identifiez d’abord la limite, distinguez CGNAT du NAT ordinaire et du double NAT, puis choisissez une solution de contournement pour l’accès dont vous avez besoin.

Mots-clés rapides : Ce qu’est CGNAT et pourquoi les FAI l’utilisent

Ces termes suffisent pour suivre où s’arrête cette connexion manquante.

RFC 6888 définit un NAT de classe opérateur (CGN)—aussi appelé NAT à grande échelle (LSN)—comme une fonction côté fournisseur qui permet à plusieurs abonnés de partager une adresse IPv4. Les abonnés ne la gèrent pas. « Classe opérateur » décrit le placement et l’échelle, pas une qualité supérieure.

La limite de propriété ressemble à ceci :

YOU CONTROL                         ISP CONTROLS
device → home router / NAT → ISP CGNAT → shared public IPv4 → internet

Le routeur domestique contrôle le réseau local du client. Le CGN du FAI mappe les connexions des abonnés à son adresse publique partagée. La navigation normale fonctionne toujours parce qu’un appareil démarre la conversation et les deux couches de traduction peuvent suivre la réponse.

Pensez à l’adresse IPv4 publique comme l’entrée de rue d’un bâtiment et à un port comme un interphone. Votre routeur est le bureau de réception intérieur. CGNAT ajoute un bureau extérieur partagé par de nombreux clients et exploité par le FAI. Les ports aident ce bureau extérieur à suivre les conversations actives ; ils ne donnent pas à chaque client la propriété permanente de chaque interphone sur l’adresse partagée.

Les FAI utilisent cette conception parce que l’espace IPv4 routable globalement est limité et la transition IPv6 reste incomplète. Les pools régionaux gratuits sont effectivement épuisés, bien que les adresses existantes puissent toujours être transférées et réutilisées. CGNAT préserve la compatibilité IPv4 en partageant les adresses rares. IPv6 fournit l’espace d’adresses plus grand à long terme, mais il n’est pas disponible de bout en bout partout.

NAT vs Double NAT vs CGNAT

Les questions décisives ne sont pas « Combien de boîtes vois-je ? » mais « Où la traduction se produit-elle et qui peut la modifier ? »

📝 Note : CGNAT aboutit souvent à deux couches NAT IPv4 quand un routeur domestique est présent, mais « CGNAT » désigne la fonction exploitée par l’ISP tandis que « double NAT » décrit seulement la topologie.

Cette distinction de propriété change ce que vous pouvez corriger. Avec deux passerelles locales, vous pouvez peut-être utiliser le mode bridge/AP ou configurer les deux couches. Un traducteur de fournisseur se situe en dehors de ces contrôles, et certaines conceptions CGNAT n’incluent pas du tout de traducteur exploité par le client.

Les étiquettes de console telles que « ouvert », « modéré » ou « strict NAT » sont distinctes. Elles résument le comportement de connectivité pour cette plateforme ; elles n’identifient pas qui possède les traducteurs ni ne prouvent l’existence de CGNAT.

Pourquoi la redirection de port échoue derrière CGNAT

Le trafic sortant fonctionne car chaque traducteur crée un état : un enregistrement temporaire reliant un flux interne à une adresse et un port externes. Lorsque votre appareil lance une demande, le routeur domestique et le CGN de l’ISP l’enregistrent chacun, permettant aux réponses correspondantes de revenir.

Une nouvelle connexion entrante n’a pas un tel état. Elle atteint d’abord l’IPv4 public partagée de l’ISP, où le CGN n’a aucun mappage spécifique à l’abonné :

OUTBOUND WORKS
device → home NAT [state created] → ISP CGN [state created] → internet
device ← home NAT [state match]   ← ISP CGN [state match]   ← reply

NEW INBOUND CONNECTION STOPS
outside user → shared public IPv4 → ISP CGN
                                      X — no subscriber mapping
                                      home router is never reached

C’est pourquoi la redirection de port CGNAT échoue. Votre règle de routeur domestique peut être valide, mais elle appartient à la réception intérieure. Modifier la liste des visiteurs de ce bureau ne peut pas dire au bureau extérieur partagé de l’ISP quel abonné devrait recevoir un visiteur inattendu. Le paquet n’atteint jamais votre règle.

Un proxy inverse du côté domestique inaccessible ne change pas cela. Il peut organiser les demandes après leur arrivée, mais il ne peut pas créer la route manquante. Un tunnel inverse—ou un proxy ou relais à une arête accessible—est différent car le côté privé établit d’abord un chemin sortant.

Comment savoir si vous êtes derrière CGNAT

Utilisez les preuves dans cet ordre :

1. Désactivez les VPN et les proxies. Éteignez tout ce qui modifie l’adresse publique à partir de laquelle votre trafic semble partir.
2. Identifiez la passerelle côté ISP. Utilisez le routeur ou le modem directement connecté au fournisseur, pas un deuxième routeur plus loin dans votre réseau.
3. Comparez les deux adresses. Notez l’adresse WAN ou IPv4 Internet de cette passerelle, puis utilisez un service externe pour afficher votre IPv4 publique en même temps.

❗ Important : Une différence entre les adresses WAN et publiques prouve qu’une limite de traduction en amont existe, pas automatiquement que c’est CGNAT. Ne faites cette déduction que depuis la passerelle directement connectée à l’ISP.

4. Interprétez le résultat. Utilisez ces signaux ensemble :
   • Une adresse WAN dans 100.64.0.0/10—100.64.0.0 à 100.127.255.255—est une forte preuve de CGNAT. RFC 6598 réserve cet Espace d’adresses partagées non routable globalement pour l’utilisation par le fournisseur ; ce n’est pas l’espace privé RFC 1918.
   • Une adresse dans 10.0.0.0/8, 172.16.0.0/12, ou 192.168.0.0/16 montre également une WAN non publique, mais elle peut appartenir à un autre routeur local.
   • Des adresses WAN et publiques différentes indiquent une traduction en amont. Les adresses routable globalement correspondantes rendent CGNAT IPv4 ordinaire beaucoup moins probable sur ce chemin.
5. Excluez les causes locales. Avant de l’appeler CGNAT, vérifiez que :
   • Le service écoute sur son adresse LAN, pas seulement sur localhost.
   • Le pare-feu hôte autorise le port et le protocole prévus.
   • La règle du routeur cible l’adresse interne actuelle et le bon choix TCP/UDP.
   • Un deuxième routeur local n’ajoute pas une autre couche de traduction.
   • Le test provient de données mobiles ou d’un autre réseau véritablement externe.
6. Confirmez avec l’ISP. Traceroute peut soutenir le diagnostic lorsque des sauts partagés ou privés apparaissent au-delà de la passerelle domestique, mais les sauts cachés le rendent inconclus. Demandez au fournisseur si la ligne utilise CGNAT et si une IPv4 publique dynamique ou statique est disponible.

Ce que CGNAT affecte—et ce qu’il n’affecte généralement pas

Cette séparation sortant/entrant détermine ce que les utilisateurs remarquent. La navigation, le streaming, les téléchargements et la plupart des clients d’applications fonctionnent généralement normalement. Les problèmes apparaissent quand un système externe doit établir une nouvelle connexion vers quelque chose derrière la limite du fournisseur.

L’hébergement IPv4 direct et l’accès à distance nécessitent donc un autre chemin accessible. Sur un réseau privé, cela affecte l’accès à un NAS, un système CCTV ou un tableau de bord interne. Les sites web publics, les récepteurs webhook et les serveurs de jeux font face à la même exigence d’entrée. Un client VPN fonctionne généralement parce qu’il se connecte vers l’extérieur. Un serveur VPN domestique est différent parce que les utilisateurs distants établissent la connexion, il a donc besoin d’une entrée accessible, d’IPv6 compatible ou d’un point de terminaison sur un relais ou un hôte public.

Les jeux pair-à-pair, la voix et le partage de fichiers sont moins prévisibles. Certaines applications trouvent un itinéraire direct, tandis que d’autres utilisent un relais via un intermédiaire accessible. Un relais peut préserver la connectivité au prix d’une latence supplémentaire. Quand la traversée échoue, l’application peut signaler un NAT restrictif ou échouer à se connecter. RFC 7021 documente ces points de pression sans impliquer un échec universel.

Partager une adresse IPv4 peut fusionner des abonnés non liés en une seule réputation. Le comportement d’un utilisateur peut amener d’autres abonnés à voir plus de CAPTCHA ou de limites de débit. L’adresse partagée peut également se retrouver sur des listes de blocage, déclencher des restrictions de connexion simultanée ou produire une géolocalisation approximative. Une sortie résidentielle partagée ou changeante complique davantage les listes blanches professionnelles qui s’attendent à un point de terminaison stable.

📝 Remarque : Bloquer par défaut les IPv4 entrants non sollicités peut réduire l’exposition accidentelle, mais CGNAT n’est pas un pare-feu et ne remplace pas l’authentification, les mises à jour, TLS ou la politique d’accès.

CGNAT n’arrête pas le trafic sortant malveillant. Il ne sécurise pas les applications exposées via un autre chemin ou ne contrôle pas qui peut se connecter. Un tunnel, une IP publique ou une route IPv6 nécessitent toujours des contrôles de sécurité délibérés.

Cinq façons de contourner CGNAT

Les cinq options résolvent différents problèmes d’accès. Les mailles privées, les tunnels gérés et les relais VPS partagent un motif utile : le côté privé se connecte d’abord vers l’extérieur.

private service → outbound mesh / tunnel link → reachable edge ← outside user

Dans l’analogie du bâtiment, vous obtenez soit une entrée de rue utilisable, soit maintenez une ligne vers une entrée ailleurs.

📝 Note : « Contourner » est un raccourci. Ces approches ne désactivent pas le NAT du transporteur ; elles obtiennent un autre bord public, utilisent IPv6 de bout en bout, ou établissent un chemin créé par une connexion sortante.

Commencez par le tableau, puis utilisez les détails ci-dessous pour les compromis qui importent pour votre configuration.

1. Demander un IPv4 public à l’ISP

Pour l’IPv4 entrant général, c’est généralement l’option la plus simple quand l’ISP l’offre. Un IPv4 public dynamique fonctionne avec DNS mis à jour. Choisissez un IPv4 public statique pour les listes d’autorisation stables, les enregistrements ou les points de terminaison VPN. Vérifiez la disponibilité et le coût, et sécurisez tout service que vous exposez directement.

2. Utiliser IPv6 natif

Le trafic IPv6 évite CGNAT IPv4. L’accès direct nécessite un préfixe global, un écouteur IPv6, des règles de pare-feu appropriées, un DNS correct si nécessaire, et IPv6 du côté distant. Cela n’aide pas les clients IPv4 uniquement ou n’expose pas un service automatiquement.

3. Construire une maille privée

Un VPN maille tel que Tailscale convient aux utilisateurs et appareils de confiance qui peuvent exécuter un logiciel client authentifié. Il essaie les connexions directes, puis peut revenir à un relais pair ou DERP avec un coût de performance. Il n’est pas destiné aux visiteurs anonymes ou aux webhooks publics.

4. Publier via un tunnel sortant géré

Un service tel que Cloudflare Tunnel connecte l’origine vers l’extérieur à un bord fournisseur. Cela fonctionne bien pour les applications web, les API, les démos et l’accès privé contrôlé. Les visiteurs HTTP publics peuvent ne pas avoir besoin de client, tandis que les modes privés ou non-web peuvent nécessiter un logiciel fournisseur. Le support du protocole, l’identité, les limites et la disponibilité du bord restent des dépendances du fournisseur.

5. Utiliser un VPS comme bord public — ou déplacer la charge de travail

Un VPS peut relayer le trafic via un tunnel sortant depuis la maison, ou héberger l’application directement quand elle n’a pas besoin de données ou de matériel du réseau local. Cela offre un point de terminaison stable et un contrôle TCP/UDP large. Vous êtes responsable de la sécurité, de la surveillance, de la fiabilité du tunnel, de la bande passante, de la gestion des abus et de la latence ajoutée. Un VPS AlexHost approprié peut remplir ce rôle, sous réserve de son adressage public et de sa politique réseau.

Quelle option correspond à votre cas d’usage ?

Choisissez l’architecture en posant quatre questions dans l’ordre :

1. L’accès est-il limité à des personnes et appareils de confiance, ou ouvert au public ?
2. Chaque appareil de connexion peut-il installer et s’authentifier via un logiciel client ?
3. Le service est-il basé sur le web, ou nécessite-t-il un comportement TCP/UDP arbitraire ?
4. Préférez-vous la commodité gérée ou le contrôle de la passerelle publique ?

Pour un NAS de confiance, une CCTV ou un accès administrateur, utilisez un VPN maillé lorsque les utilisateurs peuvent installer un logiciel client. Pour les points de terminaison web publics et les webhooks, utilisez un tunnel géré ou un hébergement public. Déplacez la charge de travail si elle n’a pas besoin du LAN domestique.

Pour TCP/UDP public, utilisez un IPv4 public ISP, une périphérie VPS, ou IPv6 lorsque tous les clients le supportent. L’hébergement de jeux est spécifique au titre : vérifiez son modèle de serveur, le support de traversée et les protocoles. Un tunnel générique ne peut pas garantir un meilleur libellé NAT de console.

Un point de terminaison VPN public nécessite un IPv4 public, un IPv6 fonctionnel, ou un hôte VPS. Pour l’entrée commerciale ou les listes blanches de partenaires, choisissez une adresse statique ou une passerelle contrôlée au lieu d’une sortie résidentielle partagée.

Questions et idées fausses courantes sur CGNAT

CGNAT est-il la même chose que double NAT ? Non. CGNAT identifie un NAT multi-abonnés exploité par un FAI. Double NAT signifie seulement que le trafic traverse deux traducteurs.

CGNAT ralentit-il toujours Internet ? Non. Les performances dépendent davantage du fournisseur, de l’application et de la présence d’un relais.

Un DNS dynamique peut-il corriger CGNAT ? Non. Il suit une adresse changeante mais ne peut pas créer un mappage en amont. Il aide une fois que vous disposez d’une adresse publique dynamique accessible.

Un VPN normal contourne-t-il CGNAT ? Généralement non. Cela fonctionne seulement si le service VPN fournit un transfert entrant, une superposition privée ou un autre point d’entrée accessible.

IPv6 peut-il le résoudre ? Oui, quand les deux extrémités ont IPv6 et que le pare-feu et DNS le permettent. Cela n’aide pas les clients IPv4 uniquement.

100.64.0.0/10 est-il un espace privé ? C’est un espace d’adresses partagées à usage spécial et non routable mondialement. Il est distinct des plages privées RFC 1918 utilisées dans les réseaux locaux ordinaires.

CGNAT est-il une fonction de sécurité ? Non. Son comportement entrant n’est pas une politique de sécurité. Vous avez toujours besoin de règles de pare-feu, d’authentification, de correctifs, de chiffrement et d’une exposition prudente.

Le point essentiel : Corriger le bord public manquant, pas seulement le routeur

Le serveur NAS ou de jeu d’ouverture peut avoir une règle locale correcte et toujours expirer car la connexion s’arrête à la limite du FAI. Plus de modifications du routeur ne corrigeront pas un chemin que le routeur ne reçoit jamais. Commencez par l’audience : utilisez un maillage pour l’accès privé de confiance, tandis que l’accès public nécessite un IPv4 public, un IPv6 fonctionnel, un tunnel géré ou un hôte contrôlé. Vérifiez d’abord les options du FAI, puis envisagez un VPS AlexHost uniquement lorsqu’une charge de travail hébergée ou un relais correspond à la conception.