Maintenant, nous savons comment sélectionner les paquets à marquer. Pour terminer notre règle, nous devons préciser au noyau ce qu'il doit faire des paquets.
Vous voulez effectuer du NAT de source ; c'est-à-dire changer l'adresse source des connexions en quelque-chose d'autre. Ceci est réalisé dans la chaîne POSTROUTING, juste avant que le paquet ne soit définitivement envoyé à l'extérieur ; c'est une remarque d'importance, car elle signifie que toute autre fonction sur votre machine sous Linux (routage, filtrage de paquets) verra le paquet non modifié. Cela signifie aussi que l'option `-o' (interface de sortie) peut être utilisée.
Le NAT de source est spécifié en utilisant les options `-j SNAT', et `--to-source' qui spécifie une adresse IP, une plage d'adresses IP, et éventuellement un port ou une plage de ports (pour les protocoles UDP et TCP seulement).
## Changer l'adresse source en 1.2.3.4
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
## Changer l'adresse source en 1.2.3.4, 1.2.3.5 ou 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
## Changer l'adresse source en 1.2.3.4, port 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
C'est un cas spécial de NAT de source appelé camouflage d'adresse IP : il devrait seulement être utilisé pour des adresses IP allouées dynamiquement, comme pour des connexions téléphoniques standardes (pour les adresses IP statiques, utilisez le SNAT ci-dessus).
Vous n'avez pas besoin de spécifier l'adresse source explicitement avec le camouflage : il utilisera l'adresse source de l'interface par laquelle le paquet sort. Mais plus important, si le lien est rompu, les connexions (qui sont de toute façon perdues) sont oubliées, ce qui évite des problèmes éventuels quand la connexion est rétablie avec une nouvelle adresse IP.
## Camoufler tout ce qui sort par ppp0
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Ceci est réalisé dans la chaîne PREROUTING, au moment où le paquet arrive ; cela signifie que toute autre fonction de votre machine sous Linux (routage, filtrage de paquets) verra le paquet aller vers sa destination `réelle'. Cela signifie aussi que l'option `-i' (interface d'entrée) peut être utilisée.
Le NAT de destination est spécifié en utilisant `-j DNAT', et l'option `--to-destination' spécifie une adresse IP, une plage d'adresses IP, et éventuellement un port ou une plage de ports (pour les protocoles UDP et TCP seulement).
## Changer l'adresse de destination en 5.6.7.8
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8
## Changer l'adresse de destination en 5.6.7.8, 5.6.7.9 ou 5.6.7.10
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8-5.6.7.10
## Changer l'adresse de destination du trafic web en 5.6.7.8, port 8080
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \
-j DNAT --to 5.6.7.8:8080
Il y a un cas spécialisé de NAT de destination appelé redirection : c'est une simple facilité qui est exactement équivalente à faire du DNAT vers l'adresse de l'interface d'entrée.
## Envoyer le trafic web entrant du port-80 vers notre mandataire (transparent) Squid
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j REDIRECT --to-port 3128
Notez que Squid doit être configuré pour jouer le rôle de mandataire transparent !
Il y a plusieurs subtilités du NAT que la plupart des gens n'auront jamais à utiliser. Elles sont documentées ici pour les curieux.
Si une plage d'adresses IP est donnée, l'adresse choisie est basée sur l'adresse la moins utilisée, pour les connexions que la machine connaît. Ceci donne un équilibrage de charge grossier.
Vous pouvez utiliser la cible `-j ACCEPT' pour laisser passer une connexion sans réaliser de NAT.
Le comportement par défaut essaie de modifier la connexion le moins possible, en respectant les contraintes de la règle définie par l'utilisateur. Cela veut dire qu'on ne redirige pas les ports à moins d'y être forcé.
Même quand aucun NAT n'est demandé pour une connexion, une transformation de port source peut être implicitement effectuée, si une autre connexion a déjà été engagée avant la nouvelle. Considérons le cas du camouflage qui est plutôt courant :
Quand cette correspondance implicite de source se produit, les ports sont répartis en 3 classes :
Un port ne sera jamais implicitement mis en correspondance dans une autre classe que la sienne.
S'il n'y a aucune façon de mettre en correspondance la connexion quand l'utilisateur le demande, elle sera abandonnée. Ceci s'applique aussi aux paquets ne pouvant être associés à une connexion, parce qu'ils sont malformés ou parce que la machine est saturée en mémoire, etc...
Vous pouvez avoir des règles de NAT qui mettent en correspondance des paquets sur la même plage ; le code du NAT est suffisamment malin pour éviter les collisions. Donc avoir deux règles qui mettent en correspondance les adresses sources 192.168.1.1 et 192.168.1.2 avec 1.2.3.4 fonctionnera.
De plus, vous pouvez mettre en correspondance des adresses IP réelles utilisées, à partir du moment où ces adresses passent par la machine effectuant cette mise en correspondance. Ainsi, si vous avez un réseau assigné (1.2.3.0/24), avec un réseau interne utilisant ces adresses et un autre utilisant des adresses privées (192.168.1.0/24), vous pouvez simplement faire du NAT des adresses sources 192.168.1.0/24 vers le réseau 1.2.3.0 sans crainte de collisions :
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0/24
La même logique s'applique aux adresses utilisées par la machine effectuant elle-même le NAT : c'est comme cela que le camouflage fonctionne (en partageant l'adresse de l'interface entre des paquets camouflés et des paquets `réels' venant de la machine elle-même).
De plus, vous pouvez mettre en correspondance les mêmes paquets sur différentes cibles et ils seront répartis. Par exemple, si vous ne voulez rien mettre en correspondance sur 1.2.3.5, vous pouvez utiliser :
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254
Le code du NAT vous permet d'insérer des règles de DNAT dans la chaîne OUTPUT, mais ceci n'est pas complètement soutenu dans le noyau 2.4 (il pourrait l'être, mais il nécessite une nouvelle option de configuration, quelques tests, et un bon morceau de code. Ainsi, à moins que quelqu'un n'engage Rusty pour l'écrire, je ne le prévois pas de sitôt).
La limitation actuelle vient du fait que vous ne pouvez modifier la destination que vers la machine locale (par exemple `j DNAT --to 127.0.0.1'), et vers aucune autre machine, sinon les réponses ne seront pas traduites correctement.