Netfilter et IPtables
09/02/2005
 Christian CALECA 
Liste des cours

NAT

Accueil ] [ Architecture ] [ Conntrack ] [ Filter ] [ NAT ] [ Et le reste ] [ iptables ]


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:

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 www.wanadoo.fr.

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 veut. 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.4.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."

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.

schéma

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

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:

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 le 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 ?

organigramme 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).

Là encore, nous pouvons l'illustrer de façon différente :

schéma

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

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 ip_nat_ftp sera nécessaire si vous voulez travailler proprement en FTP.


Précédente ] [ Accueil ] [ Suivante ]