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