Comprendre NAT et PAT sans ouvrir trop largement son réseau

Dans une PME, le NAT et le PAT restent invisibles tant que tout fonctionne. Les postes sortent sur Internet, les téléphones se connectent au Wi-Fi, les serveurs internes répondent aux bons services et personne ne se demande pourquoi plusieurs machines peuvent partager la même adresse IP publique. Le sujet devient concret le jour où une règle de pare-feu bloque une application, où un VPN ne passe plus, ou lorsqu’une redirection de port expose un service qui ne devait jamais être visible.

Le NAT traduit des adresses IP entre deux réseaux. Le PAT, souvent appelé surcharge NAT, ajoute la traduction des ports pour distinguer plusieurs connexions qui utilisent la même adresse publique. Pour un administrateur, comprendre cette différence évite beaucoup de diagnostics flous : un problème peut venir de la table de traduction, d’un port mal ouvert, d’une règle trop large ou d’un conflit entre deux services.

NAT et PAT : la différence à retenir

Le NAT, pour Network Address Translation, modifie l’adresse source ou destination d’un paquet lorsqu’il traverse un équipement réseau. Dans le cas le plus courant, un poste interne en adresse privée, par exemple 192.168.1.25, contacte un service Internet. Le routeur remplace cette adresse privée par l’adresse publique de la box, du routeur ou du pare-feu avant de transmettre le paquet.

Cette traduction ne change pas le besoin métier. Elle change seulement la manière dont le flux est présenté au réseau voisin.

Le PAT, pour Port Address Translation, va plus loin. Il ne se contente pas de changer l’adresse IP : il associe aussi un port source différent à chaque connexion. C’est ce mécanisme qui permet à dix, cinquante ou cinq cents appareils internes de sortir via une seule IP publique sans mélanger les réponses.

La distinction est simple : le NAT répond à la question “quelle adresse dois-je présenter ?”, tandis que le PAT répond aussi à “quelle session exacte dois-je retrouver au retour ?”. Cette nuance devient essentielle dès que plusieurs machines consultent le même service externe au même moment.

Pourquoi ces mécanismes existent encore dans les réseaux modernes

Le NAT a été massivement adopté pour économiser les adresses IPv4 publiques. Les plages privées définies pour les réseaux internes ne sont pas routées directement sur Internet. Elles peuvent donc être réutilisées dans des milliers d’entreprises, de foyers et de sites sans conflit global. Le routeur situé en bordure devient alors le point de passage entre l’espace privé et Internet.

IPv6 réduit théoriquement ce besoin, puisque l’espace d’adressage disponible est beaucoup plus vaste. Pourtant, les environnements réels restent hybrides. Beaucoup de réseaux d’entreprise gardent IPv4, utilisent des VPN, hébergent des services historiques ou s’appuient sur des équipements qui conservent des règles NAT. Le sujet ne disparaît donc pas avec une phrase sur IPv6.

Pour une équipe IT, le NAT a aussi un intérêt opérationnel : il permet de découpler le plan d’adressage interne de l’adresse publique fournie par l’opérateur. Si le fournisseur change, si un lien secondaire est ajouté ou si un site distant est raccordé, l’architecture interne n’a pas forcément besoin d’être renumérotée immédiatement.

Cette souplesse reste utile, mais elle doit être tracée. Une règle oubliée devient vite une hypothèse cachée.

Il faut cependant éviter un contresens fréquent. Le NAT n’est pas conçu comme une mesure de sécurité complète. Il rend les machines internes moins directement visibles dans certains scénarios, mais la sécurité vient surtout de la politique de filtrage, de la segmentation, des mises à jour, de l’authentification et de la supervision.

Ce tableau ne remplace pas les logs. Il donne seulement le vocabulaire minimal pour poser les bonnes questions.

Pour approfondir ce point, consultez le fonctionnement d’un VLAN sans complexifier le, qui traite plus précisément de comprendre le fonctionnement d’un vlan sans complexifier le réseau.

Ce qui se passe quand un poste sort vers Internet

