Je me souviens d’un TP qui avait pourtant l’air anodin : “Configurer un accès Internet pour un petit réseau local avec une seule adresse IP publique.” À ce moment-là, j’étais confiant. Très confiant. Peut-être un peu trop. J’avais déjà fait du ping, de l’IP statique, un peu de routage… alors NAT, franchement, ça devait être une formalité, non ?

Et dans ma tête, ça sonnait comme :

“Bah tu mets une passerelle, tu fais pointer vers l’extérieur, et tout roule !”

🧠 Sauf que non. Rien ne roulait. Tout était figé.

Je configure les IPs internes.
Je configure la route par défaut.
Je connecte le routeur à “l’Internet” du TP.
Je fais un ping vers 8.8.8.8 depuis un poste…
…et là :

Request timed out.

Encore.
Et encore.
Et encore.

Un petit frisson. Le doute. Le syndrome du terminal vide.

🔌 J’ai vérifié les câbles.
🧮 J’ai refait les IPs.
🔁 J’ai redémarré le routeur.
😤 J’ai même pensé que la maquette virtuelle était buggée.

Mais non. Tout était juste… sauf que ça ne marchait pas.

Et c’est là que le formateur est passé derrière moi, en regardant ma config. Il a plissé les yeux, puis dit avec ce petit sourire de “ça va te faire mal mais tu vas apprendre” :

“Tu as tout bien fait. Mais… comment veux-tu qu’une IP privée sorte sur Internet sans NAT ?”

💡 Le déclic : une seule IP pour les gouverner tous

Quand il a dit "sans NAT", j’ai levé les yeux comme si j’avais entendu un mot en klingon.

“Mais… j’ai mis la passerelle, non ? Ça devrait marcher…”

Et c’est là qu’il m’a sorti la métaphore qui a changé ma vie :

“Imagine que tu es à l’intérieur d’un bâtiment avec 50 personnes.
Il n’y a qu’un seul téléphone pour appeler à l’extérieur.
Quand quelqu’un veut téléphoner, il passe par la réception.
Et quand quelqu’un appelle en retour, c’est la réception qui redirige vers la bonne personne.
Eh bien NAT, c’est cette réception.”

🧠 Boum.

Tout s’est éclairé.

En fait, j’avais 50 machines avec des IP privées, genre 192.168.1.x, qui sont comme des numéros internes dans une entreprise. Mais pour sortir sur Internet — qui ne comprend que les adresses publiques — il fallait une sorte de traducteur. Un filtre. Un NAT.

Et le plus fort, c’est que NAT ne se contente pas de traduire les adresses IP.  
Il utilise aussi les numéros de ports TCP/UDP pour suivre qui a demandé quoi.  
C’est comme si chaque machine interne avait un badge unique qu’il faut noter pour lui renvoyer la bonne réponse.

On parle ici de traduction niveau 3 (IP), mais aussi niveau 4 (port). Et c’est ce duo qui permet à plusieurs machines de partager une seule adresse publique sans que tout se mélange.

Et ce traducteur, il bosse à la frontière. Il prend un paquet, il le regarde, et il dit :

“Toi, tu viens de 192.168.1.12, mais je vais te faire passer pour moi : 82.145.22.91.
Et quand la réponse arrivera, je saurai que c’est pour toi.”

🔄 Traduction d’adresse, masquage, redirection : tout ça dans un mécanisme invisible, mais vital.

Et là, j’ai compris : c’était pas un détail. C’était le cœur du truc.

Sans NAT, impossible de sortir.
Avec NAT, les machines privées deviennent des caméléons : elles sortent toutes sous le même masque.

🧪 Et là… ça a marché. Enfin.

On a configuré le NAT, en suivant les instructions du formateur :
Une commande, deux options, une interface dedans, une dehors.

ip nat inside source list 1 interface Gig0/1 overload

Et puis… miracle.

Je relance le ping vers 8.8.8.8.

Reply from 8.8.8.8: bytes=32 time=12ms TTL=119

🟢 Boum. Ronde verte. Ping OK. Internet atteint.

🧠 Ce qu’on venait de faire là, c’était un type bien précis de NAT : le PAT, ou NAT overload.  
En clair, on utilise une seule IP publique pour plusieurs machines internes, et on distingue chaque session avec les numéros de ports.

