NAT : comprendre enfin les flux entrants et sortants

Si tu es en BTS SIO option SISR, tu as forcément déjà entendu une phrase du genre « on a mis du NAT, donc c’est bon ». Et tu as aussi probablement vu, en TP, une règle NAT qui marche… puis une autre qui casse tout. Et là tu te retrouves à cliquer partout dans le firewall, à douter de ta vie, à rebooter « au cas où ».

Le NAT, c’est simple sur le papier. Dans la vraie vie, avec les flux entrants et sortants, les retours de flux, les ports, les règles dans le mauvais ordre et les routes qui ne sont pas celles que tu crois… c’est un petit labyrinthe.

Donc on va faire un truc plus utile qu’un cours théorique. On va comprendre vraiment :

• ce que veut dire « flux sortant » et « flux entrant »
• pourquoi le retour de flux n’est pas un flux entrant « comme les autres »
• les types de NAT que tu utilises en entreprise (et en lab)
• comment diagnostiquer quand ça ne marche pas
• et surtout, comment raisonner proprement

Et si tu veux compléter avec des labs systèmes et réseaux dans le même style, garde sous la main le blog BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) : l’idée c’est justement de relier les notions à des cas concrets, pas juste réciter un schéma.

NAT, c’est quoi au juste (mais vraiment)

NAT = network address translation. Traduction d’adresses. Le principe : un équipement (souvent un routeur ou un pare-feu) remplace une adresse IP (et parfois un port) par une autre.

Le cas le plus courant :

• ton PC est en IP privée, par exemple 192.168.1.10
• Internet ne route pas les IP privées
• donc ton pare-feu remplace la source 192.168.1.10 par ton IP publique, par exemple 203.0.113.5
• et il garde quelque part une table qui dit : « ce flux-là appartient à ce client-là »

Ce dernier point est le point qui fait toute la différence entre « je crois que j’ai compris » et « je dépanne en prod sans panique ».

Le NAT n’est pas juste une traduction. C’est une traduction avec état la plupart du temps (en tout cas sur les firewalls modernes). Donc, il y a une notion de session, de table de correspondance, de timeout, etc.

Flux sortant vs flux entrant : la définition claire

On va être très stricts avec les mots, sinon tu te fais piéger.

Flux sortant

Un flux sortant, c’est un flux initié depuis ton réseau interne vers l’extérieur.

Exemple : ton PC va sur https://www.example.com en TCP 443.

• source : 192.168.1.10:52344
• destination : 93.184.216.34:443

Le NAT appliqué ici est généralement du SNAT (source NAT). Souvent sous forme de masquerading, PAT, overload… bref, « plein de clients partagent une IP publique ».

Flux entrant

Un flux entrant, c’est un flux initié depuis l’extérieur vers ton réseau interne.

Exemple : quelqu’un sur Internet tente d’accéder à ton serveur web interne.

• source : 198.51.100.25:60000
• destination : 203.0.113.5:443

Et toi tu veux rediriger ça vers :

• serveur interne : 192.168.1.20:443

Ici, tu fais du DNAT (destination NAT), souvent appelé « port forwarding ».

Le piège classique : le retour d’un flux sortant n’est pas un flux entrant

Quand ton PC initie une connexion vers Internet, le serveur va répondre. Ce trafic revient de l’extérieur vers ton IP publique. Beaucoup d’étudiants appellent ça « entrant ». En ressenti, oui, ça arrive de l’extérieur.

Mais en logique firewall, c’est du trafic de retour, associé à un état existant.

Donc :

• ce n’est pas un « flux entrant publié »
• ça ne doit pas nécessiter une règle DNAT
• ça ne doit pas nécessiter une ouverture entrante large, si le firewall est stateful

C’est pour ça qu’un firewall a souvent une règle implicite du type : « autoriser established, related ».

Les trois grands types de NAT à connaître en SISR

On peut faire compliqué, mais en vrai pour ton quotidien SISR, retiens ces trois-là.

1) SNAT (source NAT) : pour les flux sortants

But : remplacer l’IP source interne par une IP routable (souvent publique).

Cas typique : sortie Internet du LAN.

• avant NAT : 192.168.1.10 -> Internet
• après NAT : 203.0.113.5 -> Internet

Selon le firewall, ça peut s’appeler :

• masquerade
• hide NAT
• PAT (port address translation)
• overload (Cisco)
• « NAT dynamique »

Ce NAT crée une entrée dans une table, du style :

• 192.168.1.10:52344 devient 203.0.113.5:40001

