NAT, translations et publication de services

La traduction d’adresses, ou NAT (Network Address Translation), est née d’une pénurie : les adresses IPv4 (Internet Protocol version 4) publiques manquaient, alors on a caché des réseaux entiers derrière une seule. Le mécanisme est devenu si courant qu’on le prend pour une protection, ce qu’il n’est pas. Cette fiche explique la traduction sortante, la publication de services, la traversée de NAT par les applications temps réel, puis les limites : protocoles cassés, traçabilité difficile derrière un NAT d’opérateur, et faux sentiment de sécurité.

→ Lire l’explication complète de la marmotte

Traduire pour sortir

SNAT et PAT

Le SNAT (Source NAT) remplace l’adresse source d’un paquet sortant par une autre, en général l’adresse publique de l’équipement de sortie. Si une seule adresse publique doit servir des centaines de machines, il faut aussi traduire le port source : c’est le PAT (Port Address Translation), appelé NAPT (Network Address Port Translation) dans les RFC et « masquerade » sous Linux quand l’adresse publique est prise dynamiquement sur l’interface. Le NAT IPv4 « traditionnel » est décrit par le RFC 3022 ; les adresses privées qu’il permet de cacher sont celles du RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), présentées dans IPv4, CIDR et plans d’adressage.

La table de translation

Chaque traduction est mémorisée dans une table de translation qui associe le couple interne (adresse, port) au couple externe. Prenons un poste 192.168.10.23 qui ouvre une connexion HTTPS (HyperText Transfer Protocol Secure) vers 198.51.100.7, derrière un routeur d’adresse publique 203.0.113.5 :

Sens	Source	Destination
Sortant, avant traduction	192.168.10.23:51544	198.51.100.7:443
Sortant, après traduction	203.0.113.5:51544	198.51.100.7:443
Retour, avant traduction	198.51.100.7:443	203.0.113.5:51544
Retour, après traduction	198.51.100.7:443	192.168.10.23:51544

Le port source est un port éphémère, choisi par le système du poste dans une plage dynamique (sous Linux, 32768 à 60999 par défaut ; l’IANA, Internet Assigned Numbers Authority, recommande 49152 à 65535). Le routeur conserve ce port s’il est libre côté public, et en choisit un autre si deux postes ont pris le même. Avec 65 535 ports par adresse et par protocole, une adresse publique peut porter quelques dizaines de milliers de connexions simultanées vers une même destination : beaucoup pour un foyer, peu pour un NAT qui sert des milliers d’abonnés. Sous Linux, la table est celle du suivi de connexions :

conntrack -L -p tcp --dport 443
# tcp 6 431999 ESTABLISHED src=192.168.10.23 dst=198.51.100.7 sport=51544 dport=443
#     src=198.51.100.7 dst=203.0.113.5 sport=443 dport=51544 [ASSURED]

La première moitié décrit le paquet tel qu’émis, la seconde la réponse attendue : la différence entre les deux révèle la traduction.

Domestique, entreprise et nuage

À la maison, la box fait du PAT vers une adresse publique unique. En entreprise, un pare-feu traduit souvent vers un petit bloc d’adresses publiques, avec parfois une adresse de sortie distincte par zone, ce qui aide à identifier l’origine d’un flux. Dans le nuage, une NAT gateway gérée permet à des machines privées d’un réseau virtuel de sortir vers Internet sans être joignables depuis lui ; elle se facture souvent au volume, ce qui transforme une mise à jour massive de serveurs en ligne remarquée sur la facture (voir Réseau cloud et VPC).

Publier et traverser

DNAT et port forwarding

Le DNAT (Destination NAT) fait l’inverse : il réécrit l’adresse de destination d’un paquet entrant pour l’envoyer vers une machine interne. Le port forwarding (redirection de port) en est la forme la plus courante : « tout ce qui arrive sur le port 443 de l’adresse publique part vers 192.168.20.10:443 ». Voici les deux sens avec nftables :

