CGNAT et UDP : comment le NAT opérateur affecte le trafic en temps réel
Le NAT opérateur (CGNAT) permet à un opérateur de placer des milliers d'abonnés derrière un petit pool d'adresses IPv4 publiques, et presque toutes les IP mobiles se trouvent derrière lui. Pour l'UDP, cela compte : les correspondances vivent sur des minuteurs d'inactivité, les connexions entrantes échouent, et une courte pause peut changer votre port public en plein appel.
Qu'est-ce que le NAT opérateur (CGNAT)
Qu'est-ce que le CGNAT ? C'est une traduction d'adresses gérée par le FAI ou l'opérateur mobile plutôt que par votre routeur domestique. Il partage chaque adresse IPv4 publique entre de nombreux clients et leur attribue des adissues depuis 100.64.0.0/10, l'espace d'adressage partagé réservé à cet usage par la RFC 6598.
L'opérateur associe l'adresse et le port de chaque abonné à une IP publique partagée
- NAT domestique : un foyer derrière une IP publique, avec redirection de ports sous votre contrôle.
- CGNAT : de nombreux abonnés derrière une IP publique, sans redirection de ports pour personne.
- NAT444 : la configuration « large bande » où votre routeur traduit une fois et l'opérateur traduit à nouveau, à travers trois domaines d'adressage IPv4.
Les téléphones n'ont généralement pas de routeur intermédiaire, donc la passerelle de l'opérateur traduit leur adresse une seule fois.
Pourquoi les réseaux mobiles dépendent du CGNAT
Les opérateurs mobiles ont adopté le Carrier Grade NAT parce que les adresses IPv4 ont été épuisées il y a longtemps et que les téléphones sont bien plus nombreux que les adresses possédées par un opérateur. Une IP publique peut servir des milliers d'abonnés, à condition que chaque connexion reçoive son propre port.
La plupart des personnes qui tapent « qu'est-ce que le CGNAT » dans une barre de recherche demandent en réalité une question de rareté. De nombreux opérateurs donnent déjà l'IPv6 aux téléphones, mais tout ce qui nécessite encore l'IPv4 passe par le traducteur.
Ce qui change pour une connexion sortante
Derrière un CGNAT, chaque connexion sortante part d'une adresse partagée et d'un port que l'opérateur choisit. Les réponses reviennent seulement tant que la passerelle se souvient de cette paire, et rien de l'extérieur ne peut initier une connexion vers vous.
| Ce qui change | Pourquoi c'est important |
|---|---|
| IP publique partagée | Les serveurs distants voient de nombreux utilisateurs derrière une même IP partagée |
| Correspondance adresse + port | L'attribution de port de l'opérateur, et non votre appareil, identifie la session |
| État de session | Les correspondances sont temporaires et expirent |
| Aucun chemin entrant | Les connexions non sollicitées venant de l'extérieur sont bloquées |
Les problèmes CGNAT UDP commencent ici : le TCP a des signaux explicites d'ouverture et de fermeture, l'UDP n'en a pas.
Comment le CGNAT gère les correspondances UDP
Une correspondance UDP CGNAT est créée par votre premier paquet sortant et supprimée après une période de silence. Sans négociation à suivre, le délai d'expiration du NAT décide seul de sa durée de vie.
Le trafic maintient la correspondance active ; un long silence peut changer le port public
Les passerelles bien conçues utilisent une correspondance indépendante du point de terminaison (EIM) : la même adresse et le même port internes conservent la même adresse et le même port publics pour chaque destination. Cela aide les applications pair-à-pair, car un port appris auprès d'un serveur fonctionne avec les autres.
« Un minuteur de correspondance NAT UDP NE DOIT PAS expirer en moins de deux minutes, sauf si REQ-5a s'applique. »
— RFC 4787, meilleure pratique actuelle de l'IETF pour le comportement NAT UDP
Tous les réseaux ne la suivent pas, donc les applications ne devraient pas compter sur ce plancher de deux minutes.
Pourquoi les connexions entrantes et la redirection de ports ne fonctionnent pas
Les connexions entrantes échouent parce que la passerelle ne transmet que les paquets correspondant à une correspondance créée par votre appareil. La redirection de ports nécessite un port public réservé pour vous, et sur une adresse partagée, chaque port appartient au pool de l'opérateur.
- ✅ Les requêtes sortantes et leurs réponses
- ✅ Les sessions établies qui continuent d'envoyer du trafic
- ❌ Les tentatives de connexion entrante non sollicitées
- ❌ La redirection manuelle de ports sur une adresse partagée
Le Port Control Protocol (PCP) permet à un appareil de demander une correspondance à l'opérateur, mais peu d'opérateurs l'exposent aux abonnés. Les applications qui doivent accepter des connexions s'appuient généralement sur un serveur relais externe, auquel l'appareil se connecte d'abord.
Comment le CGNAT affecte le trafic en temps réel
Les applications temps réel rencontrent d'abord les limites UDP du CGNAT, car elles ont besoin d'une livraison bidirectionnelle stable. Une correspondance perdue se manifeste immédiatement par un audio coupé, une vidéo figée ou une désynchronisation.
| Type de trafic | Impact CGNAT | Ce qui aide |
|---|---|---|
| VoIP | Audio à sens unique ou manquant après une re-correspondance | Keepalives plus courts que le délai NAT |
| Appels vidéo | Gels pendant la renégociation du chemin | Redémarrage ICE avec repli TURN |
| Jeux en ligne | Pics de latence et déconnexions | Courtes périodes d'inactivité, reconnexions rapides |
| IPTV sur UDP | Flux bloqué après une pause | Keepalives client ou livraison via HTTP |
| WebRTC | Les liens pairs directs échouent sur les NAT stricts | Relais TURN quand les chemins directs échouent |
Réputation des IP partagées et limites de débit
Une adresse partagée d'opérateur porte l'historique combiné de tous ceux qui se trouvent derrière elle. Quand un abonné se comporte mal, les limites de débit et les vérifications peuvent toucher tous les autres sur cette adresse.
Les grandes plateformes savent quelles plages appartiennent aux opérateurs et fixent souvent des seuils plus souples, car bloquer une adresse verrouillerait de nombreux utilisateurs légitimes. Les passerelles chargées subissent malgré tout des captchas et des ralentissements supplémentaires, effet direct du Carrier Grade NAT. C'est pourquoi la réputation des IP sur les pools mobiles change rapidement.
Vérifier si vous êtes derrière un CGNAT, étape par étape
Comparez l'adresse WAN rapportée par votre routeur ou téléphone avec l'IP publique vue par un site web. Si elles diffèrent et que l'adresse WAN se trouve dans une plage partagée ou privée, votre opérateur la traduit.
- Trouvez l'adresse WAN. En large bande, ouvrez la page d'admin du routeur et notez son IP WAN ou Internet. Sur un téléphone, vérifiez l'IP cellulaire dans les paramètres réseau.
- Trouvez l'IP publique. Ouvrez n'importe quelle page « quelle est mon IP » sur la même connexion.
- Comparez-les. Des adresses identiques signifient l'absence de NAT opérateur sur ce lien.
- Vérifiez la plage. Une adresse WAN dans 100.64.0.0/10 indique un CGNAT ; une adresse 10.x.x.x sur mobile l'indique généralement aussi.
Si « qu'est-ce que le CGNAT » vous a mené ici après une redirection de port échouée, ces étapes tranchent la question en quelques minutes.
| À vérifier | Résultat attendu derrière un CGNAT |
|---|---|
| IP WAN vs IP publique | Adresses différentes |
| Plage de l'IP WAN | 100.64.0.0/10, ou une plage privée sur mobile |
| Test entrant vers l'IP publique | Échoue, mais un pare-feu peut aussi en être la cause |
Comparer l'adresse Wi-Fi locale d'un appareil avec l'IP publique ne prouve rien, car le NAT domestique seul les fait déjà différer.
Comment les proxys mobiles fonctionnent au-dessus du CGNAT
Un proxy mobile CGNAT envoie le trafic via une véritable passerelle d'opérateur, il hérite donc du comportement NAT de cet opérateur. Les sessions collantes gardent une IP de sortie pendant une durée définie ; les sessions rotatives la changent selon un calendrier ou par requête.
Même une session collante peut changer en cours de tâche : l'opérateur rééquilibre ses passerelles, l'appareil se reconnecte, ou une correspondance inactive expire. Un proxy mobile convient aux vérifications qui doivent venir d'IP d'opérateur. Pour un travail lourd en UDP, notez que de nombreux fournisseurs, Insocks inclus, n'offrent pas l'UDP sur les pools mobiles.
Comment garder des sessions stables sur des IP mobiles
Des sessions UDP CGNAT stables sur des IP mobiles dépendent du rythme du trafic et de la logique de reconnexion. Envoyez de petits paquets avant l'expiration de la correspondance et laissez l'application récupérer quand le port public change.
- ✅ Gardez l'intervalle de keepalive sous le délai NAT le plus court prévu ; ICE, utilisé par WebRTC, est réglé par défaut à 15 secondes.
- ✅ Détectez une nouvelle IP ou un nouveau port public et réenregistrez-vous au lieu d'attendre l'ancien.
- ✅ Conception de sessions courtes et résumables.
- ❌ Attendre un trafic entrant qui n'arrive jamais.
- ❌ coder en dur une IP externe dans des listes blanches ou la logique applicative.
💡 Journalisez l'IP et le port publics à chaque reconnexion. Ce schéma révèle le vrai délai d'expiration de l'opérateur sur lequel vous êtes.
Exemple : un softphone en mode silencieux
Une équipe de télésanté voyait des appels mobiles devenir silencieux après environ une minute en mode muet. Les journaux montraient le port public changer pendant la pause, car un client muet n'envoyait aucun paquet audio. Un keepalive de 15 secondes et une réenregistrement lors du changement de port ont corrigé le problème sans toucher au réseau.
Erreurs courantes avec le CGNAT et les IP mobiles
Les équipes nouvelles sur une configuration de proxy mobile CGNAT traitent souvent une IP mobile comme l'adresse dédiée d'un serveur. Les correctifs relèvent de la logique applicative, pas du réseau.
| Erreur | Impact | Correctif |
|---|---|---|
| ❌ S'attendre à des connexions entrantes | Les requêtes n'atteignent jamais l'appareil | Concevoir des flux sortants uniquement ou utiliser un relais |
| ❌ Longues pauses dans une session UDP | La correspondance expire en pleine session | Envoyer des keepalives à intervalle fixe |
| ❌ Lier la logique à une IP externe | Les sessions se cassent lors d'une réattribution | Gérer les changements d'IP et de port dans le code |
Quand les IP mobiles conviennent et quand FAI ou datacenter est préférable
Choisissez des IP mobiles quand un test doit montrer ce que voient les utilisateurs d'opérateurs. Choisissez des IP FAI ou datacenter quand vous avez besoin de longues sessions, d'un débit élevé ou de l'UDP, car les sorties mobiles se trouvent toujours derrière le Carrier Grade NAT.
| Tâche | Meilleur type d'IP | Pourquoi |
|---|---|---|
| Vérification publicitaire mobile | Mobile | Montre les publicités servies aux utilisateurs d'opérateurs |
| QA de sites et d'apps mobiles | Mobile | Reproduit les conditions réelles du réseau opérateur |
| Collecte publique de données à grande échelle | Datacenter ou FAI | Rapide, stable et moins cher par requête |
| Tests VoIP et temps réel | FAI | Latence prévisible, moins de re-correspondances, support UDP |
| Longues sessions de surveillance | FAI statique | Une seule adresse pendant des jours |
Pour les longues sessions, comparez les offres proxy FAI et proxy statique.
Choisir un proxy qui gère le trafic temps réel
Pour les charges UDP CGNAT, la persistance de session et le support UDP comptent plus que la vitesse annoncée. Vérifiez la durée de conservation des sessions, les pools qui portent l'UDP et la clarté de la documentation des limites.
| Fonctionnalité | Avantage |
|---|---|
| Contrôle de session collante | Une seule sortie pendant toute la durée du test |
| SOCKS5 avec support UDP | Le trafic VoIP et jeux passe par le proxy |
| Pools FAI et statiques | Moins de re-correspondances que les passerelles mobiles |
| Couverture des réseaux opérateurs | Vérifications réalistes côté opérateur |
| Démo gratuite | Stabilité mesurée avant l'achat |
👉 Essayez les proxys de démo, inscrivez-vous pour un accès complet, ou achetez un proxy UDP une fois vos tests validés.
Points essentiels
Le comportement UDP du CGNAT explique la plupart des frictions que rencontrent les applications temps réel sur les réseaux cellulaires. Voici la réponse courte à « qu'est-ce que le CGNAT » et pourquoi cela compte.
- Le CGNAT partage les adresses IPv4 publiques entre de nombreux abonnés via la correspondance adresse et port.
- Les correspondances UDP vivent sur des minuteurs d'inactivité, donc les pauses peuvent changer votre port public.
- Les connexions entrantes et la redirection de ports ne fonctionnent pas sur les adresses partagées d'opérateur.
- Les keepalives et la logique de reconnexion maintiennent les sessions temps réel stables.
- Les proxys mobiles héritent du NAT opérateur ; les pools FAI conviennent aux longues sessions et à l'UDP.
Questions fréquemment posées
Qu'est-ce que le NAT opérateur en termes simples ?
C'est un NAT géré par votre opérateur, permettant à de nombreux clients de partager une adresse IPv4 publique.
Le CGNAT bloque-t-il le trafic UDP ?
Non, mais il supprime les correspondances UDP inactives, donc les sessions silencieuses peuvent se rompre.
Pourquoi les connexions entrantes échouent-elles sur les IP mobiles ?
La passerelle ne transmet que le trafic des connexions initiées par votre appareil.
Comment savoir si ma connexion utilise le CGNAT ?
Comparez l'IP WAN de votre routeur ou téléphone avec votre IP publique ; une différence plus une adresse WAN en 100.64.0.0/10 ou privée indique le CGNAT.
Les proxys mobiles fonctionnent-ils derrière le CGNAT ?
Oui, ils sortent via les passerelles d'opérateurs et suivent les mêmes règles NAT.
Le CGNAT affecte-t-il la latence ?
Généralement légèrement, mais le trafic peut emprunter une route plus longue via des passerelles centralisées d'opérateur.
En utilisant des proxys, vous confirmez que vous les utilisez conformément au droit américain en vigueur. Insocks est conçu pour un usage légal aux États-Unis. D'autres guides se trouvent dans le blog Insocks.