====== La table de translation d'adresses ======


===== Remarques importantes =====

La traduction d'adresse (NAT comme Network Address Translation) est à prendre ici au sens le plus large, puisque cette table permet non seulement de faire de la translation stricte d'adresses, mais également de la translation de ports et un mélange des deux, dont le masquage d'adresse est une forme particulière.

==== Mais qu'est-ce que c'est exactement ? ====

Dans un datagramme, en plus des données, on trouve également quelques informations concernant le protocole utilisé et des identificateurs de l'émetteur et du destinataire. Ce sont ces identificateurs qui nous intéressent:

  * L'adresse IP du destinataire.
  * Le port du service utilisé sur le destinataire.

Ces informations constituent une « socket », elles sont indispensables pour arriver à joindre le bon service sur le bon serveur, par exemple le service HTTP du serveur [[http://www.grenouille.com|grenouille.com]].

  * L'adresse IP de l'émetteur.
  * Le port de réponse.

> Ces informations constituent une autre « socket », elles sont indispensables pour que l'émetteur d'un paquet puisse espérer recevoir une réponse.

Avec les fonctions NAT de Netfilter, lorsqu'un paquet transite par notre passerelle, nous allons pouvoir bricoler ces sockets absolument comme on le désire. Par exemple, nous pourrons changer l'adresse de l'émetteur ou le port de l'émetteur ou les deux. Nous pouvons aussi changer l'adresse du destinataire, ou le port du destinataire, ou les deux.

==== Mais à quoi ça sert ? ====

Ca sert à une quasi infinité de choses. Parmi les plus intéressantes, citons:

=== Le masquage d'adresse ===

C'est une fonction fondamentale lorsque l'on souhaite connecter un réseau privé à l'Internet lorsque l'on ne dispose que d'une seule IP valide sur le Net, même si celle-ci est dynamique, ce qui est le cas qui nous intéresse le plus. Les clients sont sur le réseau privé et les serveurs sont sur le Net. C'est une forme particulière de SNAT (Source NAT)

C'est ce que sont capables de faire tous les routeurs SOHO (Small Office, Home Office) qui permettent de relier un petit réseau local à l'Internet, lorsque l'on ne dispose que d'un accès RTC, NUMERIS, Câble, ADSL... Un simple (très) vieux PC (un 486 suffit) équipé d'un Linux 2.6.x permet de le faire aussi bien sinon mieux.

=== Le NAT de destination ===

Ici, c'est pour résoudre les problèmes qui apparaissent dans l'autre sens. Les clients sont sur le Net et les serveurs sont sur le réseau privé.

Imaginons que nous n'ayons qu'une seule IP valide sur le Net et que nous voulions tout de même offrir des services tels que HTTP, FTP, SMTP, POP et peut-être d'autres encore. Comment faire ? La réponse triviale consiste à dire: "J'ai droit à une seule IP, donc je place tous ces serveurs sur la même machine, celle qui a la seule IP à laquelle j'ai droit."

{{ :netfilter:nat1.gif| Le cas typique}}
Oui, mais la démarche est simpliste:
  * Comment assurer un minimum de sécurité sur une machine ouverte de tous les côtés ?
  * Comment faire pour assurer une disponibilité suffisante à chaque service dans les montées en charge ?

Cette solution ne parait finalement pas très acceptable, mais comment faire autrement ? Tout simplement avec NAT. La machine frontale sera un simple routeur NAT. Côté Internet, elle possède la seule IP valide disponible, elle va faire croire que tous les services sont dessus, mais en réalité, lorsqu'elle va recevoir un paquet dont le socket de destination est 62.161.96.47:80, elle va remplacer ça vite fait par 192.168.0.1:80 et router le paquet vers le serveur HTTP. Lorsque la réponse du serveur va lui parvenir, elle remplacera le socket de l'émetteur (192.168.0.1:80) par 62.161.96.47:80 et enverra ça sur le Net. Tout le monde n'y verra que du feu.

Bien entendu, le routeur NAT est capable de faire ça pour chacun des autres serveurs:

  * Ce qui lui arrivera sur les ports 20 et 21 sera redirigé sur le serveur FTP (en réalité, le cas du FTP est bien plus difficile à résoudre que ça. Il faudra d'abord lire le chapitre sur FTP).
  * Ce qui lui arrivera sur le port 25 sera redirigé sur le serveur SMTP/POP3 service SMTP
  * Ce qui lui arrivera sur le port 110 sera redirigé sur le serveur SMTP/POP3 service POP3

=== Le cas du proxy transparent ===

Bien qu'à priori, cette possibilité soit sans intérêt sur un réseau domestique, je préfère en parler parce que ce sujet peut revêtir une certaine gravité quant aux atteintes aux libertés individuelles.

Tout le monde sait ce qu'est un proxy (serveur mandataire, en français) ? C'est un serveur auquel on s'adresse pour qu'il nous fournisse des informations situées sur un autre serveur, sur les protocoles HTTP et FTP essentiellement.. Le principal avantage d'un proxy est qu'il garde en mémoire dans un cache toutes les informations qu'il est déjà allé chercher. Si, sur un réseau privé, 10 personnes cherchent la même information, elle ne sera téléchargée qu'une fois sur le Net. L'avantage évident est l'optimisation de la bande passante sur le lien Internet, lorsque le réseau privé est un peu conséquent. L'autre avantage, c'est que l'on peut réaliser un « firewall applicatif » pour le protocole HTTP. Dans ce cas, on n'utilisera plus seulement un filtrage de paquets, mais également un filtrage sur le protocole lui-même, ce qui permet, par exemple, de faire du contrôle parental ou du contrôle de trafic web tout court.

Face à cet avantage, il y a pas mal d'inconvénients, dus  à tous les effets pervers des fonctionnalités que l'on peut ajouter à un proxy. Parmi les inconvénients les plus graves:

  * La durée de vie du cache peut être mal paramétrée, la vérification de validité du contenu également et le proxy peut fournir des informations qui ne sont plus à jour.
  * Les proxys ont souvent des fonctions de restriction d'accès qui peuvent aboutir à un régime franchement totalitaire. (Contrôle parental chez AOL, par exemple, mais ce n'est pas forcément vous qui choisissez les filtrages).
  * Les fonctions de traçage ne manquent pas non plus, ce qui permet d'espionner de façon très efficace ce que les utilisateurs de votre réseau font sur le Net.

Normalement, le navigateur Internet doit être paramétré pour utiliser un serveur proxy (outils/Options Internet/Connexions/Paramètres LAN dans Internet Explorer). Si l'installation est faite proprement, l'utilisateur devrait pouvoir choisir d'utiliser le proxy ou non. Souvent cependant, l'administrateur du réseau va bloquer le passage direct sur le port 80, obligeant les utilisateurs à passer par le proxy. Là encore, au moins, les utilisateurs sont avertis.

Le proxy transparent est beaucoup plus pernicieux, parce qu'il ne nécessite aucun paramétrage du navigateur et l'utilisateur ne sait pas qu'il passe par un proxy.

Le principe est simple, il suffit de rediriger tous les paquets dont le port de destination est 80 vers le proxy transparent, qui peut être placé sur la passerelle elle même. Ceux qui disposent d'une passerelle Linux peuvent assez facilement monter la manip en installant le proxy SQUID (configuré convenablement pour faire un proxy transparent) et en utilisant iptables pour faire de la redirection sur le service squid local.

Si vous voulez plus de détails sur ces pratiques qui flirtent avec le douteux, visitez |e chapitre consacré à HTTP.

Ce ne sont pas les seules manipulations possibles, mais ce sont celles qui paraissent les plus souvent utilisées.

===== Et comment ça marche ? =====

{{:netfilter:tablenat.gif |Le pré-routage}}
La table NAT est organisée comme ci-contre:
  * Comme son nom l'indique, la chaîne PREROUTING va bricoler les « sockets » avant les décisions de routage. Nous nous en servirons pour faire du DNAT (Destination NAT), autrement dit, pour modifier la « socket » du destinataire. ;

  * la chaîne POSTROUTING intervient à la sortie du routeur. Elle servira à faire du SNAT (Source NAT) dont par exemple, le masquage d'adresse ;

  * la chaîne OUTPUT, quant-à elle, permet de modifier le socket de destination d'un paquet issu d'un processus local. L'utilité de cette chaîne n'est pas évidente, dans la mesure où, normalement, les paquets sortant d'un processus local devraient aussi passer par POSTROUTING. La seule possibilité supplémentaire est de pouvoir rediriger les paquets qui sortent d'un processus local à destination d'une cible extérieure, vers un autre processus local (127.0.0.1). |

<html><div style="clear: both;"></div></html>
Là encore, nous pouvons l'illustrer de façon différente :

{{ :netfilter:nat2.gif |}}

Les possibilités offertes par le NAT sont quasiment infinies. Nous avons vu les plus fréquentes :

  * Masquage d'adresse, pour permettre à tout un réseau privé d'accéder au Net lorsque l'on ne dispose que d'une seule adresse IP valide sur le Net,
  * redirection d'un service serveur adressé sur la passerelle vers un serveur situé dans le réseau privé, ça peut être utile pour les joueurs en réseau, mais aussi pour des applications plus professionnelles.

Pour que tout ça fonctionne correctement, le système s'appuie sur le suivi de connexion. Nous pouvons donc nous attendre à trouver des modules spécialisés pour certains protocoles, dont le FTP, toujours lui. Ainsi, le module ''nf_nat_ftp'' sera nécessaire si vous voulez travailler proprement en FTP.