Maintenant nous savons comment selectionner les paquets a modifier. Pour completer notre règle, nous devons dire au noyau exactement ce qu'il doit faire avec les paquets.
Tu veux effectuer du NAT Source; changer l'adresse source des connections en quelque chose de différent. Ceci est réalisé dans la chaine POSTROUTING, juste avant que il ne soit finallement envoyé; c'est un détail important, car il veut dire que tout sur la machine linux elle-mème (routage, filtrage de paquets) verra le paquet non modifié. Ca veut aussi dire que l'option `-o' (interface de sortie) peut ètre utilisée.
Le NAT Source est spécifié en utilisant les options `-j SNAT', et `--to-source' qui spécifie une adresse IP, un bloc d'adresses IP, et un port ou un bloc de ports optionnels (pour 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 SNAT appelé masquerading: il devrait seulement ètre utilisé pour des adresses ip assignées dynamiquement, comme des connections standard ( pour les adresses IP statiques, utilises SNAT).
Tu n'as pas besoin de specifier l'adresse source explicitement avec le masquerading: il utilisear l'adresse source de l'interface par laquelle le paquet sort. Mais plus important, si le lien est déconnecté, les connections (qui sont de toutes facons perdues) sont oubliées, ce qui evite des problèmes éventuels quand la connection est rétablie avec une nouvelle adresse IP.
## Masquerader tout ce qui sort par ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Ceci est réalisé dans la chaine PREROUTING, juste comme le paquet arrive; cela veut dire que tout le reste sur la machine Linux (routage, filtrage de paquets) va voir le paquet aller vers sa destination `réelle'. Cela veut aussi dire que l'option `-i' (interface d'entrée) peut ètre utilisée.
Pour altérer la destination de paquets générés locallement, la chaine OUTPUT peut ètre utilisée, mais c'est moins courant.
Le NAT de Destination est spécifié en utilisant `-j DNAT', et l'option `--to-destination' spécifie une adresse ip, un bloc d'adresses IP, et un port ou un bloc de ports optionnels (pour les protocoles UDP et TCP seulement).
## Changer l'adresse de destination en 5.6.7.8
# iptables -t nat -A PREROUTING -i eth1 -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 eth1 -j DNAT --to 5.6.7.8-5.6.7.10
## Changer l'adresse de destination du traffic web en 5.6.7.8, port 8080.
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \
-j DNAT --to 5.6.7.8:8080
## Rediriger les paquets locaux destinés a 1.2.3.4 en loopback.
# iptables -t nat -A OUTPUT -d 1.2.3.4 -j DNAT --to 127.0.0.1
Il y a un cas spécialisé de NAT de Destination appelé redirection: c'est une simplification qui est exactement équivalente a faire du DNAT vers l'adresse de l'interface d'entrée.
## Envoyer le traffic web entrant du port port-80 vers notre proxy (transparent) squid
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j REDIRECT --to-port 3128
Il y a plusieurs subtilités du NAT que la pluspart des gens n'auront jamais a utiliser. Elles sont documentées ici pour les curieux.
Si un bloc d'adresses IP est donné, l'adresse IP a utiliser est choisie sur la base de l'adresse dernièrement utilisée pour les connectiosn que la machine connait. Cela donne du load-balancing primitif.
Tu peux utiliser la cible `-j ACCEPT' pour laisser une connection passer sans réaliser de NAT.
Le comportement par défaut est d'altèrer la connection aussi peu que possible, dans les contraintes de la règle définie par l'utilisateur. Cela veut dire qu'on ne redirige pas les ports a moins d'y ètre forcé.
Mème quand aucun NAT n'est requis pour une connection, une translation de port source peut ètre implicitement effectuée, si une autre connection a été mappée au dessus de la nouvelle. Considerons le cas du masquerading qui est plutot commun:
Quand ce mapping de source implicite est effectué, les ports sont divisés en 3 classes:
Un port ne sera jamais implicitement mappé dans une classe différente.
Si il n'y a pas de possibilité de mapper la connection quand l'utilisateur la demande, on la laisse tomber. Ceci s'applique aussi aux paquets qui ne peuvent pas ètre classifiés comme une partie d'une connection, parce qu'ils sont malformés, ou que la machine est saturée en mémoire, etc.
Tu peux avoir des règles NAT qui mappent des paquets sur le mème bloc; le code NAT est assez propre pour éviter les Clashs. Donc avoir deux règles qui mappent les adresses source 192.168.1.1 et 192.168.1.2 respectivement sur 1.2.3.4 fonctionnera.
Encore mieux, tu peux mapper des adresses IP réelles utilisées, aussi longtemps que ces adresses passent par la machine qui réalise le mapping. Donc si tu as un réseau assigné (1.2.3.0/24), et un réseau interne utilisant ces adresses et un réseau utilisant des adresses internet privées 192.168.1.0/24, tu peux simplement NAT les adresses sources 192.168.1.0/24 sur le réseau 1.2.3.0, sans peur de clasher:
# 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 est appliquée aux adresses utilisées par la machine NAT elle-mème: c'est comme ca que le masquerading fonctionne (en partagant l'adresse de l'interface entre des paquets masqueradés et des paquets `réels' venant de la machine elle-mème).
De plus, tu peux mapper les mèmes paquets sur différentes cible et ils seront partagés. Par exemple, si tu ne veux pas mapper quelquechose sur 1.2.3.5, tu peux 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
Si la destination d'un paquet généré locallement est changée (pe. par la chaine OUTPUT), et que cela fait passer le paquet sur une interface différente, alors l'adresse source est aussi changée en celle de cette interface. Par exemple, changer la destination d'un paquet de loopback pour sortir par eth0 résultera dans la source de ce paquet qui sera altérée de 127.0.0.1 en l'adresse de eth0; contrairement a d'autres mappings de source, ceci est fait immédiatement. Naturellement, ces deux mappings sont inversés sur les paquets de réponses qui reviennent.