Prenons un poste interne qui ouvre un site web. Le poste envoie un paquet vers l’adresse du serveur distant. Avant de quitter le réseau local, le paquet passe par la passerelle. Celle-ci remplace l’adresse privée source par son adresse publique, choisit ou conserve un port source selon la configuration, puis inscrit cette correspondance dans sa table de traduction.

Quand la réponse revient, l’équipement consulte cette table. Il sait que le paquet reçu sur telle adresse publique et tel port correspond à telle machine interne et à telle session. Il peut alors renvoyer la réponse au bon poste. Sans cette mémoire temporaire, le retour serait impossible à distribuer correctement.

La table NAT est donc une mémoire de sessions, pas une simple liste d’adresses à consulter après coup.

Cette mécanique explique pourquoi certains problèmes semblent intermittents. Si la table NAT est saturée, si les sessions expirent trop vite, si deux équipements traduisent successivement le même flux ou si le firewall journalise mal, l’utilisateur voit seulement “ça coupe”. L’administrateur doit alors retrouver la chaîne de traduction plutôt que regarder uniquement l’application.

Redirection de port : utile, mais jamais anodine

La redirection de port répond à un besoin inverse. Au lieu de permettre à un poste interne de sortir, elle autorise une connexion entrante vers un service précis : serveur web, VPN, bureau distant, outil métier ou équipement d’administration. Techniquement, l’équipement remplace la destination publique par une adresse privée interne et transmet le flux au service désigné.

Ce mécanisme est pratique, mais il crée une exposition. Une règle trop large, un port de gestion ouvert par habitude ou un service non mis à jour peuvent suffire à transformer un confort d’accès en faiblesse réelle. Dans une PME, la question n’est pas seulement “le port fonctionne-t-il ?”, mais “qui doit y accéder, depuis où, avec quelle authentification et pour quelle durée ?”.

La meilleure pratique consiste à publier le minimum nécessaire. Un accès VPN, un reverse proxy correctement configuré, une restriction par adresse source ou une authentification forte valent souvent mieux qu’un service exposé directement. Le NAT facilite le chemin ; le pare-feu doit décider si ce chemin est légitime.

Une règle entrante doit donc avoir une justification active. Sinon, elle doit être supprimée ou désactivée.

Les erreurs fréquentes dans une PME

La première erreur consiste à laisser s’accumuler des règles historiques. Une redirection créée pour un prestataire, un test ou une urgence reste parfois active pendant des années. Personne ne sait plus pourquoi elle existe, mais elle continue à exposer un service interne depuis Internet.

La deuxième erreur est le double NAT non documenté. Une box opérateur, un routeur Wi-Fi et un pare-feu peuvent traduire le même flux plusieurs fois. Pour la navigation simple, cela peut passer inaperçu. Pour un VPN, une téléphonie IP, un service publié ou certains outils métiers, le diagnostic devient beaucoup plus confus.

Dans ce cas, le premier travail consiste à retrouver l’équipement qui décide vraiment.

La troisième erreur touche aux ports. Deux services ne peuvent pas utiliser la même combinaison adresse publique/port/protocole sur la même interface. Quand une règle existante occupe déjà le port attendu, on contourne parfois le problème avec un port externe différent. Cette solution peut être acceptable, mais seulement si la documentation réseau suit.

Enfin, il ne faut pas confondre adresse privée et absence de risque. Un poste interne compromis peut initier des connexions sortantes, utiliser le PAT comme tous les autres et communiquer avec l’extérieur si le filtrage ne l’empêche pas. Le réseau a donc besoin d’une logique de sortie, pas seulement de règles entrantes.

1. Supprimer les redirections dont le propriétaire métier n’est plus identifié.
2. Éviter les interfaces d’administration exposées directement sur Internet.
3. Documenter chaque règle avec service, port, protocole, source autorisée et date de revue.
4. Journaliser les refus et les autorisations critiques.
5. Prévoir une revue après changement d’opérateur, de box ou de pare-feu.

Comment documenter proprement NAT, PAT et ports ouverts