Et c’est cette table qui permet au retour de trouver le bon poste.

2) DNAT (destination NAT) : pour publier un service en entrant

But : remplacer l’IP de destination (souvent l’IP publique du firewall) par l’IP du serveur interne.

Cas typique : publier un serveur web interne.

• avant NAT : 203.0.113.5:443
• après NAT : 192.168.1.20:443

C’est le fameux port forwarding. Ici tu dois aussi penser à la règle firewall. Le NAT seul ne suffit pas toujours.

3) NAT statique 1:1 : quand tu veux que ce soit propre

But : associer une IP publique dédiée à une IP privée.

Exemple :

• 203.0.113.10 <-> 192.168.1.30

Tu l’utilises quand tu as plusieurs IP publiques et que tu veux publier plusieurs serveurs proprement, ou éviter les problèmes de ports, ou faire des politiques plus lisibles.

Ce n’est pas obligatoire en petit réseau, mais c’est très courant en entreprise.

Lire un flux comme un pro (avec un exemple complet)

On va faire un scénario simple.

• LAN : 192.168.10.0/24
• firewall LAN : 192.168.10.254
• WAN firewall : 203.0.113.5
• serveur web interne : 192.168.10.20

Cas A : un poste interne va sur Internet (flux sortant)

Le PC 192.168.10.10 ouvre une session TCP vers 142.250.74.14:443 (un serveur Google par exemple).

1. Sur le LAN, avant NAT :

• src : 192.168.10.10:51000
• dst : 142.250.74.14:443

2. Le firewall applique SNAT :

• src devient 203.0.113.5:40010
• dst reste 142.250.74.14:443

3. Le serveur répond à :

• src : 142.250.74.14:443
• dst : 203.0.113.5:40010

4. Le firewall consulte sa table NAT et réécrit vers :

• dst devient 192.168.10.10:51000

Et voilà. Aucun DNAT. Aucun « port ouvert entrant » au sens publication. Juste de l’état et une translation de retour.

Cas B : un client Internet accède au serveur web interne (flux entrant)

Un client externe 198.51.100.25 veut accéder à https://203.0.113.5.

1. Sur le WAN, le paquet arrive :

• src : 198.51.100.25:55000
• dst : 203.0.113.5:443

2. Le firewall applique DNAT (port forwarding) :

• dst devient 192.168.10.20:443

3. Le serveur répond :

• src : 192.168.10.20:443
• dst : 198.51.100.25:55000

Et là, attention. Le serveur, lui, a comme passerelle le firewall, donc il renvoie bien via le firewall. Le firewall va souvent appliquer aussi un SNAT côté sortie, selon le design, ou au minimum il maintient l’état de la session NAT. Le but : que le client externe voie une conversation cohérente avec 203.0.113.5.

C’est souvent ici que les erreurs arrivent si :

• la route de retour n’est pas correcte
• le serveur ne passe pas par le firewall
• il y a un autre équipement qui fait NAT au milieu
• ou la règle NAT ne correspond pas au bon port / interface

NAT et firewall : deux choses différentes, mais liées

Un piège fréquent en TP : « j’ai fait le NAT, mais ça ne marche pas ». Oui. Parce que NAT ≠ autorisation.

En simplifiant :

• NAT : modifie des champs IP et ports
• règles firewall : autorisent ou bloquent

Selon les solutions, tu peux avoir :

• des politiques « NAT + sécurité » séparées (souvent le cas)
• ou des objets / règles combinées (selon l’éditeur)

Donc, pour un flux entrant publié, tu as souvent besoin de deux choses :

1. une règle DNAT
2. une règle firewall WAN -> LAN (ou WAN -> DMZ) autorisant TCP 443 vers le serveur

Et pour un flux sortant, tu as souvent :

1. une règle firewall LAN -> WAN autorisant la sortie
2. une règle SNAT (souvent globale)

Le sens de « entrant » et « sortant » dépend de l’interface

Petit rappel qui fait mal quand on l’oublie. Quand on dit « entrant » ou « sortant », on parle généralement du point de vue du pare-feu, donc selon l’interface :

• entrant sur WAN : ça vient d’Internet vers toi
• sortant sur WAN : ça part de chez toi vers Internet

Mais un même paquet peut être « entrant » sur une interface et « sortant » sur une autre. Donc si tu lis des logs, vérifie toujours :

• l’interface d’entrée (ingress)
• l’interface de sortie (egress)
• l’avant NAT et l’après NAT (souvent affichés différemment)

Les cas qui te font perdre du temps (et comment les reconnaître)

