accès distant CGNAT : pourquoi le port forwarding a cessé de fonctionner

Le port forwarding consistait à ouvrir un port sur le routeur, mapper le TCP 3389 ou un port personnalisé, et vous pouviez atteindre la machine depuis n'importe où. Aujourd'hui, beaucoup de ces machines sont injoignables parce que l'opérateur place les clients derrière du CGNAT. Si vous cherchez "remote access cgnat", vous voulez savoir : pourquoi le port forwarding a cessé de fonctionner, comment le détecter, et quelles sont les solutions pratiques et opérationnelles qui fonctionnent réellement à grande échelle ?

Qu'est‑ce que le CGNAT et pourquoi les FAI l'utilisent

CGNAT (Carrier-Grade NAT) est une mesure d'échelle adoptée par les FAI pour étirer des adresses IPv4 rares. Plutôt que d'attribuer à chaque client une IPv4 publique unique, le FAI donne une adresse RFC 6598 (100.64.0.0/10) ou une autre plage privée et partage une IP publique entre plusieurs abonnés. Le FAI effectue le NAT au point d'agrégation — d'où le terme « carrier‑grade ».

Deux faits en découlent immédiatement : d'une part, les appareils derrière le CGNAT n'ont plus d'adresse IPv4 publique routable vers laquelle pointer. D'autre part, le FAI contrôle les mappages NAT et les politiques : il décide quels ports sont mappés, si les connexions entrantes sont autorisées, et la stabilité des mappages éphémères. Sur les réseaux mobiles, la plupart des abonnés sont derrière du CGNAT ; certains FAI fixes l'utilisent aussi pour éviter d'allouer plus d'espace IPv4.

Pourquoi le port forwarding n'est plus une option

• Pas d'IPv4 publique = pas de routage entrant. Si l'IP WAN de votre routeur est dans 100.64.0.0/10 ou dans une plage privée comme 10.x.x.x, Internet ne peut pas ouvrir une connexion directement vers votre mappage de port local.
• Double NAT et mappages éphémères. Même si le CPE (routeur client) supporte le port forwarding, le NAT de l'opérateur se situe en amont et a généralement des mappages de ports transitoires que vous ne pouvez pas contrôler.
• NAT symétrique et règles de politique. Beaucoup de NAT opérateurs sont symétriques : le mappage dépend de la destination, ce qui casse les stratégies de hole‑punching et rend le pair‑à‑pair peu fiable.
• Sécurité et politiques légales des opérateurs. Les FAI bloquent souvent intentionnellement les connexions entrantes non sollicitées pour réduire les abus et se conformer à des obligations réglementaires.
• Liens mobiles et transitoires. Les clients cellulaires changent d'IP fréquemment ; même si vous aviez un mappage, il ne survivra pas à un handover LTE ou à un redémarrage du modem.

Comment détecter le CGNAT (vérifications pratiques)

Avant de modifier votre architecture, confirmez la présence de CGNAT. Voici des contrôles rapides et déterministes que vous pouvez exécuter sur la machine cible ou en demandant à l'utilisateur.

Windows: ipconfig /all
Linux/macOS: ip addr show
Check public IP: curl -s https://ifconfig.co
Check router WAN: look at the router's "WAN" or "Internet" address in its admin UI
If the router shows 100.64.x.x or a private 10.x/192.168.x.x while curl shows a different public IP, you're behind CGNAT.

Un autre indice utile est traceroute : si le premier saut public est un équipement NAT de l'opérateur avec une adresse privée ou si traceroute montre une plage privée avant l'IP publique, c'est révélateur. De même, si les règles de port forwarding que vous avez créées sur le CPE n'ont aucun effet depuis l'Internet public, le CGNAT est la cause probable.

Ce qui a remplacé le port forwarding : alternatives en conditions réelles

Le port forwarding est une solution centrée sur le routeur local. Quand l'adresse publique disparaît, il faut passer à l'un des modèles généraux suivants. Chacun a des compromis en fiabilité, latence, visibilité sécurité et coût opérationnel.

