Linux 2.4 NAT HOWTO
Rusty Russell, liste d'email netfilter@lists.samba.org
Traduit par emmanuel Rogerflynux@freegates.be
v1.0.1 Lundi 1er Mai 18:38:22 CST 2000, traduction du 28
aout 2000
Ce document décrit comment réaliser du masquerading, un proxy trans-
parent, de la redirection de ports, et d'autres formes de Network
Address Translations (Translation d'addresses réseaux) avec le Noyau
Linux 2.4 .
______________________________________________________________________
Table des matières
1. Introduction
2. Où se trouvent les site web officiels et la liste de mail ?
2.1 Qu'est ce que Network Address Translation?
2.2 Pourquoi Voudrais-Je Utiliser du NAT?
3. Les Deux Types de NAT
4. Rapide traduction des noyaux 2.0 et 2.2
4.1 Au secours! je veux juste du masquerading!
4.2 Et pour ipmasqadm?
5. Controller quoi il faut NATer
5.1 Sélection simple en utilisant iptables
5.2 Affinage Des Points De Sélection Des Paquets A Modifier
6. Specifier Comment Modifier Les Paquets
6.1 NAT Source
6.1.1 Masquerading
6.2 NAT De Destination
6.2.1 Redirection
6.3 Mappings En Profondeur
6.3.1 Selection D'adresses Multiples Dans Un Bloc
6.3.2 Créer Des Mappings De Null NAT
6.3.3 NAT Standard
6.3.4 Mapping De Port Source Implicite
6.3.5 Que Se Passe-t-il Quand Le NAT Foire ?
6.3.6 Mappings Multiples, Dépassements et Clashs
6.3.7 Altération de la Destination de Connections Générées Locallement
7. Protocoles Spéciaux
8. Considérations sur le NAT
9. NAT Source et Routage
10. NAT de Destination Sur le Mème Réseau
11. Remerciements
______________________________________________________________________
[1m1. Introduction[0m
Bienvenue, gentil lecteur.
Tu es sur le point de decouvrir le monde fascinant (et parfois
horrible) du NAT : Network Address Translations (Translation
d'addresses réseaux), et ce COMMENT-FAIRE vas être ton guide plus ou
moins précis du Noyau Linux 2.4 et supérieurs.
Dans Linux 2.4, une infrastructure appelée 'netfilter' a été
introduite pour modifier les paquets. Une couche au dessus de ceci
fournit le NAT, complètement réimplémenté depuis les noyaux
précédents.
(C) 2000 Paul `Rusty' Russell. Sous license GNU GPL.
[1m2. Où se trouvent les site web officiels et la liste de mail ?[0m
Voici les trois sites officiels:
· Merci à Filewatcher .
· Merci à l'équipe de samba et SGI .
· Merci à Harald Welte .
Pour la liste email officielle de netfilter: liste de netfilter
.
[1m2.1. Qu'est ce que Network Address Translation?[0m
Normalement, les paquets sur un réseau voyagent de leur source (par
exemple ton ordinateur de bureau) à leur destination (par exemple
www.gnumonks.org) à travers différents liens : environ 19 d'où je suis
en Australie. Aucun de ces liens n'altèrent vraiment ton paquet : ils
le renvoient juste plus loin.
Si un de ces liens effectuait du NAT, alors il altèrerait la source ou
la destination du paquet pendant qu'il passe. Comme on peut
l'imaginer, ce n'est pas comme ca que le système a été construit pour
fonctionner, et le NAT est toujours quelque chose de foireux.
Générallement le lien qui effectue du NAT va se rappeler comment il a
modifié le paquet, et quand une réponse passera dans l'autre sens, il
effectuera la modification inverse sur ce paquet de réponse, pour que
tout fonctionne bien.
[1m2.2. Pourquoi Voudrais-Je Utiliser du NAT?[0m
Dans un monde parfait, tu ne devrais pas. Autrement les raisons
principales sont :
[1mLes Connections par Modem à Internet[0m
La pluspart des FAI te donnent une seule addresse quand tu te
connecte chez eux. Tu peux envoyer des paquets avec l'adresse
source que tu veux, mais seules les réponses avec ta propre
addresse IP te seront envoyées. Si tu veux utiliser plusieurs
machines différentes (comme un réseau personnel) pour te
connecter à internet à travers cette seule connection, tu as
besoin du NAT.
C'est de loin l'utilisation la plus fréquente du NAT de nos
jours, généralement connue sous le nom de 'masquerading' dans le
monde Linux. J'appelles ca SNAT, parce que tu changes
l'addresse [1msource [22mdu premier paquet.
[1mServeurs Multiples[0m
Parfois tu veux changer l'endroit où des paquets dirigés vers
ton réseau doivent aller. Fréquemment c'est parce que (comme ci-
dessus), tu as seulement une seule addresse IP, mais tu veux
qu'on puisse accèder aux machines qui se trouvent derrière celle
avec l'adresse IP `réelle'. Si tu réécrit la destination des
paquets entrants, tu peux le faire.
Une variation commune de ceci est le load-sharing (partage de
saturation), où le paquet est distribué à une machine parmis un
ensemble. Ce type de NAT etait appelé port-forwarding sous les
versions précédentes de Linux.
[1mProxy Transparent[0m
Parfois tu veux prétendre que chaque paquet qui passe à travers
ta machine Linux est destiné à un programme sur cette machine
même. Ceci est utilisé pour réaliser des proxy transparents : un
proxy est un programme qui se trouve entre ton réseau et le
monde extérieur, établissant la communication entre les deux.
La partie transparente c'est le fait que ton réseau ne sache
mème pas qu'il est en train de parler à un proxy, à moins
évidemment que le proxy ne fonctionne pas.
Squid peut être configuré pour fonctionner de cette manière, et
c'est appelé redirection ou proxy transparent dans les versions
précédentes de Linux.
[1m3. Les Deux Types de NAT[0m
Je divise le NAT en deux types différents : le [1mNAT Source [22m(SNAT) et le
[1mNAT Destination [22m(DNAT).
Le NAT Source c'est quand on altère l'adresse source du premier paquet
: par exemple. Tu changes l'endroit dont la connection provient. Le
NAT Source est toujours réalisé après le routage, juste avant que le
paquet ne sorte sur la ligne. Le Masquerading est une forme
spécialisée de SNAT.
Le NAT Destination c'est quand on altère l'adresse de destination du
premier paquet : par exemple. Tu changes l'endroit où la connection va
aboutir. Le NAT Destination est toujours effectué avant le routage,
quand un paquet arrive en premier sur la ligne. Le Port forwarding,
load-sharing et le proxy transparent sont tous des formes de DNAT.
[1m4. Rapide traduction des noyaux 2.0 et 2.2[0m
Désolé pour tout ceux d'entres vous qui sont toujours choqués par la
transition du 2.0 (ipfwadm) au 2.2 (ipchains). Il y a de bonnes et de
mauvaises nouvelles.
Premièrement, tu peux toujours utiliser ipchains et ipfwadm comme
avant. Pour faire cela tu aurais besoin d'inserer le module
'ipchains.o' ou 'ipfwadm.o' trouvé dans la dernière distribution de
netfilter. Ils sont mutuellement exclusifs (tu as été prévenu), et ne
doivent pas êtres combinés avec aucun autre module netfilter.
Une fois que ces modules sont installés, tu peux utiliser ipchains et
ipfwadm comme d'habitude, avec les différences suivantes:
· Configurer les temps limites de masquerading avec ipchains -M -S,
or ipfwadm -M -s ne fait rien. De toutes facons les temps limites
sont plus long pour la nouvelle infrastructure NAT, donc ca n'a pas
d'importance.
· Les champs init_seq, delta et previous_delta dans le masquerading
détaillé sont toujours à zéro.
· Mettre les compteurs à zéro et les lister en mème temps `-Z -L' ne
fonctionne plus : les compteurs ne seront pas remis à zéro.
Les hackers noteront aussi:
· Tu peux à présent utiliser les ports 61000-65095 mème si tu
effectues du masquerading. Le code de masquerading utilisé pour
présumer que tout ce qui se trouvait dans cette limite était
foireux, donc les programmes ne pouvaient l'utiliser.
· Le hack (non documenté) `getsockname', que les programmes de proxy
transparents pouvaient utiliser pour trouver la destination réelle
des connections ne fonctionne plus.
· Le hack (non documenté) bind-to-foreign-address n'est plus non plus
implémenté; c'était utilisé pour completer l'illusion de proxy
transparent.
[1m4.1. Au secours! je veux juste du masquerading![0m
C'est ce que la pluspart des gens veulent. Si tu as une connection PPP
IP allouée dynamiquement (si tu sais pas, c'est ce que tu as), tu veux
simplement dire à ta machine que tout les paquets qui viennent de ton
réseau interne doivent être fait pour avoir l'air de venir de la
machine qui effectue la connection PPP.
# Charger le module NAT (ca charge tout les autres).
modprobe iptable_nat
# Dans la table NAT (-t nat), ajouter une règle (-A) après le routage
# (POSTROUTING) pour tout les paquets qui sortent par ppp0 (-o ppp0) qui dit
# de MASQUERADER la connection (-j MASQUERADE).
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
# Activer le passage IP
echo 1 > /proc/sys/net/ipv4/ip_forward
Notes que tu ne vas effectuer aucun filtrage de paquet ici : pour
cela, lis le Packet Filtering HOWTO : 'Mixer le NAT et le Filtrage de
Paquets'.
[1m4.2. Et pour ipmasqadm?[0m
C'est une catégorie d'utilisateurs beaucoup plus restreinte, donc je
ne m'attache pas à la compatibilité à ce point la. Tu peux simplement
utiliser `iptables -t nat' pour effectuer du port forwarding. Donc
par exemple, dans Linux 2.2 tu aurais tapé :
# Linux 2.2
# Passer les paquets TCP destinés au port 8080 de 1.2.3.4 au port 80 de 192.168.1.1
ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80
Maintenant tu devrais faire :
# Linux 2.4
# Ajouter une régle de pré-routage (-A PREROUTING) à la table NAT (-t nat) qui
# redirige les paquets TCP (-p tcp) destinés au port 8080 de 1.2.3.4 (-d 1.2.3.4) (--dport 8080)
# vers le port 80 de (-j DNAT) 192.168.1.1
# (--to 192.168.1.1:80).
iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 8080 \
-j DNAT --to 192.168.1.1:80
Si tu veux que cette règle altère les connections locales aussi (
p.e., même sur la machine NAT elle-mème, essayer de telneter le port
8080 de 1.2.3.4 te mettra sur le port 80 de 192.168.1.1), tu peux
insérer la même règle dans la chaine OUTPUT ( qui est pour les paquets
locaux sortants) :
# Linux 2.4
iptables -A OUTPUT -t nat -p tcp -d 1.2.3.4 --dport 8080 \
-j DNAT --to 192.168.1.1:80
[1m5. Controller quoi il faut NATer[0m
Tu dois créer des règles de NAT qui disent au kernel quelles
connections changer, et comment les changer. Pour faire cela, nous
utilisons l'outil très versatile iptables, et lui disons d'altèrer la
table NAT en specifiant l'option -t nat.
La table des règles de NAT contient 3 listes appelées `chaines':
chaque règle est examinée dans l'ordre jusqu'à ce qu'une convienne.
Les trois chaines sont appelées PREROUTING (pour le NAT de
destination, lorsque le paquet arrives), POSTROUTING (pour le NAT de
source, lorsque le paquet part), et OUTPUT (pour le NAT de destination
des paquets localement générés).
Le diagramme suivant devrait illustrer pas mal si j'avais un peu de
talent artistique:
_____ _____
/ \ / \
PREROUTING -->[décision]----------------->POSTROUTING----->
\D-NAT/ [de routage] \S-NAT/
| ^
| __|__
| / \
| | OUTPUT|
| \D-NAT/
| ^
| |
-------->Processus local------
A chacun des points ci dessus, quand un paquet passe nous regardons a
quelle connection il est associé. Si c'est une nouvelle connection,
nous regardons la chaine correspondante dans la table NAT pour voir
quoi faire avec lui. La réponse donnée sera appliquée à tous les
paquets futurs de cette connection.
[1m5.1. Sélection simple en utilisant iptables[0m
iptables a un nombre d'options standards comme listées ci-dessous.
Toutes les options avec un double tiret peuvent être abbrégées, aussi
longtemps que iptables peut les différencier des autres options
possibles. Si ton kernel a un support iptables comme module, tu devras
charger le module iptables.o en premier : `insmod ip_tables'.
L'option la plus importante ici est la sélection de table, `-t'. Pour
toutes les operations de NAT, tu devras utiliser `-t nat' pour la
table NAT. La seconde option la plus importante à utiliser est `-A'
pour ajouter une nouvelle règle à la fin de la chaine (pe. `-A
POSTROUTING'), ou `-I' pour en insérer une au début (pe. `-I
PREROUTING').
Tu peux specifier la source (`-s' ou `--source') et la destination
(`-d' ou `--destination') du paquet que tu veux NAT. Ces options
peuvent être suivies d'une seule adresse ip (p.e. 192.168.1.1), un nom
(p.e. www.gnumonks.org), ou une adresse de réseau (p.e. 192.168.1.0/24
ou 192.168.1.0/255.255.255.0).
Tu peux specifier une interface d'entrée (`-i' ou `--in-interface') ou
de sortie (`-o' ou `--out-interface') qui convient, mais celle que tu
peux specifier dépend dans quelle chaine tu mets la règle : au
PREROUTING tu peux seulement selectionner une interface d'entrée, et
au POSTROUTING (et OUTPUT) une de sortie. Si tu utilises la mauvaise,
iptables retournera une erreur.
[1m5.2. Affinage Des Points De Sélection Des Paquets A Modifier[0m
J'ai dit plus haut que tu pouvais specifier une adresse source et
destination. Si tu omets l'adresse source, alors toutes les adresses
sources conviendront. Si tu omets l'adresse destination, alors toutes
les adresses destination conviendront.
Tu peux aussi specifier un protocole (`-p' ou `--protocol'), comme TCP
ou UDP; seuls les paquets de ce protocole conviendront pour la règle.
La raison, principale de specifier un protocole tcp ou udp est que
l'on a alors des options supplémentaires : spécifiquement `--source-
port' et `--destination-port' (abbrégées en `--sport' et `--dport').
Ces options te permettent de specifier que seulement les paquets avec
un certain port source et destination conviendront à la régle. C'est
utile pour rediriger les requètes web (port TCP 80 ou 8080) et laisser
les autres paquets tranquilles.
Ces options doivent suivre l'option `-p' (qui a comme effet de charger
la librairie partagée pour ce protocole). Tu peux utiliser des
numéros de ports, ou un nom du fichier `/etc/services'.
Toutes les différentes manières dont tu peux selectionner un paquet
sont détaillées dans la page de manuel (man iptables).
[1m6. Specifier Comment Modifier Les Paquets[0m
Maintenant nous savons comment selectionner les paquets à modifier.
Pour completer notre règle, nous devons dire au noyau exactement ce
qu'il doit faire avec les paquets.
[1m6.1. NAT Source[0m
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
[1m6.1.1. Masquerading[0m
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 utilisera 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
[1m6.2. NAT De Destination[0m
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 à 1.2.3.4 en loopback.
# iptables -t nat -A OUTPUT -d 1.2.3.4 -j DNAT --to 127.0.0.1
[1m6.2.1. Redirection[0m
Il y a un cas spécialisé de NAT de Destination appelé redirection :
c'est une simplification qui est exactement équivalente à 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
[1m6.3. Mappings En Profondeur[0m
Il y a plusieurs subtilités du NAT que la pluspart des gens n'auront
jamais à utiliser. Elles sont documentées ici pour les curieux.
[1m6.3.1. Selection D'adresses Multiples Dans Un Bloc[0m
Si un bloc d'adresses IP est donné, l'adresse IP à 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.
[1m6.3.2. Créer Des Mappings De Null NAT[0m
Tu peux utiliser la cible `-j ACCEPT' pour laisser une connection
passer sans réaliser de NAT.
[1m6.3.3. NAT Standard[0m
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 à moins d'y être forcé.
[1m6.3.4. Mapping De Port Source Implicite[0m
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:
1. Une connection web est établie par une machine 192.1.1.1 du port
1024 au port 80 de www.netscape.com .
2. Ceci est masqueradé pas la machine qui masquerade pour utiliser son
adresse IP source (1.2.3.4).
3. La machine masqueradante essaye de realiser une connection web vers
le port 80 de www.netscape.com à partir de 1.2.3.4 (l'adresse de
son interface externe) port 1024.
4. Le code NAT va altèrer le port source de la seconde connection en
1025, pour que les deux ne colisionnent pas.
Quand ce mapping de source implicite est effectué, les ports sont
divisés en 3 classes:
· Les ports en dessous de 512
· Les ports entre 512 et 1023
· Les ports au dessus de 1024.
Un port ne sera jamais implicitement mappé dans une classe différente.
[1m6.3.5. Que Se Passe-t-il Quand Le NAT Foire ?[0m
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 faisant partie
d'une connection, parce qu'ils sont malformés, ou que la machine est
saturée en mémoire, etc.
[1m6.3.6. Mappings Multiples, Dépassements et Clashs[0m
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 ça que le masquerading fonctionne (en
partageant 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
[1m6.3.7. Altération de la Destination de Connections Générées Localle-[0m
[1mment[0m
Si la destination d'un paquet généré locallement est changée (p.e.
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 à 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.
[1m7. Protocoles Spéciaux[0m
Certains protocoles n'aiment pas êtres NATés. Pour chacun de ceux ci,
deux extensions doivent être écrites; une pour suivre le protocole, et
une pour le NAT en lui-mème.
Dans la distribution courante de netfilter, il y a des modules pour
ftp : ip_conntrack_ftp.o et ip_nat_ftp.o. Si tu les insmod dans ton
kernel (ou si tu les compiles en monolythique), alors effectuer
n'importe quel type de NAT sur une connection ftp devrait fonctionner.
Si tu ne le fais pas, alors seulement le ftp passif sera utilisable,
et encore cela pourrait ne pas fonctionner convenablement si tu
effectues plus qu'un simple NAT source.
[1m8. Considérations sur le NAT[0m
Si tu effectues du NAT sur une connection, tout les paquets qui
passent dans les [1mdeux [22msens (de et vers le réseau) doivent passer à
travers la machine NATée, sinon ça ne fonctionnera pas correctement.
En particulier, le code de suivi ré-assemble des fragments, ce qui
veut dire que non seulement le suivi de connection ne sera pas
valable, mais tes paquets pourraient ne pas passer du tout, comme des
fragments seront retenus.
[1m9. NAT Source et Routage[0m
Si tu effectues du SNAT, tu devras verifier que chaque machine SNATée
renvera ses packets à la machine qui NAT. Par exemple, si tu mappe des
paquets sortants sur l'adresse source 1.2.3.4, alors le routeur
exterieur doit savoir qu'il doit renvoyer les paquets de réponse (qui
auront la [1mdestination [22m1.2.3.4) à cette machine. Ceci peut être fait
des manières suivantes :
1. Si tu effectues du SNAT sur l'adresse propre de la machine (pour
laquelle le routage et tout fonctionne), tu n'as besoin de rien
faire.
2. Si tu effectues du SNAT sur une adresse inusitée du LAN local (par
exemple, tu mappes sur 1.2.3.99, une ip libre sur ton réseau
1.2.3.0/24), ta machine NAT devra répondre aux requètes ARP pour
cette adresse aussi : la facon la plus facile de faire cela est de
créer un alias IP, p.e :
# ip address add 1.2.3.99 dev eth0
3. Si tu effectues du SNAT sur une adresse complètement différente, tu
devras t'assurer que la machine qui sera touchée par les paquets
SNAT routera cette addresse vers la machine NAT. Ceci est déjà
existant si la machine NAT est leur passerelle par défaut, sinon tu
devras publier une route (si tu utilises un protocole de routage ou
ajouter manuellement les routes sur chaque machine concernée.
[1m10. NAT de Destination Sur le Mème Réseau[0m
Si tu effectues du portforwarding sur le même réseau, tu devras
t'assurer que les paquets futurs et leurs réponses passeront par la
machine NAT (pour qu'ils soient modifiés). Le code NAT (depuis
2.4.0-test6), va bloquer les ICMP redirect sortants qui sont produits
lorsque le paquet NATé sort par la même interface que celle par
laquelle il est rentré, mais le serveur distant continuera toujours à
essayer de répondre directement au client (qui ne reconnais pas la
réponse).
Le cas classique est lorsque le staff interne essaye d'accèder ton
serveur web `public', qui est DNATé de l'adresse publique (1.2.3.4)
vers une machine interne (192.168.1.1), comme ceci :
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp --dport 80 -j DNAT --to 192.168.1.1
Une solution est d'utiliser un serveur DNS interne qui connait
l'adresse IP réelle de ton site web public, et de passer toutes les
autres requètes vers un serveur DNS externe. Ceci veut dire que le
logging sur le serveur web montrera les adresses IP interne
correctement.
L'autre solution est d'avoir la machine NAT qui mappe aussi les
adresses IP sources sur la sienne pour ces connections, trompant le
serveur en répondant par elle. Dans cet exemple, nous devrions faire
ceci (en supposant que l'adresse IP interne de la machine NAT est
192.168.1.250):
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
-p tcp --dport 80 -j SNAT --to 192.168.1.250
A cause de la règle de [1mPREROUTING[22m, les paquets seront déja destinés
pour le serveur web interne : nous pouvons dire lesquels sont sourcés
en interne par les adresses IP source.
[1m11. Remerciements[0m
En premier remerciements à WatchGuard, et David Bonn, qui on cru assez
a l'idée de netfilter pour me supporter pendant que je travaillais
dessus.
Et à tout ceux qui m'ont supporté, alors que j'apprenais la laideur du
NAT, spécialement ceux qui lisent mon journal.
Rusty.