1) Le NAT hairpin (ou NAT loopback)

Cas typique : depuis le LAN, tu veux accéder à ton serveur publié via l’IP publique ou le nom de domaine public.

Exemple : depuis 192.168.10.10, tu tapes https://mon-site.fr qui pointe vers 203.0.113.5.

Sans hairpin NAT, ça peut échouer ou partir sur un chemin bizarre. Avec hairpin, le firewall accepte qu’un client interne « revienne » vers l’IP publique et soit redirigé vers le serveur interne.

Symptôme : ça marche depuis 4G, mais pas depuis le Wi-Fi interne. Classique.

Solution : activer/configurer le NAT loopback, ou utiliser split DNS (résolution interne différente).

2) Double NAT

Tu as une box opérateur qui fait NAT, puis ton firewall qui refait NAT. En lab c’est fréquent, en PME aussi.

Symptôme : la publication entrante ne marche pas malgré DNAT. Normal, parce que l’IP publique n’est pas sur ton firewall, elle est sur la box. Il faut aussi rediriger sur la box, ou passer la box en mode bridge, ou mettre ton firewall en DMZ.

3) Le serveur ne renvoie pas par le bon chemin

Un serveur interne avec une mauvaise passerelle par défaut, ou une route statique qui renvoie ailleurs.

Symptôme : tu vois le SYN arriver, tu vois le DNAT, mais pas de SYN-ACK qui ressort correctement. Ou alors il sort, mais pas par la bonne interface.

Réflexe : vérifier la gateway du serveur, puis un traceroute, puis les routes sur le firewall.

4) Ordre des règles NAT

Sur pas mal d’équipements, l’ordre compte. Une règle trop générale matche avant la règle spécifique.

Symptôme : tu as « tout bon », mais c’est une autre règle qui s’applique. Les logs NAT aident beaucoup ici.

Réflexe : lire les hits sur les règles, activer le logging temporairement.

Méthode de dépannage simple (et très efficace)

Quand NAT et flux te rendent fou, tu fais ça. Toujours dans cet ordre.

Étape 1 : définir le flux attendu, noir sur blanc

Écris :

• qui initie la connexion
• source IP:port
• destination IP:port
• protocole (TCP, UDP, ICMP)

Sans ça, tu dépannes dans le flou.

Étape 2 : vérifier la route, avant même le NAT

• le client a-t-il une gateway correcte ?
• le firewall a-t-il une route vers la destination ?
• le serveur interne a-t-il une route de retour via le firewall ?

Le NAT ne corrige pas une route cassée.

Étape 3 : vérifier la règle NAT appliquée

Sur le firewall, cherche :

• la règle matche-t-elle la bonne interface d’entrée ?
• matche-t-elle la bonne destination (IP publique, port) ?
• pour SNAT : quelle IP publique est utilisée ?
• pour DNAT : vers quelle IP interne est traduit ?

Étape 4 : vérifier la politique de sécurité

Même si le NAT est bon, la règle de filtrage peut bloquer.

• WAN -> LAN pour un flux entrant publié
• LAN -> WAN pour un flux sortant

Étape 5 : regarder l’état de session / conntrack

Si ton équipement le permet, c’est de l’or.

• vois-tu la session ?
• vois-tu les deux sens (aller et retour) ?
• vois-tu la translation NAT associée ?

Étape 6 : capture de paquets, au bon endroit

Si tu peux, capture sur :

• interface WAN (avant DNAT)
• interface LAN (après DNAT)
• et pareil pour le retour

Un tcpdump ou une capture intégrée firewall te montre la vérité, sans interprétation.

Petit mémo ultra utile : ce que tu dois retenir

• Flux sortant : initié par l’interne, généralement SNAT.
• Flux entrant : initié par l’externe, généralement DNAT + règle firewall.
• Retour de flux sortant : ce n’est pas une publication entrante, c’est de l’état.
• NAT ≠ autorisation : NAT traduit, le firewall autorise.
• Route de retour : si elle est fausse, tout s’écroule.
• Hairpin et double NAT : deux causes fréquentes de « ça marche pas en interne ».

Un mini lab à refaire chez toi (ou en salle)

Si tu veux t’entraîner vite fait, tu peux te monter un lab avec :

• une VM firewall (pfSense, OPNsense, ou même une distro avec nftables)
• une VM cliente dans un LAN
• une VM serveur web interne
• et un réseau WAN simulé (ou un second réseau)

Objectif :