table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    # Publication : HTTPS entrant vers le serveur web interne
    iifname "wan" tcp dport 443 dnat to 192.168.20.10:443
  }
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    # Sortie : les postes prennent l'adresse publique
    oifname "wan" ip saddr 192.168.10.0/24 snat to 203.0.113.5
  }
}

Ces règles traduisent ; elles n’autorisent rien. Il faut une règle de filtrage dans la chaîne forward pour laisser passer le flux publié, et c’est elle qui décide qui peut joindre le serveur (voir Filtrage, segmentation, NAC et Zero Trust). Sur beaucoup de box et de pare-feu grand public, créer une redirection ouvre aussi le filtrage, sans le dire : une règle ajoutée pour un test de deux heures publie alors une interface d’administration pour plusieurs années. Les box qui acceptent l’UPnP (Universal Plug and Play) laissent même les applications internes créer leurs propres redirections, ce qui est commode et rarement souhaité.

Reverse proxy, répartiteur de charge et NAT

Un reverse proxy termine la connexion du client, lit la requête applicative, puis ouvre sa propre connexion vers le serveur interne. Il peut donc filtrer des chemins, ajouter de l’authentification, terminer TLS (Transport Layer Security), journaliser chaque requête. Un répartiteur de charge (load balancer) distribue les connexions entre plusieurs serveurs ; il travaille soit au niveau 4, en traduisant adresses et ports comme un DNAT évolué, soit au niveau 7, comme un reverse proxy. Le DNAT, lui, ne voit que des en-têtes IP et TCP (Transmission Control Protocol) : le serveur interne reçoit la connexion du client lui-même, avec son adresse d’origine, et toute la protection repose sur lui et sur le filtrage. Le reverse proxy masque l’adresse du client au serveur, d’où l’en-tête X-Forwarded-For ou le protocole PROXY pour la transmettre.

STUN, TURN et ICE

Deux téléphones derrière deux NAT ne peuvent pas s’appeler directement : aucun ne connaît l’adresse publique de l’autre, et aucun NAT n’a d’entrée de table pour un flux qu’il n’a pas vu sortir. La NAT traversal résout ce problème en trois outils. STUN (Session Traversal Utilities for NAT, RFC 8489) permet à une machine de demander à un serveur externe quelle adresse et quel port publics il voit pour elle. TURN (Traversal Using Relays around NAT, RFC 8656) fournit un relais qui fait transiter le flux quand aucune connexion directe n’est possible, au prix de bande passante et de latence. ICE (Interactive Connectivity Establishment, RFC 8445) orchestre l’ensemble : chaque pair rassemble ses adresses candidates (locale, publique vue par STUN, relais TURN), les échange avec l’autre, teste les paires et retient la meilleure qui fonctionne. WebRTC (Web Real-Time Communication) et la plupart des applications de visioconférence reposent sur ce trio (voir VoIP, signalisation et communications).

Limites et sécurité

Pourquoi le NAT n’est pas une politique de sécurité

Le NAT bloque par accident une partie du trafic entrant : sans entrée dans la table, un paquet non sollicité ne sait pas où aller. Cet effet de bord a valu au NAT une réputation de protection qu’il ne mérite pas. Il ne décrit aucune politique : rien ne dit quels flux sortants sont permis, et un poste compromis qui ouvre une connexion sortante vers son serveur de commande la voit traduite avec la même bonne volonté qu’une consultation de messagerie. Il ne protège rien de ce qui est publié : un DNAT expose le service au monde entier. Il ne s’applique pas aux machines du même réseau, qui se joignent sans traduction. Et il disparaît avec IPv6, où chaque machine peut avoir une adresse globale : seul un pare-feu avec état fournit alors le refus par défaut que l’on croyait tenir du NAT (voir IPv6, autoconfiguration et coexistence). Pour mémoire, IPv6 connaît une traduction de préfixe sans état, NPTv6 (Network Prefix Translation, RFC 6296, de statut expérimental), utile pour certains cas de multi-raccordement, mais le NAT avec ports de type IPv4, dit NAT66, n’est pas recommandé par l’IETF (Internet Engineering Task Force) et reste marginal.