Une documentation utile n’a pas besoin d’être longue. Elle doit simplement permettre à une autre personne de comprendre le flux sans appeler l’ancien administrateur. Pour chaque règle, indiquez l’adresse privée, l’adresse publique, le port interne, le port externe, le protocole, le service concerné, le propriétaire métier et la raison de l’exposition.

Le format compte moins que la régularité. Un tableau simple, maintenu à jour, vaut mieux qu’un schéma parfait oublié.

Ajoutez aussi la durée prévue. Certaines règles devraient être temporaires : maintenance, migration, accès prestataire, période de test. Si aucune date de revue n’est fixée, elles deviennent permanentes par inertie. C’est souvent là que naissent les écarts entre l’architecture supposée et la réalité de production.

Dans un contexte multi-sites ou télétravail, la documentation doit également préciser les dépendances : VPN, liens opérateurs, plages IP distantes, DNS, certificats, règles de routage et équipements intermédiaires. Un incident NAT ressemble rarement à une seule ligne de configuration défectueuse.

Un cas concret pour lire un flux sans se tromper

Imaginez une PME qui publie un portail métier interne pour quelques commerciaux nomades. Sur le papier, la règle paraît simple : port HTTPS entrant vers un serveur applicatif. Dans la réalité, le flux passe par une box opérateur, un pare-feu, un VLAN serveur, un reverse proxy et une authentification applicative. Si l’un de ces éléments applique une traduction ou une restriction non documentée, le diagnostic devient vite circulaire.

La bonne lecture commence par le sens du flux.

Depuis Internet, la requête arrive sur une adresse publique. La règle de destination l’oriente vers un équipement interne. Ensuite, une règle de filtrage autorise ou bloque le passage. Enfin, le serveur répond, et le retour doit suivre une route cohérente. Si la réponse repart par un autre lien opérateur, par un autre pare-feu ou sans traduction symétrique, l’utilisateur ne verra qu’une page qui charge mal.

Dans ce type de cas, l’équipe doit noter la source autorisée, la destination réelle, le port externe, le port interne, le protocole, la règle firewall associée et le chemin de retour. Ce n’est pas de l’administration excessive : c’est ce qui permet de corriger vite après un changement d’opérateur, une migration de serveur, un nouveau VPN ou un durcissement de sécurité. Sans cette trace, chaque incident oblige à redécouvrir l’architecture.

Un test utile reste très concret : lancer une connexion depuis une source connue, vérifier la règle touchée dans les logs, confirmer l’arrivée sur le service interne, puis contrôler le chemin retour. Ce test en quatre points sépare le problème NAT du problème applicatif, DNS ou certificat.

Il faut aussi décider ce qui ne doit jamais être publié directement.

Les interfaces d’administration, les consoles de sauvegarde, les hyperviseurs, les partages de fichiers et les accès RDP méritent une protection supplémentaire, généralement via VPN, bastion, restriction d’adresse ou solution d’accès dédiée. Une redirection fonctionnelle n’est pas une validation d’architecture. Le vrai critère est le niveau d’exposition acceptable pour le service concerné.

Ce qu’il faut retenir avant de modifier une règle

Le NAT et le PAT sont des mécanismes de traduction, pas des boîtes noires magiques. Ils rendent possible le partage d’une adresse publique, facilitent l’organisation d’un réseau IPv4 et permettent certains accès entrants, mais ils doivent rester lisibles. Dès qu’une règle n’a plus de propriétaire, de justification ou de trace dans les logs, elle devient une dette réseau.

Avant toute modification, partez du flux métier : qui initie la connexion, vers quel service, depuis quelle source, avec quel niveau d’exposition acceptable ? Ensuite seulement, traduisez ce besoin en NAT, PAT, redirection ou règle de filtrage. Cette méthode évite de “tester des ports” au hasard et maintient une architecture que l’équipe pourra reprendre sans improviser.

La priorité est simple : gardez les règles nécessaires, supprimez les exceptions oubliées et documentez chaque passage entre privé et public.

Pour approfondir ce point, consultez windows smb, qui traite plus précisément de windows smb, comprendre le partage de fichiers sans exposer le réseau.