Guide Pratique du NAT sous Linux 2.4 Rusty Russell Titre original : `Linux 2.4 NAT HOWTO' Traduction initiale : Emmanuel Roger Dernière adaptation : Guillaume Audiracguillaume POINT audirac CHEZ netpratique POINT fr Relecture : Thomas Nemethtnemeth CHEZ free POINT fr v1.18.fr.1.0, le 20 Mai 2004, traduction/adaptation Ce document décrit comment réaliser du camouflage d'adresse IP, un serveur mandataire transparent, de la redirection de ports ou d'autres formes de Traduction d'Adresse Réseau (`Network Address Translation' ou NAT) avec le noyau Linux 2.4. ______________________________________________________________________ Table des matières 1. Introduction 2. Où se Trouvent les Sites Web Officiels et la Liste de Diffusion ? 2.1 Qu'est-ce Que la Traduction d'Adresse Réseau ? 2.2 Pourquoi Voudrais-Je Utiliser du NAT ? 3. Les Deux Types de NAT 4. Traduction Rapide À Partir des Noyaux 2.0 et 2.2 4.1 Au secours ! Je Veux Juste du Camouflage ! 4.2 Et Au Sujet d'ipmasqadm ? 5. Contrôler À Quoi Appliquer le NAT 5.1 Sélection Simple Avec Iptables 5.2 Affinage de la Sélection des Paquets à Marquer 6. Définir Comment Marquer Les Paquets 6.1 NAT de Source 6.1.1 Camouflage 6.2 NAT de Destination 6.2.1 Redirection 6.3 Détail des Mises en Correspondance 6.3.1 Sélection d'Adresses Multiples Dans une Plage 6.3.2 Ne Réaliser Aucune Correspondance de NAT 6.3.3 Comportement Standard du NAT 6.3.4 Correspondance Implicite de Port Source 6.3.5 Que Se Passe-t'il Quand le NAT Echoue ? 6.3.6 Mises en Correspondance Multiples, Recouvrements et Collisions 6.3.7 Modification de la Destination de Connexions Générées Localement 7. Protocoles Spéciaux 8. Avertissements sur le NAT 9. NAT de Source et Routage 10. NAT de Destination Vers le Même Réseau 11. Remerciements 12. Commentaires et Corrections ______________________________________________________________________ 1. Introduction Bienvenue, ami lecteur. Vous êtes sur le point de plonger dans le monde fascinant (et parfois redoutable) de la Traduction d'Adresse Réseau ou NAT (`Network Address Translation'), parfois appelée Transformation d'Adresse Réseau. Ce Guide Pratique vous accompagnera aussi précisément que possible dans les noyaux de Linux 2.4 et au-delà. Sous Linux 2.4, une infrastructure appelée `Netfilter' a été introduite pour marquer les paquets. Une couche au-dessus de celle-ci fournit le NAT, complètement réimplémenté depuis les noyaux précédents. (C) 2000 Paul `Rusty' Russell. Sous licence GNU GPL. 2. Où se Trouvent les Sites Web Officiels et la Liste de Diffusion ? Voici les trois sites officiels : · Merci à Filewatcher . · Merci à l'équipe de samba et SGI . · Merci à Harald Welte . Vous pouvez tous les atteindre en utilisant le DNS de type Round-Robin via et Pour la liste de diffusion officielle de Netfilter : Liste de Netfilter . 2.1. Qu'est-ce Que la Traduction d'Adresse Réseau ? Normalement, les paquets sur un réseau voyagent de leur source (par exemple, votre ordinateur de bureau) à leur destination (par exemple, www.gnumonks.org) en traversant différents liens : dans mon cas, environ 19 d'où je suis en Australie. Aucun de ces liens ne modifie vraiment votre paquet : ils le renvoient juste plus loin. Si l'un de ces liens effectuait du NAT, alors il modifierait l'adresse source ou destination du paquet au moment où il passe. Comme on peut l'imaginer, le système n'a pas été prévu pour fonctionner comme ça, et le NAT est toujours quelque-chose de bancal. Généralement, le lien effectuant du NAT mémorise comment il a modifié un paquet, et quand une réponse arrive dans l'autre sens, il effectue la modification inverse sur ce paquet de réponse, pour que tout fonctionne bien. 2.2. Pourquoi Voudrais-Je Utiliser du NAT ? Dans un monde parfait, vous n'en auriez pas besoin. Néanmoins, voici les raisons principales : Les Connexions par Modem à Internet La plupart des FAI (Fournisseurs d'Accès à Internet) vous donnent une seule adresse IP quand vous vous connectez chez eux. De ce fait, vous pouvez envoyer des paquets avec l'adresse source que vous voulez, mais seules vous seront envoyées les réponses aux paquets avec l'adresse IP source qui vous a été attribuée. Si vous voulez utiliser plusieurs machines différentes (comme dans un réseau personnel) pour vous connecter à Internet à travers ce lien unique, vous avez 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 camouflage d'adresse IP (`masquerading') dans le monde Linux. J'appelle ça du SNAT, parce que vous changez l'adresse source du premier paquet. Serveurs Multiples Parfois, vous voulez changer la direction des paquets arrivant dans votre réseau. C'est souvent parce que vous n'avez qu'une seule adresse IP (comme ci-dessus), mais vous voulez quand même qu'on puisse accéder aux machines qui se trouvent derrière celle avec l'adresse IP `réelle'. Vous pouvez le faire si vous remaniez la destination des paquets entrants. Ce genre de NAT est appelé `redirection de ports' (`port-forwarding') dans les précédentes versions de Linux. Une variante courante de ceci est le partage de charge (`load- sharing'), où les paquets sont répartis sur un parc de machines. Si vous faites ceci sur une large échelle, vous pouvez jeter un oeil à Serveur Linux Virtuel . Mandataire Transparent Parfois, vous voulez faire croire que chaque paquet traversant votre machine sous Linux est destiné à un programme sur cette machine même. Ceci est utilisé pour réaliser des mandataires transparents : un mandataire (ou `proxy') est un programme qui se situe entre votre réseau et le monde extérieur, établissant la communication entre les deux. La transparence traduit le fait que votre réseau ne sait pas qu'il communique avec un mandataire, à moins évidemment qu'il ne fonctionne pas. Squid peut être configuré pour fonctionner de cette manière, et c'est ce qu'on appelle une redirection ou un mandataire transparent dans les versions précédentes de Linux. 3. Les Deux Types de NAT Je sépare le NAT en deux types différents : le NAT de Source (SNAT) et le NAT de Destination (DNAT). Le NAT de source, c'est lorsqu'on modifie l'adresse source du premier paquet : c'est-à-dire que vous changez le lieu dont est issue la connexion. Le NAT de source est toujours réalisé après le routage, juste avant que le paquet ne soit envoyé sur la ligne. Le camouflage est une forme spécialisée de SNAT. Le NAT de destination, c'est lorsqu'on modifie l'adresse de destination du premier paquet : c'est-à-dire que vous changez le lieu où la connexion va aboutir. Le NAT de destination est toujours effectué avant le routage, aussitôt que le paquet arrive sur la ligne. La redirection de port, le partage de charge et le mandataire transparent sont tous des formes de DNAT. 4. Traduction Rapide À Partir des Noyaux 2.0 et 2.2 Désolé pour tous ceux d'entre-vous qui restent choqués par la transition du 2.0 (Ipfwadm) au 2.2 (Ipchains). Il y a de bonnes et de mauvaises nouvelles. Tout d'abord, vous pouvez toujours utiliser Ipchains et Ipfwadm comme avant. Pour cela, vous aurez besoin d'insérer (avec insmod) les modules 'ipchains.o' ou 'ipfwadm.o' trouvés dans la dernière distribution de Netfilter. Ils sont mutuellement exclusifs (vous êtes prévenus) et ne doivent être associés avec aucun autre module de Netfilter. Une fois un de ces modules installé, vous pouvez utiliser Ipchains ou Ipfwadm comme avant, avec les différences suivantes : · Configurer les durées de validité du camouflage avec ipchains -M -S ou ipfwadm -M -s, est sans effet. Puisque les durées de validité sont plus longues pour la nouvelle infrastructure de NAT, ça n'a plus d'importance. · Pour le camouflage, les champs init_seq, delta et previous_delta du listage détaillé sont toujours à zéro. · Initialiser les compteurs et les lister en même temps avec `-Z -L' ne fonctionne plus : les compteurs ne seront pas remis à zéro. · La rétrocompatibilité fonctionne mal pour un grand nombre de connexions : ne l'utilisez pas sur une passerelle professionnelle ! Les bidouilleurs remarqueront aussi : · Vous pouvez à présent utiliser les ports 61000-65095 même si vous effectuez du camouflage. Le code de camouflage considérait que tout ce qui se trouvait dans cet intervalle était déloyal, donc les programmes ne pouvaient l'utiliser. · Le bidouillage `getsockname' (non documenté) que les programmes des mandataires transparents pouvaient utiliser pour découvrir la destination réelle des connexions ne fonctionne plus. · Le bidouillage `bind-to-foreign-address' (non documenté) n'est également plus implémenté; il servait à réaliser l'illusion d'un mandataire transparent. 4.1. Au secours ! Je Veux Juste du Camouflage ! C'est ce que veulent la plupart des gens. Si vous avez une connexion PPP allouée dynamiquement (si vous ne savez pas, c'est le cas), vous voulez simplement dire à votre machine que tous les paquets qui viennent de votre réseau interne doivent avoir l'air de venir de la machine qui initie la connexion PPP. # Charger le module du NAT (il charge tous les autres). modprobe iptable_nat # Dans la table du NAT (-t nat), ajouter une règle (-A) après le routage # (POSTROUTING) pour tous les paquets qui sortent par ppp0 (-o ppp0) qui stipule # de camoufler la connexion (-j MASQUERADE). iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # Activer la redirection d'IP echo 1 > /proc/sys/net/ipv4/ip_forward Notez que vous n'allez effectuer aucun filtrage de paquets ici : pour cela, lisez le chapitre du Guide Pratique du Filtrage de Paquets : `Mélanger le NAT et le Filtrage de Paquets'. 4.2. Et Au Sujet d'ipmasqadm ? C'est une catégorie d'utilisateurs beaucoup plus restreinte, donc je ne m'attache pas à la compatibilité à ce point là. Vous pouvez simplement utiliser `iptables -t nat' pour effectuer de la redirection de port. Donc par exemple, sous Linux 2.2, vous auriez entré : # Linux 2.2 # Faire suivre les paquets TCP destinés au port 8080 de 1.2.3.4 vers le 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, vous devriez faire : # Linux 2.4 # Ajouter une règle de pré-routage (-A PREROUTING) à la table de NAT (-t nat) qui # prend les paquets TCP (-p tcp) destinés au port 8080 (--dport 8080) de 1.2.3.4 (-d 1.2.3.4) # et les redirige (-j DNAT) vers le port 80 de 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 5. Contrôler À Quoi Appliquer le NAT Vous devez créer des règles de NAT qui disent au noyau quelles connexions modifier et comment les modifier. Pour cela, on utilise la souplesse de l'outil Iptables, en lui spécifiant de modifier la table de NAT avec l'option -t nat. La table des règles de NAT contient 3 listes appelées `chaînes' : chaque règle est examinée dans l'ordre jusqu'à ce que l'une d'elles convienne. Les trois chaînes sont nommées PREROUTING (pour le NAT de destination, lorsque le paquet arrive), POSTROUTING (pour le NAT de source, lorsque le paquet part) et OUTPUT. La troisieme chaîne (OUTPUT) sera ignorée pour l'instant. Le diagramme suivant devrait illustrer ceci clairement si j'avais le moindre talent artistique : _____ _____ / \ / \ PREROUTING -->[Décision]----------------->POSTROUTING-----> \D-NAT/ [de routage] \S-NAT/ | ^ | | | | | | | | | | | | ------> Processus local ------ Lorsqu'un paquet traverse chacun des cercles ci-dessus, on observe la connexion à laquelle il est associé. S'il s'agit d'une nouvelle connexion, on examine la chaîne correspondante dans la table de NAT pour voir ce qu'il convient de faire du paquet. La réponse obtenue sera appliquée ensuite à tous les futurs paquets associés à cette connexion. 5.1. Sélection Simple Avec Iptables Iptables accepte en standard de nombreuses options, listées ci- dessous. Toutes les options avec un double tiret peuvent être abrégées, à condition qu'Iptables puisse les différencier des autres. Si votre noyau contient le module de support d'Iptables, vous devrez charger le module iptables.o en premier : `insmod ip_tables'. L'option la plus importante ici est la sélection de table avec `-t'. Pour toutes les opérations de NAT, vous aurez à utiliser `-t nat' pour la table NAT. La seconde option indispensable est `-A' pour ajouter une nouvelle règle à la fin d'une chaîne (par exemple `-A POSTROUTING') ou `-I' pour en insérer une au début (par exemple `-I PREROUTING'). Vous pouvez spécifier l'adresse de source (`-s' ou `--source') et de destination (`-d' ou `--destination') du paquet que vous voulez transformer. Ces options peuvent être suivies par une seule adresse IP (par exemple 192.168.1.1), un nom (p.e. www.gnumonks.org), ou une adresse de réseau (par exemple 192.168.1.0/24 ou 192.168.1.0/255.255.255.0). Pour la correspondance, vous pouvez spécifier une interface d'entrée (`-i' ou `--in-interface') ou de sortie (`-o' ou `--out-interface'), mais celle que vous avez le droit de spécifier dépend de la chaîne contenant la règle : dans PREROUTING, vous ne pouvez sélectionner qu'une interface d'entrée, et dans POSTROUTING (et OUTPUT) qu'une interface de sortie. Si vous vous trompez, Iptables vous renverra une erreur. 5.2. Affinage de la Sélection des Paquets à Marquer J'ai mentionné plus haut que vous pouviez spécifier une adresse de source et de destination. Néanmoins, si vous omettez l'adresse de source, alors toutes les adresses de source conviendront. Et si vous omettez l'adresse de destination, alors toutes les adresses de destination conviendront. Vous pouvez aussi spécifier un protocole (`-p' ou `--protocol'), comme TCP ou UDP ; seuls les paquets de ce protocole corresponderont à la règle. Le principal intérêt de spécifier un protocole TCP ou UDP est de disposer alors d'options supplémentaires : précisément `--source- port' et `--destination-port' (abbrégées en `--sport' et `--dport'). Ces options vous permettent de spécifier que seuls les paquets avec un certain port source ou destination corresponderont à 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 l'extension de bibliothèque partagée pour ce protocole). Vous pouvez utiliser des numéros de ports ou un nom issu du fichier `/etc/services'. Les différentes manières dont vous pouvez sélectionner un paquet sont détaillées dans la page de manuel (man iptables). 6. Définir Comment Marquer Les Paquets 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. 6.1. NAT de Source 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 6.1.1. Camouflage 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 6.2. NAT de Destination 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 6.2.1. Redirection 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 ! 6.3. Détail des Mises en Correspondance 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. 6.3.1. Sélection d'Adresses Multiples Dans une Plage 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. 6.3.2. Ne Réaliser Aucune Correspondance de NAT Vous pouvez utiliser la cible `-j ACCEPT' pour laisser passer une connexion sans réaliser de NAT. 6.3.3. Comportement Standard du 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é. 6.3.4. Correspondance Implicite de Port Source 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 : 1. Une connexion web est établie par une machine 192.1.1.1 du port 1024 au port 80 de www.netscape.com. 2. Celle-ci est transformée par la machine effectuant le camouflage pour utiliser en adresse source sa propre adresse IP (1.2.3.4). 3. La machine effectuant le camouflage essaie de réaliser une connexion 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 du NAT va modifier le port source de la seconde connexion en 1025, pour éviter toute collision entre les deux connexions. Quand cette correspondance implicite de source se produit, les ports sont répartis en 3 classes : · Les ports inférieurs à 512 · Les ports entre 512 et 1023 · Les ports supérieurs à 1024. Un port ne sera jamais implicitement mis en correspondance dans une autre classe que la sienne. 6.3.5. Que Se Passe-t'il Quand le NAT Echoue ? 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... 6.3.6. Mises en Correspondance Multiples, Recouvrements et Collisions 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 6.3.7. Modification de la Destination de Connexions Générées Localement 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. 7. Protocoles Spéciaux Certains protocoles n'aiment pas être soumis au NAT. Pour chacun d'entre-eux, deux extensions doivent être écrites ; une pour le traçage de connexion du protocole et une pour le NAT lui-même. Dans la distribution actuelle de Netfilter, il y a des modules pour FTP : ip_conntrack_ftp.o et ip_nat_ftp.o. Si vous les insérez dans votre noyau avec insmod (ou si vous les intégrez à la compilation), alors effectuer tout type de NAT sur une connexion FTP devrait fonctionner. Si vous ne le faites pas, alors seul le FTP passif sera utilisable, et encore, il pourrait ne pas fonctionner de façon fiable si vous réalisez plus que du simple NAT de source. 8. Avertissements sur le NAT Si vous effectuez du NAT sur une connexion, tous les paquets passant dans les deux sens (vers l'intérieur et l'extérieur du réseau) doivent traverser la machine effectuant le NAT, sinon ça ne fonctionnera pas correctement. En effet, le code de traçage de connexion réassemble les fragments, ce qui veut dire que non seulement le suivi de connexion ne sera pas fiable, mais aussi que vos paquets pourraient ne pas passer du tout, puisque des fragments seront retenus. 9. NAT de Source et Routage Si vous effectuez du SNAT, vous devriez vérifier que chaque machine qui reçoit des paquets modifiés par SNAT renverra les réponses à la machine de NAT. Par exemple, si vous mettez en correspondance des paquets sortants sur l'adresse source 1.2.3.4, alors le routeur extérieur doit savoir qu'il doit renvoyer les paquets de réponse (qui auront comme destination 1.2.3.4) à cette machine. Ceci peut être fait des manières suivantes : 1. Si vous effectuez du SNAT vers la propre adresse de la machine (pour laquelle le routage et le reste fonctionnent), vous n'avez rien à faire. 2. Si vous effectuez du SNAT sur une adresse inutilisée du réseau local (par exemple, vous mettez en correspondance sur 1.2.3.99, une adresse IP libre sur votre réseau 1.2.3.0/24), votre machine de NAT devra répondre aux requêtes ARP sur cette adresse autant que sur la sienne : la façon la plus facile de faire cela est de créer un alias IP, par exemple : # ip address add 1.2.3.99 dev eth0 3. Si vous effectuez du SNAT vers une adresse complètement différente, assurez-vous que la machine atteinte par les paquets modifiés routera cette adresse vers la machine de NAT. Ceci est déjà réalisé si la machine de NAT est leur passerelle par défaut, sinon vous devrez publier une route (si vous utilisez un protocole de routage) ou ajouter manuellement les routes sur chaque machine concernée. 10. NAT de Destination Vers le Même Réseau Si vous effectuez de la redirection de port vers le même réseau, vous devrez vous assurer que les paquets futurs et leurs réponses passeront par la machine de NAT (pour qu'ils soient modifiés). Le code du NAT (depuis le noyau 2.4.0-test6) bloquera le paquet de redirection ICMP sortant qui est généré lorsque le paquet modifié sort par l'interface par laquelle il est entré, mais le serveur de réception essaiera toujours de répondre directement au client (qui ne reconnaitra pas la réponse). Dans le cas classique, les machines internes essaient d'accéder à votre serveur web `public', qui en réalité est redirigé par 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 connaît l'adresse IP réelle (interne) de votre site web public, et de rediriger toutes les autres requêtes vers un serveur DNS externe. Ceci signifie qu'une connexion locale sur le serveur web montrera les adresses IP internes correctement. L'autre solution pour ces connexions est de forcer la machine de NAT à mettre en correspondance les adresses IP sources avec la sienne, trompant le serveur en répondant à travers lui. Dans cet exemple, nous devrions faire ceci (en supposant que l'adresse IP interne de la machine de 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 Comme la règle de PREROUTING est exécutée en premier, les paquets seront déjà destinés pour le serveur web interne : nous pouvons dire lesquels sont générés en interne grâce aux adresses IP sources. 11. Remerciements Tout d'abord, je remercie WatchGuard et David Bonn, qui ont cru à l'idée de Netfilter suffisamment pour me soutenir lorsque je travaillais dessus. Je remercie aussi tous ceux qui ont été patients avec mes extravagances, alors que j'apprenais la laideur du NAT, et je remercie spécialement ceux qui lisent mon journal. Rusty. 12. Commentaires et Corrections Merci de faire parvenir en anglais à l'auteur vos questions et commentaires relatifs à la version originale de ce document à l'adresse netfilter@lists.samba.org. N'hésitez pas à faire parvenir tout commentaire relatif à la version française de ce document à commentaires CHEZ traduc POINT org en précisant le titre et la version de ce document.