CGNAT et traçabilité

Faute d’adresses IPv4, de nombreux opérateurs, surtout mobiles, ajoutent un second niveau de traduction dans leur propre réseau : le CGNAT (Carrier-Grade NAT). L’abonné reçoit sur sa box une adresse du bloc 100.64.0.0/10, réservé à cet usage par le RFC 6598, et partage son adresse publique avec d’autres abonnés. Deux conséquences. D’abord, aucun service ne peut être publié depuis chez soi : il n’existe aucune redirection possible sur un équipement de l’opérateur. Ensuite, une adresse publique ne désigne plus un abonné : pour attribuer une activité, il faut l’adresse, le port source et un horodatage précis, croisés avec les journaux de traduction de l’opérateur. Un service en ligne qui ne journalise pas le port source de ses clients rend cette attribution impossible.

La journalisation des translations s’impose au même titre dans l’entreprise : sans elle, un signalement du type « activité malveillante depuis 203.0.113.5 à 14 h 02 » ne mène à aucune machine. Les journaux doivent contenir adresse et port internes, adresse et port traduits, destination, et un horodatage synchronisé. Certains équipements réduisent le volume en allouant des blocs de ports par client et en ne journalisant que l’allocation du bloc.

Les protocoles cassés par la translation

Le NAT réécrit les en-têtes, pas le contenu. Tout protocole qui transporte des adresses ou des ports dans ses données souffre donc. Le FTP (File Transfer Protocol) en mode actif annonce, dans la commande PORT, l’adresse privée du client, que le serveur ne peut pas joindre. SIP (Session Initiation Protocol) et sa description de session SDP (Session Description Protocol) indiquent l’adresse où envoyer l’audio, encore une fois privée. IPsec en mode AH (Authentication Header) signe l’en-tête IP, que le NAT modifie, ce qui invalide la signature ; ESP (Encapsulating Security Payload) passe grâce à l’encapsulation dans UDP (User Datagram Protocol) sur le port 4500 (NAT-T, RFC 3948). Les passerelles applicatives (ALG, Application Level Gateway) intégrées aux routeurs tentent de réécrire ces contenus, avec un succès variable : une ALG SIP défaillante est l’une des causes les plus fréquentes d’appels sans son dans un sens.

Exemples et ateliers

NAT source sortant. Le schéma tient en une ligne : poste 192.168.10.23:51544 -> [routeur, SNAT] -> 203.0.113.5:51544 -> serveur 198.51.100.7:443, avec la table de translation dessinée au-dessus du routeur et la flèche de retour qui la consulte. L’exercice consiste à y ajouter un second poste qui choisit lui aussi le port 51544, et à montrer que le routeur lui attribue un autre port public.

Publication par DNAT. Le schéma montre un client 198.51.100.40 qui joint 203.0.113.5:443, la règle DNAT qui réécrit la destination en 192.168.20.10:443, puis la règle de filtrage qui autorise ce flux vers la DMZ (zone démilitarisée) et seulement lui. La question de contrôle : qu’arrive-t-il si l’on supprime la règle de filtrage mais pas la règle DNAT ? Sur un pare-feu correctement configuré, le flux est refusé ; sur une box qui couple les deux, la question ne se pose même pas.

Service inaccessible derrière CGNAT. Un utilisateur publie un serveur domestique sur le port 443 ; rien ne répond de l’extérieur. Diagnostic en trois étapes : lire l’adresse WAN affichée par la box ; la comparer à l’adresse publique vue par un service externe ; si l’adresse de la box appartient à 100.64.0.0/10 ou diffère de l’adresse vue de l’extérieur, un CGNAT est en place, et aucune redirection sur la box n’y changera rien. Les issues sont connues : demander à l’opérateur une adresse IPv4 publique dédiée, publier en IPv6 si l’opérateur le fournit, ou établir une connexion sortante vers un relais extérieur (serveur loué, service de tunnel) qui republie le service.