1. Pair‑à‑pair avec hole punching (STUN/ICE/WebRTC) : Fonctionne bien lorsque les deux points sont derrière des NATs qui autorisent UDP ou ont des mappages prévisibles. Beaucoup d'outils modernes utilisent ICE pour tenter des chemins directs. Avantages : faible latence quand ça se connecte ; inconvénients : échoue avec les NATs symétriques des opérateurs et nécessite une solution de secours.
2. Relays / TURN / relais gérés : Quand le hole punching échoue, le trafic est proxifié via un relais. Les relays de type TURN garantissent la connectivité au prix d'un saut et d'une consommation de bande passante supplémentaires. C'est le remplacement pragmatique du port forwarding dans le monde réel, car cela fonctionne indépendamment du NAT client.
3. VPN (site ou appareil) : Un VPN peut fournir une adresse routable dans un maillage (Tailscale, ZeroTier, IPsec site‑à‑site classique). Avantages : routage stable et contrôles d'accès solides ; inconvénients : nécessite l'installation d'un client ou un équipement passerelle et peut complexifier le routage pour de grandes flottes.
4. IPv6 : L'IPv6 native restaure l'ancien modèle car chaque appareil peut avoir une adresse globale routable. Mais les FAI ne fournissent pas toujours IPv6 de manière cohérente, et exploiter IPv6 en toute sécurité à grande échelle demande une posture firewall/monitoring différente.
5. Tunnels inverses (SSH, autossh) : Simple et efficace pour quelques machines : la cible ouvre une connexion sortante vers un serveur que vous contrôlez, créant un chemin entrant exploitable. Intensif en opération pour des flottes du fait de la gestion des clés et de la fiabilité à grande échelle.

En pratique, la plupart des produits commerciaux d'accès distant combinent : tenter le direct (STUN/UDP) d'abord, puis basculer sur un relais. Le chemin via relais est la seule option qui remplace de manière fiable le port forwarding face à la variété des NATs opérateurs, des portails captifs et des liens mobiles que vous rencontrerez.

À quoi s'attendre d'un relais et les compromis de sécurité

Beaucoup supposent que les relays sont magiquement chiffrés de bout en bout de façon à empêcher l'opérateur du relais de voir le contenu des sessions. Ce n'est pas la vérité implicite pour la plupart des systèmes de bureau à distance. Le modèle technique réel est généralement TLS avec certificats par appareil : lorsqu'une session bascule sur un relais, TLS peut être terminé au niveau du relais, plaçant l'opérateur d'infrastructure en position d'accéder ou d'inspecter le trafic de session s'il le souhaite. Une connexion P2P directe qui n'utilise jamais de relais est chiffrée de bout en bout entre les deux points, mais on ne peut pas s'y fier dans un monde CGNAT.

Conséquence opérationnelle : choisissez un opérateur de relais de confiance, exploitez des relays dans plusieurs régions pour faible latence et basculement, et assurez‑vous que le relais offre des journaux d'audit et des contrôles d'accès vérifiables. Si une réglementation interdit l'accès tiers au trafic des sessions, vous aurez besoin d'un relais auto‑hébergé sous votre contrôle (voir plus bas).

La voie recommandée par Tenvo : relais géré par défaut

À grande échelle, le choix le moins coûteux et le moins risqué est un relais géré avec un client moderne qui supporte chemins directs et relais. Tenvo fournit des clients natifs pour Windows, macOS et Linux, un client navigateur en bêta publique, et un relais géré multi‑régions prêt à l'emploi. Tarifs : Free $0 / Lite $2.99/mo / Pro $7.99/mo. Le relais géré supprime la charge opérationnelle de patching, renouvellement de certificats, basculement multi‑régions et garde des clés — tâches que de nombreuses équipes sous‑estiment lorsqu'elles considèrent l'"auto‑hébergement" comme une option gratuite.

Détail important : Tenvo utilise TLS avec un certificat par appareil pour les sessions. Cela signifie que les connexions pair à pair sont chiffrées de bout en bout entre les deux appareils, mais les sessions qui utilisent le relais géré verront TLS terminé au relais. Pour les équipes qui ne peuvent accepter que l'opérateur du relais soit en position de déchiffrer, l'auto‑hébergement est la seule voie correcte — mais elle a des coûts réels.

Pour une vue technique approfondie de la connexion sans port forwarding, voir Remote Desktop Without Port Forwarding Explained.

Quand l'auto‑hébergement d'un relais est le bon choix

