4. 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 de insmod 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 ètrtes 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 a zéro.
• Mettre les compteurs a zéro et les lister en mème temps `-Z -L' ne fonctionne plus: les compteurs ne seront pas remis a zéro.

Les hackers noteront aussi:

• Tu peux a 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.

4.1 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 a 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'.

4.2 Et pour ipmasqadm?

C'est une catégorie d'utilisateurs beaucoup plus restreinte, donc je ne m'attaches pas a la compatibilité a 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) a 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