Pièges classiques

Croire que le NAT suffit comme pare-feu laisse le réseau sans politique sortante et sans contrôle des services publiés. Oublier les logs de translation rend toute enquête impossible au-delà de l’adresse publique. Publier un service interne par erreur, par une redirection de test jamais retirée ou une règle UPnP créée par une application, expose des interfaces que personne ne surveille. Les services de recensement d’Internet, eux, les trouvent en quelques heures.

À ne pas confondre

Le NAT traduit, le filtrage décide ; un équipement fait souvent les deux, ce qui entretient la confusion. Le DNAT réécrit une adresse de destination, le reverse proxy termine la connexion et en ouvre une autre, ce qui lui permet d’inspecter et d’authentifier (voir Services applicatifs et partage). Une adresse privée n’est pas une protection : elle est seulement non routée sur Internet, et parfaitement joignable depuis tout le réseau interne. Le CGNAT n’est pas un pare-feu d’opérateur : il partage des adresses, il ne garantit aucun filtrage, et l’abonné reste responsable de ce qui sort de chez lui.

🐝 Ce qui arrive si on s’en passe

Un réseau qui compte sur la traduction d’adresses pour se protéger ne dispose d’aucune politique de filtrage écrite : la première règle de publication ajoutée pour un besoin ponctuel expose un service interne à tout Internet, et rien ne signale qu’elle n’était pas prévue. Sans journal de translation horodaté, une activité malveillante signalée depuis l’adresse publique ne se rattache à aucune machine interne ; l’enquête s’arrête à la porte, et la machine compromise poursuit son activité à l’intérieur. Derrière une traduction d’opérateur partagée entre abonnés, la même adresse publique désigne plusieurs clients à la fois, ce qui rend toute attribution sans horodatage précis ni port source parfaitement hasardeuse.

🦫 Explication de la marmotte 🍫

Sur Internet, chaque machine qui communique a besoin d’une adresse publique, mais ces adresses sont rares. La traduction d’adresses, appelée NAT, de l’anglais network address translation, permet à beaucoup de machines d’un réseau privé de sortir avec une seule adresse publique. Quand une machine interne envoie un message vers l’extérieur, l’équipement de sortie remplace l’adresse et le numéro de port d’origine par les siens, et note cette correspondance dans une table de translation. Quand la réponse revient, il consulte la table et la renvoie à la bonne machine. Les fournisseurs d’accès appliquent parfois une seconde traduction pour partager une même adresse entre plusieurs abonnés. Dans l’autre sens, publier un service consiste à dire à l’équipement que tout ce qui arrive sur tel port de l’adresse publique doit être transmis à telle machine interne ; une erreur de configuration suffit à exposer un service qui devait rester interne. Certains protocoles écrivent des adresses à l’intérieur de leurs messages, que la traduction ne modifie pas, et ils cessent alors de fonctionner. Pour les appels vidéo, par exemple, des techniques spéciales aident deux machines placées derrière une traduction à se joindre, avec un relais si rien d’autre ne marche. La traduction ne filtre rien par elle-même : seules des règles de pare-feu décident de ce qui passe. Sans journal des correspondances, il devient impossible de savoir quelle machine interne se cachait derrière une adresse publique à un instant donné.

Pages voisines

La citent

NAT, translations et publication de services

Elle cite

: les deux pages se citent l’une l’autre.

NAT, translations et publication de services

NAT, translations et publication de services

Traduire pour sortir

SNAT et PAT

La table de translation

Domestique, entreprise et nuage

Publier et traverser

DNAT et port forwarding

Reverse proxy, répartiteur de charge et NAT

STUN, TURN et ICE

Limites et sécurité

Pourquoi le NAT n’est pas une politique de sécurité

CGNAT et traçabilité

Les protocoles cassés par la translation

Exemples et ateliers

Pièges classiques

À ne pas confondre

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines