Accès distant MikroTik derrière CGNAT

Résumé Le CGNAT (Carrier-Grade NAT) permet à un FAI de partager une seule adresse IPv4 publique entre de nombreux abonnés, ce qui préserve des adresses rares mais casse les connexions entrantes — la redirection de ports vers un routeur MikroTik situé derrière ne fonctionne donc tout simplement pas. Comme le routeur n’a pas d’adresse publique joignable, la solution fiable consiste à inverser le sens : faire en sorte que le routeur compose lui-même vers un point de rendez-vous que vous contrôlez. Ce guide explique ce qu’est le CGNAT, comment le détecter et comment gérer des routeurs MikroTik situés derrière à l’aide de tunnels sortants.

Qu’est-ce que le CGNAT ?

Le CGNAT est une deuxième couche de traduction d’adresses réseau exécutée à l’intérieur du réseau du FAI, qui mappe de nombreux clients sur un petit pool d’adresses IPv4 publiques partagées, attribuant généralement à chaque abonné une adresse privée de la plage opérateur 100.64.0.0/10 au lieu d’une véritable IP publique. Il existe parce que le monde a épuisé les blocs IPv4 libres il y a des années : plutôt que d’acheter des adresses de plus en plus chères, la plupart des fournisseurs sans fil fixe, mobile, fibre et satellite placent désormais les abonnés derrière une passerelle partagée. Votre MikroTik accède toujours à internet et peut initier des connexions sortantes normalement — mais du point de vue de l’internet public, votre routeur n’a pas d’adresse propre. (Carrier-grade NAT — Wikipedia)

Comment le CGNAT casse-t-il l’accès entrant à un MikroTik ?

La redirection de ports normale suppose que votre interface WAN détient une IP publique que le reste d’internet peut joindre. Sous CGNAT, cette hypothèse échoue deux fois. D’abord, votre adresse WAN est privée (souvent 100.64.x.x), donc un port redirigé sur votre MikroTik pointe vers une adresse que personne en dehors de l’opérateur ne peut router. Ensuite, la véritable IP publique se trouve sur le périphérique NAT maître du FAI, partagé avec des dizaines d’autres abonnés, et il ne vous redirigera pas un port entrant arbitraire — vous ne le contrôlez pas. (Open Port Checkers — Why port forwarding fails with CGNAT)

La conséquence pratique pour quiconque exploite un parc de routeurs est sévère : vous ne pouvez pas atteindre le MikroTik d’un client en Winbox, WebFig, SSH ou API depuis le bureau, car il n’existe aucun chemin entrant vers lui. Un nom d’hôte DNS dynamique n’aide pas non plus — il résoudrait vers l’IP partagée de l’opérateur, pas vers votre routeur. C’est le même mur que rencontrent les utilisateurs de Starlink, que nous traitons en détail dans notre étude de cas sur les changements d’IP de Starlink.

Comment savoir si un MikroTik est derrière un CGNAT ?

Vérifiez l’adresse sur l’interface WAN et comparez-la à l’IP publique que la connexion montre réellement à internet. Dans un terminal Winbox ou WebFig :

/ip address print

Si l’interface WAN détient une adresse comprise dans 100.64.0.0 – 100.127.255.255 (la plage partagée 100.64.0.0/10), 10.0.0.0/8 ou une autre plage privée RFC1918, vous êtes presque certainement derrière un CGNAT. Confirmez-le en comparant cette adresse avec ce que rapporte un service externe « what is my IP » : si elles diffèrent, un NAT opérateur se trouve entre vous et internet. Un traceroute montrant un ou plusieurs sauts privés avant le premier saut public est un autre signal fort. (oneuptime — How to detect if you are behind CGNAT)

Comment gérer des routeurs MikroTik derrière un CGNAT ?

La solution durable consiste à cesser d’essayer de se connecter vers l’intérieur et, à la place, à laisser le routeur se connecter vers l’extérieur à un point de rendez-vous doté d’une adresse publique stable. Comme la connexion sortante est initiée depuis derrière le CGNAT, le NAT de l’opérateur l’autorise volontiers — de la même façon que votre navigateur atteint n’importe quel site web. Une fois ce tunnel établi, vous atteignez le routeur en retour à travers lui. Il existe quatre manières courantes de le construire, chacune documentée dans son propre guide :

