Quand on commence à toucher aux routeurs, aux VM, à Docker, à un petit pfSense dans un coin, on tombe vite sur le même truc. Tout marche en sortie… puis, bizarrement, rien ne rentre.
Et là, tu lis « NAT » partout.
NAT, en vrai, c’est pas si compliqué. Ce qui rend le sujet pénible, c’est qu’on mélange souvent trois choses dans la même phrase : les adresses privées, la traduction d’adresse, et les règles de pare feu. Alors qu’on peut déjà avancer avec un seul schéma simple et deux ou trois flux typiques.
On va faire ça. Et si tu es en BTS SIO SISR, garde ça sous le coude pour tes labs et tes comptes rendus E4, E5. D’ailleurs, sur BTS SIO2 SISR Tech Lab ( https://sio1blog.blogspot.com/ ), je publie souvent des mini labs réseau et sécu, dans la même logique : concret, visible, testable.
NAT : l’idée en une phrase
Le NAT (network address translation) consiste à modifier des informations d’adressage dans les paquets quand ils traversent un équipement (routeur, firewall, box). Typiquement, on change l’adresse IP source, ou l’adresse IP destination, parfois le port.
Pourquoi on fait ça ?
Parce que sur un LAN on utilise souvent des IP privées (RFC1918), non routables sur Internet. Donc pour sortir, il faut « présenter » une IP publique.
Le schéma simple à garder en tête
Voici le schéma qu’on va utiliser tout le long. Un poste dans un LAN privé. Un routeur qui fait NAT. Internet.
Quelques repères :
- PC1 : 192.168.1.10
- Routeur (LAN) : 192.168.1.1
- Routeur (WAN) : 203.0.113.5 (IP publique exemple)
- Serveur web Internet : 198.51.100.20 (exemple)
Oui, ce sont des IP de documentation (203.0.113.0/24, 198.51.100.0/24). Pratique pour expliquer sans viser une vraie cible.
Avant de parler NAT : qui décide de laisser passer ?
Petit aparté, mais important. Beaucoup de gens pensent :
« si je fais une règle NAT, j’autorise le trafic ».
Non. Pas forcément.
Sur beaucoup de firewalls (pfSense, FortiGate, etc.), tu as :
- une partie « NAT » qui fait la traduction
- une partie « firewall » qui autorise ou bloque
Sur une box grand public, c’est souvent fusionné et ça entretient la confusion.
Donc dans ta tête, sépare bien : NAT = réécriture d’adresse, pare feu = décision.
SNAT, DNAT : les deux familles qui reviennent tout le temps
On peut classer très simplement :
- SNAT : on modifie l’IP source (souvent en sortie vers Internet)
- DNAT : on modifie l’IP destination (souvent pour publier un service interne)
Et au milieu, tu as le NAT le plus courant en entreprise ou à la maison : le PAT (port address translation), souvent appelé « NAT overload ». En gros : plein de machines privées partagent une seule IP publique grâce aux ports.
On le voit juste après.
Cas no 1 : sortie Internet classique (PAT / masquerade)
PC1 veut aller sur un site web : 198.51.100.20 en HTTPS (port 443).
Sans NAT, le paquet sortirait comme ça :
- Source : 192.168.1.10:55321
- Destination : 198.51.100.20:443
Sauf que 192.168.1.10, sur Internet, personne ne sait répondre. Donc le routeur fait un NAT source, et très souvent change aussi le port.
Avec PAT, ça devient :
- Source : 203.0.113.5:40001
- Destination : 198.51.100.20:443
Le serveur web répond à 203.0.113.5:40001, et le routeur sait que ça correspond à la session de 192.168.1.10:55321. Il garde une entrée dans une table.
La table NAT, version simplifiée
| Interne (inside local) | Externe (inside global) | Destination |
| 192.168.1.10:55321 | 203.0.113.5:40001 | 198.51.100.20:443 |
Ce tableau, c’est le cœur du truc.
Le NAT, ce n’est pas juste « je remplace l’IP ». C’est « je remplace l’IP et je mémorise une correspondance ».
Pourquoi « ça marche en sortie mais pas en entrée » ?
Parce que la table NAT se crée quand un flux sortant démarre. Donc le retour est attendu, associé, autorisé.
Si depuis Internet, quelqu’un tente d’initier une connexion vers 203.0.113.5:40001, ça ne veut rien dire. Le routeur n’a pas de correspondance, donc il jette.
Et c’est là que tu commences à entendre : « il faut faire du port forwarding ».
Oui. DNAT.
Cas no 2 : publier un serveur interne (DNAT / port forwarding)
Tu as un serveur web interne : 192.168.1.50, et tu veux le rendre accessible depuis Internet sur le port 443.
Tu configures une redirection :
- Si quelqu’un arrive sur 203.0.113.5:443
- Alors tu rediriges vers 192.168.1.50:443
C’est du DNAT : on modifie la destination.
Schéma mental :
Concrètement, un client Internet envoie :
- Source : 8.8.8.8:51234
- Destination : 203.0.113.5:443
Le routeur réécrit :
- Source : 8.8.8.8:51234
- Destination : 192.168.1.50:443
Et quand le serveur répond, là ça devient subtil : il faut que le retour repasse par le routeur NAT, sinon le client n’acceptera pas.
Dans la plupart des cas, ça marche car la passerelle par défaut du serveur interne est bien le firewall routeur. Donc le retour repasse par lui, et il fait la traduction inverse.
Le piège classique : DNAT sans règle firewall
Tu fais la redirection NAT, mais tu oublies d’autoriser le flux côté pare feu WAN.
Résultat : tu testes depuis l’extérieur, ça time out. Et tu te dis « le NAT marche pas ».
En vrai, le NAT fait son boulot. Mais le pare feu bloque.
Dans un lab BTS, c’est typiquement le genre de capture que tu peux montrer dans ton compte rendu : NAT OK, firewall KO, ou inverse. Ça fait pro, parce que tu démontres.
Cas no 3 : NAT statique (1:1)
Là on quitte un peu la box maison. NAT statique, c’est quand tu veux associer une IP publique à une machine interne, de façon fixe.
Exemple :
- 203.0.113.10 ↔ 192.168.1.10
Tout trafic vers 203.0.113.10 est envoyé à 192.168.1.10. Et la machine sort avec 203.0.113.10.
C’est pratique quand :
- tu as un bloc d’IP publiques
- tu veux une séparation nette par service
- tu veux éviter de gérer 15 redirections de ports
Mais attention, ça peut exposer énormément si tu n’as pas un pare feu strict.
NAT et flux retour : le truc qui explique 80 % des bugs
Il y a une idée que tu dois vraiment garder.
Pour qu’un flux marche, il faut que :
- le paquet aller passe
- la réponse revienne par le même chemin, et que le NAT inverse puisse s’appliquer
C’est pour ça que des architectures multi liens ou multi routeurs font souffrir.
Exemple classique :
- DNAT sur firewall A
- mais le serveur interne renvoie son trafic via routeur B (mauvaise passerelle)
- le client Internet reçoit une réponse depuis l’IP privée ou depuis une autre IP publique
- et la connexion casse
On appelle souvent ça un problème de routage asymétrique. Et c’est méchant, parce que tu vois des paquets dans Wireshark, tu as l’impression que « ça répond », mais non, pas correctement.
Hairpin NAT : accéder à un service publié, mais depuis le LAN
Scénario réel :
- ton site est publié sur https://monserveur.mondomaine.tld
- ce DNS pointe vers 203.0.113.5
- depuis ton LAN, tu veux accéder au site avec le même nom
Ton PC interne va donc essayer d’aller vers 203.0.113.5, qui est… ton IP WAN.
Il faut alors que le firewall supporte le « NAT loopback », aussi appelé hairpin NAT.
Sans ça, tu obtiens :
- soit un refus
- soit un comportement bizarre
- soit ça marche sur mobile (4G) mais pas en Wi-Fi (LAN)
Et c’est typiquement le bug que les gens découvrent le vendredi à 18 h 40.
Une mini méthode de diagnostic, simple et efficace
Quand « le NAT ne marche pas », fais ça dans cet ordre. Toujours.
1) Vérifie le routage de base
- le client a la bonne passerelle ?
- le firewall a une route vers le LAN ?
- le serveur interne a sa passerelle sur le firewall ?
Sans routage, le NAT n’a même pas l’occasion d’être utile.
2) Vérifie le pare feu
- règle WAN qui autorise le port ?
- règle LAN qui autorise la sortie ?
- logs : tu vois des blocks ?
3) Vérifie la règle NAT
- interface concernée (WAN, LAN, VLAN) ?
- bon port externe et bon port interne ?
- bonne IP interne cible ?
4) Observe un vrai flux
- tcpdump sur le firewall
- Wireshark côté client
- logs NAT si disponibles
Tu veux répondre à une seule question : est ce que le paquet arrive, et sous quelle forme.
Exemple rapide avec des commandes (niveau BTS, mais utile)
Sur un Linux routeur, tu peux voir des règles NAT avec iptables (legacy) :
bash sudo iptables -t nat -L -n -v
Et voir les sessions suivies (conntrack) :
bash sudo conntrack -L | head
Sur pfSense, tu regardes :
- Firewall > NAT
- Status > System Logs
- Diagnostics > Packet Capture
Ce n’est pas « pour faire joli ». C’est vraiment l’endroit où tu comprends le sens des flèches.
Un dernier schéma mental, très concret
Si tu ne devais retenir qu’un dessin dans ta tête :
- Sortie : le routeur remplace 192.168.1.10 par 203.0.113.5, garde une table, et laisse revenir la réponse.
- Entrée : pour initier depuis Internet, il faut une règle DNAT explicite, et une règle firewall explicite.
C’est ça. Et déjà, tu as compris la majorité des lab NAT qu’on te demandera.
Pour aller plus loin sur BTS SIO2 SISR Tech Lab
Si tu veux, je peux publier une suite sur BTS SIO2 SISR Tech Lab ( https://sio1blog.blogspot.com/ ) avec un vrai lab pas à pas :
- NAT sortant + logs
- DNAT web + test depuis Internet (ou depuis un VPS)
- hairpin NAT
- et une capture Wireshark commentée, parce que ça change tout quand tu vois les IP dans les paquets
Si ça t’intéresse, garde le site en favoris, je mets souvent des articles orientés « manip et preuve », pas juste théorie.
Conclusion
Le NAT, ce n’est pas un concept mystérieux. C’est une réécriture + une table, et ensuite tout tourne autour de la question : « est ce que le flux retour repasse au bon endroit ».
Avec le schéma simple LAN → routeur NAT → Internet, tu peux expliquer :
- le PAT en sortie
- le DNAT pour publier un service
- pourquoi le retour est vital
- pourquoi tu as parfois besoin de hairpin NAT
Et franchement, une fois que tu sais dessiner ça sur une feuille, tu es déjà au dessus de beaucoup de configs faites au hasard, au clic, sans comprendre. Ce qui est… assez courant.
Questions fréquemment posées
Qu'est-ce que le NAT et pourquoi est-il utilisé dans les réseaux ?
Le NAT (Network Address Translation) consiste à modifier des informations d'adressage dans les paquets lorsqu'ils traversent un équipement réseau comme un routeur ou un firewall. Il est utilisé principalement parce que les réseaux locaux utilisent souvent des adresses IP privées non routables sur Internet, donc pour permettre la communication vers l'extérieur, il faut présenter une adresse IP publique.
Quelle est la différence entre NAT, adresses privées et règles de pare-feu ?
Ces trois concepts sont souvent confondus. Le NAT concerne la traduction d'adresses IP dans les paquets. Les adresses privées sont des plages d'IP non routables sur Internet utilisées en LAN. Les règles de pare-feu décident si un trafic est autorisé ou bloqué. Il est important de bien différencier ces notions : NAT modifie les adresses, tandis que le pare-feu contrôle l'autorisation du trafic.
Quels sont les types principaux de NAT et leurs usages ?
Il existe deux grandes familles de NAT : le SNAT (Source NAT), qui modifie l'adresse IP source, souvent utilisé pour les connexions sortantes vers Internet ; et le DNAT (Destination NAT), qui modifie l'adresse IP destination, généralement pour publier un service interne accessible depuis l'extérieur. Entre les deux, on trouve le PAT (Port Address Translation), aussi appelé "NAT overload", qui permet à plusieurs machines privées de partager une seule IP publique grâce à la translation des ports.
Comment fonctionne le PAT lors d'une connexion Internet classique ?
Lorsqu'un poste du LAN (par exemple 192.168.1.10) souhaite accéder à un site web externe, son paquet sort avec son IP privée source. Le routeur effectue une translation d'adresse source (SNAT) en remplaçant cette IP privée par sa propre IP publique et modifie aussi le port source pour différencier chaque session. Ainsi, par exemple, la source devient 203.0.113.5:40001 vers la destination 198.51.100.20:443. Le routeur maintient une table de correspondance pour acheminer correctement les réponses.
Le NAT autorise-t-il automatiquement le passage du trafic ?
Non, faire une règle NAT ne signifie pas automatiquement autoriser le trafic. Sur beaucoup de firewalls comme pfSense ou FortiGate, la fonction NAT est distincte des règles de pare-feu qui décident d'autoriser ou bloquer le trafic. Sur certaines box grand public ces fonctions sont fusionnées, ce qui peut créer une confusion.
Quels schémas simples peut-on retenir pour comprendre le fonctionnement du NAT ?
Un schéma simple consiste en un poste dans un LAN privé avec une adresse IP privée (exemple : 192.168.1.10), un routeur faisant NAT ayant une interface LAN (192.168.1.1) et une interface WAN avec une IP publique (203.0.113.5), et enfin Internet avec des serveurs externes (exemple : 198.51.100.20). Ce modèle aide à visualiser comment les adresses sont traduites lors des communications entre le LAN et Internet.
0 Commentaires