Linux 2.4 NAT HOWTO <author>Rusty Russell, liste d'email <tt>netfilter@lists.samba.org</tt>&nl; Traduit par emmanuel Roger<tt><htmlurl name="flynux@freegates.be" url="mailto:flynux@freegates.be"></tt>&nl; <date>v1.0.1 Lundi 1er Mai 18:38:22 CST 2000, traduction du 28 aout 2000 <abstract> Ce document décrit comment réaliser du masquerading, un proxy transparent, de la redirection de ports, et d'autres formes de Network Address Translations (Translation d'addresses réseaux) avec le Noyau Linux 2.4 . </abstract>  <toc>  <sect>Introduction<label id="intro"> 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. <sect>Où se trouvent les site web officiels et la liste de mail ? Voici les trois sites officiels: <itemize> <item>Merci à <url url="http://netfilter.filewatcher.org/" name="Filewatcher">. <item>Merci à <url url="http://netfilter.samba.org/" name="l'équipe de samba et SGI">. <item>Merci à <url url="http://netfilter.gnumonks.org/" name="Harald Welte">. </itemize> Pour la liste email officielle de netfilter: <url url="http://www.netfilter.org/contact.html#list" name="liste de netfilter">. <sect1>Qu'est ce que Network Address Translation? 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. <sect1>Pourquoi Voudrais-Je Utiliser du NAT? Dans un monde parfait, tu ne devrais pas. Autrement les raisons principales sont : <descrip> <tag/Les Connections par Modem à Internet/ 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 <bf>source</bf> du premier paquet. <tag/Serveurs Multiples/ 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. <tag/Proxy Transparent/ 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. </descrip> <sect>Les Deux Types de NAT Je divise le NAT en deux types différents : le <bf>NAT Source</bf> (SNAT) et le <bf>NAT Destination</bf> (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. <sect>Rapide traduction des noyaux 2.0 et 2.2 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: <itemize> <item> 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. <item> Les champs init_seq, delta et previous_delta dans le masquerading détaillé sont toujours à zéro. <item> 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. </itemize> Les hackers noteront aussi: <itemize> <item> 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. <item> Le hack (non documenté) `getsockname', que les programmes de proxy transparents pouvaient utiliser pour trouver la destination réelle des connections ne fonctionne plus. <item> 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. </itemize> <sect1>Au secours! je veux juste du masquerading! 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. <tscreen><verb> # 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 </verb></tscreen> 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'. <sect1>Et pour ipmasqadm? 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é : <tscreen><verb> # 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 </verb></tscreen> Maintenant tu devrais faire : <tscreen><verb> # 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 </verb></tscreen> 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) : <tscreen><verb> # 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 </verb></tscreen> <sect>Controller quoi il faut NATer 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 <tt>iptables</tt>, 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: <tscreen><verb> _____ _____ / \ / \ PREROUTING -->[décision]----------------->POSTROUTING-----> \D-NAT/ [de routage] \S-NAT/ | ^ | __|__ | / \ | | OUTPUT| | \D-NAT/ | ^ | | -------->Processus local------ </verb></tscreen> 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. <sect1>Sélection simple en utilisant iptables <tt>iptables</tt> 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 <tt>iptables</tt> 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, <tt>iptables</tt> retournera une erreur. <sect1>Affinage Des Points De Sélection Des Paquets A Modifier 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 (<tt>man iptables</tt>). <sect>Specifier Comment Modifier Les Paquets 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. <sect1>NAT Source 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). <tscreen><verb> ## 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 </verb></tscreen> <sect2>Masquerading 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. <tscreen><verb> ## Masquerader tout ce qui sort par ppp0. # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE </verb></tscreen> <sect1>NAT De Destination 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). <tscreen><verb> ## 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 </verb></tscreen> <sect2>Redirection 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. <tscreen><verb> ## 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 </verb></tscreen> <sect1>Mappings En Profondeur 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. <sect2>Selection D'adresses Multiples Dans Un Bloc 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. <sect2>Créer Des Mappings De Null NAT Tu peux utiliser la cible `-j ACCEPT' pour laisser une connection passer sans réaliser de NAT. <sect2>NAT Standard 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é. <sect2>Mapping De Port Source Implicite 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: <enum> <item> Une connection web est établie par une machine 192.1.1.1 du port 1024 au port 80 de www.netscape.com . <item> Ceci est masqueradé pas la machine qui masquerade pour utiliser son adresse IP source (1.2.3.4). <item> 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. <item> Le code NAT va altèrer le port source de la seconde connection en 1025, pour que les deux ne colisionnent pas. </enum> Quand ce mapping de source implicite est effectué, les ports sont divisés en 3 classes: <itemize> <item> Les ports en dessous de 512 <item> Les ports entre 512 et 1023 <item> Les ports au dessus de 1024. </itemize> Un port ne sera jamais implicitement mappé dans une classe différente. <sect2>Que Se Passe-t-il Quand Le NAT Foire ? 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. <sect2>Mappings Multiples, Dépassements et Clashs 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 : <tscreen><verb> # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \ -j SNAT --to 1.2.3.0/24 </verb></tscreen> 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: <tscreen><verb> # 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 </verb></tscreen> <sect2>Altération de la Destination de Connections Générées Locallement 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. <sect>Protocoles Spéciaux 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. <sect>Considérations sur le NAT Si tu effectues du NAT sur une connection, tout les paquets qui passent dans les <bf>deux</bf> sens (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. <sect>NAT Source et Routage 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 <bf>destination</bf> 1.2.3.4) à cette machine. Ceci peut être fait des manières suivantes : <enum> <item> 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. <item> 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 : <tscreen><verb> # ip address add 1.2.3.99 dev eth0 </verb></tscreen> <item> 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. </enum> <sect>NAT de Destination Sur le Mème Réseau 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 : <tscreen><verb> # iptables -t nat -A PREROUTING -d 1.2.3.4 \ -p tcp --dport 80 -j DNAT --to 192.168.1.1 </verb></tscreen> 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): <tscreen><verb> # 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 </verb></tscreen> A cause de la règle de <bf>PREROUTING</bf>, 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. <sect>Remerciements 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. </article>