Un VPN auto-hébergé vers un VPS est l’approche classique : un VPS Linux bon marché doté d’une IP publique sert de point de rendez-vous, et chaque MikroTik s’y connecte. WireGuard est la référence moderne — rapide, peu gourmand en CPU et tolérant aux changements d’adresse qui accompagnent le CGNAT et les IP dynamiques. Le guide plus large sur la gestion basée sur un VPS couvre la même idée avec d’autres types de tunnels.

Un VPN maillé géré supprime l’essentiel de la plomberie manuelle. Tailscale et ZeroTier fournissent tous deux un plan de contrôle qui prend en charge la traversée du NAT et la distribution des clés à votre place, si bien qu’un routeur derrière un CGNAT rejoint le réseau avec presque aucune configuration par appareil.

Une plateforme TR-069 / ACS est l’option standard des opérateurs lorsque vous travaillez à grande échelle : le CPE ouvre une session sortante vers un serveur d’auto-configuration, qui pousse ensuite configuration et firmware. Elle est conçue spécialement pour gérer des appareils d’abonnés vivant derrière le NAT opérateur.

Un cloud de gestion dédié combine l’idée du tunnel sortant avec la supervision et le contrôle d’accès en un seul endroit, ce qui est le modèle utilisé par le NATCloud de MKController.

Conseils

• L’IPv6 contourne souvent entièrement le CGNAT. Si votre FAI attribue un préfixe IPv6 routable, vous pourrez peut-être atteindre le routeur via IPv6 même lorsque l’IPv4 est piégé derrière le NAT opérateur — mais seulement si chaque saut de votre chemin de gestion possède aussi l’IPv6.
• Définissez toujours un keepalive sur les tunnels sortants (par exemple persistent-keepalive=25 avec WireGuard) afin que l’opérateur ne supprime pas silencieusement le mappage NAT inactif.
• Certains FAI vendent une adresse IPv4 statique ou publique en option payante. Pour un seul site critique, cela peut être plus simple qu’un tunnel ; pour un parc, cela ne passe pas à l’échelle côté coût.
• N’exposez jamais Winbox, WebFig ou SSH directement sur internet comme « contournement ». Derrière un CGNAT cela ne fonctionnerait de toute façon pas, et sur une véritable IP publique c’est une invitation permanente pour les attaquants.

FAQ

Un service DNS dynamique règle-t-il le CGNAT ? Non. Le DNS dynamique met seulement à jour un nom d’hôte pour pointer vers l’IP publique dont vous disposez. Derrière un CGNAT, cette IP publique appartient à l’opérateur et est partagée, donc le nom d’hôte ne peut pas atteindre votre routeur.

Le CGNAT est-il identique au NAT de mon propre routeur ? Non. Le NAT de votre routeur traduit votre LAN privé vers votre adresse WAN, et vous contrôlez ses règles de redirection de ports. Le CGNAT ajoute un second NAT à l’intérieur du FAI que vous ne contrôlez pas, et c’est pourquoi la redirection entrante casse.

Puis-je simplement demander à mon FAI de le désactiver ? Parfois. De nombreux fournisseurs proposent une adresse IPv4 publique ou statique moyennant des frais ou sur demande. La disponibilité et le prix varient fortement selon l’opérateur et la région.

Passez à l’étape suivante

Construire votre propre tunnel pour un routeur est simple. Le faire sur des dizaines ou des centaines de MikroTik — chacun derrière un opérateur CGNAT différent, avec des clés à faire tourner et des configurations VPS à surveiller — c’est là que le coût opérationnel s’accumule.

Le NATCloud de MKController est conçu exactement pour cela. Chaque MikroTik se connecte via un tunnel sortant vers le plan de contrôle, sans IP publique, sans redirection de ports et sans modifications VPS par appareil. Vous obtenez une supervision centralisée et un accès distant sécurisé à chaque routeur, même ceux enfouis tout au fond derrière le NAT opérateur.

Commencez votre essai gratuit de MKController