Mais il existe d’autres formes de NAT :  
- NAT statique : une IP privée correspond toujours à une IP publique, 1:1.  
- NAT dynamique : on puise dans un pool d’adresses publiques selon les besoins.  
- PAT (celui qu’on a fait) : tout le monde sort avec la même IP, et c’est le port source qui permet au routeur de tout suivre.

Mais ce jour-là, tout ce que je voulais, c’était que ça marche. Et ça a marché.

Sur les autres postes, pareil. Tout le monde accède au web avec cette unique adresse IP publique.

C’était magique. Et en même temps, c’était logique.

On avait littéralement un seul “billet” qu'on partage pour sortir, et NAT jouait le rôle du passe-partout, du chef d’orchestre.

Et là, autre révélation du formateur :

“Le NAT, c’est pas seulement pour sortir sur Internet.
C’est aussi pour contrôler qui peut sortir, et qui peut entrer.
Avec du NAT statique ou dynamique, tu peux aussi rediriger des services internes, comme un serveur web local vers l’extérieur.”

Bien sûr, ce n’est pas un firewall à proprement parler.  
Mais comme il casse la connexion initiale, il joue le rôle de mur invisible : rien ne rentre si rien n’est d’abord sorti.

🧠 Nouveau choc.

Je venais de passer d’un petit ping de test à un vrai outil d’administration réseau, filtrage, sécurité, et architecture.

🔄 Le jour où j’ai mal configuré NAT (et tout est tombé)

Évidemment, j’ai voulu refaire tout seul. Reproduire le TP, montrer que j’avais compris. Trop sûr de moi, je suis parti tête baissée.

Et là… blackout total.

ping 8.8.8.8 → Request timed out

Encore ?

ping 8.8.8.8 → KO

😤 “Mais pourquoi ?!”

Je reviens sur ma config. Tout a l’air bon. Je relis la commande NAT, je vérifie les ACLs, et là…
je vois l’erreur de débutant :

J’avais inversé les interfaces.

J’avais mis ip nat outside sur l’interface LAN, et ip nat inside sur l’interface Internet.

🧠 Résultat ? NAT ne savait pas dans quel sens traduire. C’est comme une douane où les entrées et sorties sont inversées. Personne ne bouge.

Et ce jour-là, j’ai appris une grande leçon :

🛑 Avec NAT, il ne suffit pas de “faire” — il faut penser le sens.

• Qui est à l’intérieur ?

• Qui est à l’extérieur ?

• Qui initie la communication ?

• Quelle interface est inside ? Laquelle est outside ?

Et surtout :
🎯 Toujours vérifier ses ACLs. Car si la access-list est mal écrite, aucun trafic ne sera “matché”, donc NAT ne s’appliquera pas.

Depuis ce TP, je double-checke tout :

• Les interfaces inside/outside ✅

• Les routes par défaut ✅

• Les ACLs pour NAT ✅

• Et surtout, les tests de connectivité avant et après ✅

Parce que NAT, c’est puissant. Mais mal configuré ? C’est un mur invisible. Et c’est toi qui te cognes dedans.

🎤 Conclusion

Ce jour-là, je n’ai pas juste appris à “faire du NAT”.

J’ai compris ce que c’était, profondément.

J’ai compris que dans un monde où tout le monde veut sortir, il faut parfois un traducteur, un filtre, un gardien des passages.

Et aujourd’hui, quand je pense au NAT, je ne pense plus à une ligne de config.
Je pense à une réception dans un immeuble, à un pont entre deux mondes, à un caméléon du réseau.

Je vois les machines privées lever la main et dire :

“Je veux sortir !”

Et NAT qui répond :

“OK, mais tu passes par moi. Je gère.”

🧠 Je vois une seule adresse publique comme une façade d’entreprise,
et derrière, tout un monde organisé, invisible, protégé.

Et je me dis, avec un petit sourire :

“C’est fou comme trois lettres peuvent connecter tout un réseau au monde entier.”

📌 Si cet article t’a aidé à mieux comprendre le NAT, imagine ce qu’on peut faire ensemble avec les autres concepts réseau.

👉 Partage-le à un·e camarade qui galère encore avec ses ping.

🔁 Et si tu ne l’as pas encore lu, jette un œil à mon article précédent sur les VLAN. C’est là que tout a commencé !