1. faire sortir le client vers Internet (SNAT)
2. publier le serveur web (DNAT)
3. tester depuis un « client WAN » (une autre VM côté WAN)
4. tester depuis le LAN via l’IP publique (hairpin)

Et si tu veux des idées de labs et de checklists réseau, tu peux piocher sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/). Le but, c’est d’accumuler des petits scénarios réalistes. Ceux qui te servent le jour où tu dois dépanner vite.

Conclusion : si tu comprends les flux, le NAT devient banal

Le NAT a une réputation un peu magique. Alors qu’en réalité, c’est très mécanique.

Tu identifies qui initie. Tu suis le paquet. Tu sais ce qui est traduit (source ou destination). Tu vérifies la route de retour. Et tu sépares bien NAT et filtrage.

Et là, d’un coup, ce n’est plus « le NAT marche pas ». C’est : « le DNAT matche pas parce que l’interface d’entrée n’est pas la WAN », ou « le serveur répond hors firewall », ou « le retour n’a pas d’état parce que la session expire ». Bref, tu redeviens maître du truc.

Si tu veux, je peux aussi te proposer une version « cheat sheet » imprimable (une page) avec schémas flux sortant vs entrant, et une checklist dépannage. Ce genre de mémo, en plein TP, ça sauve.

Questions fréquemment posées

Qu'est-ce que le NAT et pourquoi est-il essentiel en réseau ?

Le NAT (Network Address Translation) est une technique qui permet à un équipement, comme un routeur ou un pare-feu, de remplacer une adresse IP (et parfois un port) par une autre. Cela permet notamment à des machines avec des adresses IP privées de communiquer sur Internet via une adresse IP publique. Le NAT est essentiel car Internet ne route pas les adresses IP privées, donc sans NAT, les machines internes ne pourraient pas accéder au réseau externe.

Quelle est la différence entre un flux sortant et un flux entrant en contexte NAT ?

Un flux sortant est une communication initiée depuis le réseau interne vers l'extérieur, par exemple lorsqu'un PC interne accède à un site web. Le NAT appliqué est généralement du SNAT (Source NAT). Un flux entrant est une communication initiée depuis l'extérieur vers le réseau interne, comme lorsqu'un utilisateur externe tente d'accéder à un serveur web interne. Ici, on utilise du DNAT (Destination NAT) souvent appelé redirection de port.

Pourquoi le retour d'un flux sortant n'est-il pas considéré comme un flux entrant classique ?

Le retour d'un flux sortant correspond au trafic de réponse d'une connexion initiée depuis le réseau interne. Même s'il arrive de l'extérieur, il est associé à une session déjà établie et gérée par la table d'état du firewall. Ce trafic de retour ne nécessite pas de règle DNAT ni d'ouverture large entrante si le firewall est stateful, car il est implicitement autorisé grâce aux règles 'established' et 'related'.

Quels sont les principaux types de NAT utilisés en entreprise et en laboratoire SISR ?

Les trois grands types de NAT à connaître sont : 1) SNAT (Source NAT) : utilisé pour les flux sortants afin de remplacer l'adresse IP source interne par une adresse IP publique routable. 2) DNAT (Destination NAT) : utilisé pour les flux entrants afin de rediriger des connexions externes vers des serveurs internes spécifiques. 3) Le masquerading ou PAT (Port Address Translation) : forme particulière de SNAT où plusieurs clients partagent la même adresse IP publique en différenciant les ports.

Comment diagnostiquer quand une règle NAT ne fonctionne pas correctement ?

Pour diagnostiquer un problème avec le NAT, il faut comprendre précisément si le flux concerné est sortant ou entrant, vérifier la table d'état du firewall pour voir si la session existe, contrôler l'ordre des règles dans le firewall (car une règle mal placée peut bloquer tout), vérifier les routes configurées pour s'assurer qu'elles correspondent bien au trafic attendu, et enfin tester avec des outils adaptés tout en surveillant les logs pour identifier où ça coince.

Comment raisonner proprement avec le NAT pour éviter les erreurs fréquentes ?

Il faut être strict dans la définition des termes : distinguer clairement flux sortant, flux entrant et trafic de retour. Comprendre que le NAT est souvent stateful et que le trafic de retour n'est pas un nouveau flux entrant nécessitant une règle spécifique. Toujours réfléchir à l'origine du trafic et à sa destination finale avant d'écrire des règles. Tester chaque règle isolément et dans l'ordre correct pour éviter qu'une règle bloque tout le reste. Enfin, utiliser des cas concrets et labs pratiques pour relier théorie et réalité.