Auto‑héberger un relais n'a de sens que lorsqu'une exigence écrite l'impose : une obligation de conformité qui interdit l'infrastructure tierce, un réseau isolé sans egress Internet, ou une règle de résidence des données imposée. Si vous choisissez l'auto‑hébergement pour la commodité ou le coût perçu « gratuit », vous paierez en heures et en risque :

• Mises à jour 24/7 et réponse aux CVE pour le logiciel relais et l'OS
• Émission et renouvellement de certificats (letsencrypt ou PKI d'entreprise), et stockage sécurisé des clés
• Haute disponibilité et ingénierie de basculement multi‑régions pour égaler les offres gérées
• Télémetrie opérationnelle, journalisation et rétention pour les audits

Si votre exigence vous oblige à auto‑héberger, le guide canonique est Self-Hosted Remote Desktop: Why, How, and What Breaks, qui parcourt la checklist et les pièges.

Checklist de migration pratique : passer du port forwarding à un accès fiable

• Inventaire des appareils : identifiez les endpoints qui dépendent du port forwarding et s'ils sont derrière du CGNAT. Suivez l'OS, la version du client et la disponibilité d'agents sans surveillance.
• Détecter le CGNAT : exécutez les vérifications ci‑dessus sur des appareils représentatifs. Enregistrez des exemples pour pouvoir contacter le FAI si nécessaire.
• Choisir le modèle de connectivité : relais géré pour la plupart des flottes ; VPN pour les réseaux qui requièrent un maillage routé ; IPv6 là où les FAI et la posture de sécurité le permettent.
• Mettre en place des agents persistants : remplacez les sessions RDP/SSH éphémères par un petit agent persistant qui initie des connexions sortantes vers le relais ou le maillage. Cela réduit le travail de maintenance.
• Planifier le monitoring : ajoutez des SLOs de disponibilité des sessions, des vérifications de santé des relays et des alertes de coût bande passante (les relays consomment de l'egress que vous devez budgéter).
• Renforcer l'accès : exiger MFA, attestation des appareils quand possible, et journaux d'audit centralisés pour l'enregistrement des sessions et les forensics post‑incident.
• Tester le basculement et la récupération : simulez des pannes de relais et assurez‑vous qu'une région secondaire ou un chemin VPN est disponible.

Pour un guide pas‑à‑pas rapide pour lancer un agent d'accès distant, voir How to Set Up Remote Access in 60 Seconds. Pour les mécanismes sous‑jacents de l'établissement des connexions, lisez How Remote Desktop Access Works: A Simple Explanation.

Chiffres opérationnels et quelques attentes

Attendez‑vous à ce que le trafic via relais ajoute de la latence et un coût de bande passante. Un relais régional bien placé devrait ajouter 20–80 ms aller‑retour comparé à un saut LAN lorsque les endpoints sont sur le même continent ; les sessions inter‑continentales seront dominées par la géographie quoi qu'il en soit. La bande passante se facture : pour des sessions vidéo/graphismes, comptez 1–5 Mbps comme base pour des tâches d'administration typiques ; les sessions à haute fréquence d'images ou le gaming peuvent facilement atteindre 20–50 Mbps. Ces chiffres permettent de décider si un VPN local ou une route IPv6 est préférable.

TL;DR recommandation

Si vous traitez le problème "remote access cgnat" sur le terrain, cessez de compter sur le port forwarding comme solution fiable. Détectez le CGNAT, puis choisissez un modèle : relais géré pour la plupart des équipes, VPN/maillage pour un accès routé et isolé, IPv6 quand le FAI et la posture de sécurité le permettent, et auto‑hébergement seulement lorsqu'une exigence écrite interdit les relays tiers. L'option relais géré réduit la charge opérationnelle — l'offre Tenvo est multi‑régions, supporte des clients natifs et un client navigateur en bêta publique, et propose des niveaux Free/Lite/Pro (Free $0 / Lite $2.99/mo / Pro $7.99/mo).

Enfin, souvenez‑vous du compromis de sécurité : les relays peuvent terminer TLS. Si votre politique autorise un opérateur de confiance à exploiter des relays avec contrôles d'audit, utilisez l'option gérée. Sinon, prévoyez le budget et les ressources pour exploiter correctement vos propres relays.

Prêt à arrêter de courir après le port forwarding et à obtenir un accès distant fiable qui gère le CGNAT ? Téléchargez le client Tenvo et testez un chemin relais géré sur votre parc : Obtenir Tenvo.