Re: Questions sur IPTABLES

トップ ページ

このメッセージに返信
著者: Olivier Allard-Jacquin
日付:  
To: guilde
題目: Re: Questions sur IPTABLES
    Bonjour Nicolas,

nico.efrei@??? a écrit :
> Bonjour à tout le monde. Voilà après avoir lu le tuto d'olivier (http://olivieraj.free.fr/fr/linux/information/firewall) sur les iptables


    Cela me dit quelque chose en effet... ;)


> il y a un truc que je ne pige pas au niveau du forwarding.


    Forwarding ? Ou NAT ?


    Je pense que ton problème se situe au niveau de la compréhension  de la 
différence entre ces 2 concepts.


> Si j'ai bien compris (ce n'est peut être pas le cas) si je fais la commande suivante :
>
> eth0 ==> internet
> eth1 ==> réseau local
> serveur servant de passerelle 192.168.0.1 (debian sarge)
> mon ordi sous winXP 192.168.0.2


    OK


> iptables -A FORWARD -i eth1 -o eth0 -s 192.168.0.0/24 -d 0.0.0.0/0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT


    Cette commande autorise les paquets VENANT de l'interface de ton réseau 
local ("-i eth1" et "-s 192.168.0.0/24") à SORTIR sur l'interface de ta 
connexion Internet ("-o eth0" et "-d 0.0.0.0/0"), à la condition que ce 
soit des paquets :


- de l'établissement d'une nouvelle connexion (exemple : un SYN vers
un serveur HTTP)
- ou qui font suite à une connexion déjà établie (exemple : les ACK à
des paquets que tu reçois du serveur, ou les demandes que tu fais au
serveur)
- ou qui sont en relation avec une connexion déjà établie (c'est
typiquement le cas d'une connexion FTP en mode DATA, port 20, suite à
des requêtes en mode COMMANDE, port 21).

    Pour être bref, tu laisses passer des paquets qui veulent SORTIR de ton 
réseau local


> iptables -A FORWARD -i eth0 -o eth1 -s 0.0.0.0/0 -d 192.168.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT


    Cette commande autorise les paquets VENANT de l'extérieur de ton réseau 
local ("-i eth0" et "-s 0.0.0.0/0") à RENTRER dans ton réseau local ("-o 
eth1" et "-d 192.168.0.0/24"), à la condition que ces paquets :
  - fassent suite à une connexion déjà établie (exemple : le ACK du 
serveur suite à ton SYNC, ou tout simplement la page HTML que tu as demandé)
  - ou soient en relation avec une connexion déjà établie (c'est 
typiquement le cas d'une connexion FTP en mode DATA, port 20, suite à 
des requêtes en mode COMMANDE, port 21).


    Bref, cette règle permet à ton Windows de recevoir les réponses aux 
demandes qu'il a fait aux serveurs sur Internet.


> iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j MASQUERADE


    Cette règle peut paraître assez bizarre, mais elle est nécessaire. Avec 
la 1ère règle, que se passe t'il sur les paquets que tu  envoies sur 
Internet ? Ils ont pour adresse de retour une adresse IP de ton réseau 
local (192.168.0.2). Mais cette adresse n'est pas autorisé sur Internet. 
Donc comment le serveur pourra t'il y répondre ? Réponse : Il ne pourra pas.


    Donc le but de cette commande est de masquer ("-j MASQUERADE") les 
adresses IP de ton réseau local, et de les remplacer par celle de ton 
interface réseau externe ("-o eth0").


    Ainsi, les paquets partirons sur Internet avec comme adresse IP de 
retour, celle de ta Debian. Ce sera alors à netfilter de se charger de 
faire la "conversion" des adresses IP, mais cela il le fera 
automatiquement, sans que tu n'aies besoin de rajouter une autre règle.


    Tout ce que nous venons de voir ici, c'est pour le NAT, à savoir le 
Network Address Translation.


    Par contre, ce que tu vas demander ci-dessous est un peu différent...


> Avec ca, je peux surfer sur le net depuis avec mon ordi sous winXP


    Oui


> et normalement je peux utiliser, depuis cet ordi, toute application qui demande à se connecter au net avec n'importe quel port non ?


    Toutes ? Oui. Quelque soit le port de destination (emule y compris).


> Si oui, pourquoi par exemple si je veux utiliser emule, il faut que j'entre les regles spécifiques,


    Oui, mais ces règles dont tu parles sont un poil différentes. Car ce 
sont des règles de PORT FORWARDING. Et non plus de NAT.


> c'est à dire avec le numéro de port ? Hors avec les 3 commandes précédentes, je n'ai pas précisé de protocoles ni de ports, donc elle est normalement valables pour tout.


    Oui, car dans les 3 règles dont tu as parlé ci-dessus, tu n'as pas 
précisé de protocole (tcp, udp, icmp, ...) ni de port particulier.


> Voilà je tiens juste à préciser que si vous m'aidez, vous ne m'aidez pas pour faire du P2P (étant donné que je connais le moyen d'arranger ça) mais plutot pour mieux comprendre iptables car là je ne comprend pas pourquoi ça ne marche pas :(


    Pour cela, je vais donner les règles en question. Les explications qui 
suivent sont valables aussi bien pour emule, que pour d'autres clients 
P2P, comme bittorent. Mais ces explications sont aussi valables pour un 
autre usage du PORT FORWARDING, à savoir l'hébergement sur une machine 
local (ici, le XP en 192.168.0.2) d'un serveur que l'on veut mettre à 
disposition sur Internet. Un serveur HTTP par exemple.


    A noter que ces explications ne sont pas une incitation au partage de 
fichiers sous copyright. Le P2P sert aussi à la distribution de fichiers 
libres, comme des images ISO de distributions Linux (c'est par exemple 
le cas de la Mandrake...).


    Bon, quel est le problème avec ton emule ? C'est simplement que pour 
que le réseau emule fonctionne, il faut que toi aussi tu partages des 
fichiers sur Internet. C'est la règle du jeu.


    Pour cela, ton emule Windows a ouvert des ports en entrée (tcp/4662 et 
udp/4672 si mes souvenirs sont exacts), sur lequel il va attendre des 
demandes de connexion de la part d'autres clients P2P.


    OUI, MAIS. Ces clients, la seule chose qu'ils connaissent de toi, c'est 
l'adresse IP externe de ta Debian (interface eth0). Donc c'est sur cette 
adresse IP et sur les ports tcp/4662 et udp/4672 de ta Debian que ces 
clients vont accéder.


    Or, le netfilter de ta Debian est programmé pour quoi ? Pour refuser 
toutes connexions entrantes sur l'interface réseau eth0, et qui n'ont 
pas étés sollicitées par ta machine.


    Donc les demandes de connexions de ces clients externes sont refusées. 
Ton emule Windows ne voit pas arriver de connexion de demande de 
partage, dont il estime que tu refuses de partager. Donc tu ne pourras 
pas télécharger (dans les faits, c'est un peu plus compliqué que cela, 
mais je ne vais pas rentrer dans les détails).


    Tu vas me dire "Mais moi pourtant, je me connecte pour récupérer des 
fichiers sur des clients emule. Donc le netfilter de ma Debian doit bien 
voir que j'utilise emule. Donc il doit comprendre qu'il faut qu'il ouvre 
ce port". Et bien non, netfilter ne le fait pas. Et ce, pour 2 raisons :


- il n'existe pas, pour l'instant, de module netfilter qui analyse le
trafic emule (*). Et donc netfilter ne peut pas savoir que ton emule
Windows à ouvert les ports tcp/4662 et udp/4672 de ton XP.

- Si effectivement il existait un tel module, que se passerait t'il si
tu avais 2 client emule tournant sur 2 XP de ton réseau interne ?
Comment le netfilter de ta Debian pourrait savoir à quel emule sont
destinés les demandes de connexion arrivant sur les ports tcp/4662 et
udp/4672 ? Il ne pourrait pas (**).

    Donc, au niveau de netfilter, toute la logique du P2P est de :


- MODIFIER les paquets à destination des ports tcp/4662 et udp/4672 de
l'interface réseau eth0, afin de transformer leur adresse IP cible en
celle de ton XP sur ton interface réseau interne :

iptables -t nat -A PREROUTING \
          -i eth0 -s 0.0.0.0/0 \
          -p tcp --dport 4662 \
          -j DNAT --to-destination 192.168.0.2


iptables -t nat -A PREROUTING \
          -i eth0 -s 0.0.0.0/0 \
          -p udp --dport 4672 \
          -j DNAT --to-destination 192.168.0.2


Remarque importante. Ici, nous n'utilisons pas la table "-t filter",
mais la table "-t nat". Pourquoi ? Parce que dans netfilter, la table
"NAT" est utilisée AVANT la table "filter", et que dans la conception du
port forwarding, il FAUT que les paquets soient modifiés AVANT
d'atteindre la table "filter".

Autre remarque : Dans les règles ci-dessous, les numéros de port NE sont
PAS modifiés. Mais on pourrait les modifier eux-aussi. Cependant, dans
le cas précis de emule, ce serait une TRÈS mauvaise idée (**).

- REDIRIGER les ports tcp/4662 et udp/4672 de l'interface réseau eth0,
pour les faire passer sur ton réseau interne (eth1), afin que ton XP
reçoive ces paquets :

iptable -A FORWARD -i eth0 -s 0.0.0.0/0 -o eth1 -d 192.168.0.2 \
         -p tcp --dport 4662 \
         -m state --state NEW, ESTABLISHED -j ACCEPT


iptable -A FORWARD -i eth0 -s 0.0.0.0/0 -o eth1 -d 192.168.0.2 \
         -p udp --dport 4672 \
         -m state --state NEW, ESTABLISHED -j ACCEPT


- REDIRIGER les réponses de ton client P2P XP, pour qu'elles passent de
ton interface réseau interne à Internet :

iptable -A FORWARD -i eth1 -s 192.168.0.2 -o eth0 -d 0.0.0.0/0 \
         -p tcp --sport 4662 \
         -m state --state ESTABLISHED -j ACCEPT


iptable -A FORWARD -i eth1 -s 192.168.0.2 -o eth0 -d 0.0.0.0/0 \
         -p udp --sport 4672 \
         -m state --state ESTABLISHED -j ACCEPT


Mais en fait, comme toi tu utilises déjà le forwarding "en retour" pour
que ton Windows puisse surfer sur Internet, ces 2 règles ne servent à
rien. Elles font doublons avec ce que tu utilises, et qui de plus est
plus "vaste" :

iptables -A FORWARD -i eth1 -s 192.168.0.0/24 -o eth0 -d 0.0.0.0/0 \
          -m state --state NEW,ESTABLISHED,RELATED \
          -j ACCEPT


- Une dernière rêgle peut être utilisée. Il s'agit du "POSTROUTING".
Mais dans l'usage que tu fais de ton réseau interne, cette rêgle n'est
pas nécéssaire.

- Remarque importante. Tu remarqueras qu'à AUCUN moment je n'ai parlé de
règle de ta table "FILTER" autorisant les paquets externe tcp/4662 et
udp/4672 à rentrer dans ta machine. Il N'y a PAS par exemple de :

iptable -A INPUT -i eth0 -s 0.0.0.0/0 \
         -p tcp --dport 4662 \
         -m state --state NEW,ESTABLISHED -j ACCEPT


iptable -A INPUT -i eth0 -s 0.0.0.0/0 \
         -p udp --dport 4672 \
         -m state --state NEW,ESTABLISHED -j ACCEPT


    Et pourquoi cela ? Non, ce N'est PAS une erreur de ma part. C'est tout 
simplement que ces règles sont INUTILES.


    En effet, les règles FILTER de type "-A INPUT" sont destinés à laisser 
passer des paquets à destination des applications tournant sur ta 
Debian. Mais dans le cadre du forwarding, cela NE sert à RIEN. D'où 
l'importance de mettre en place la sécurité du FORWARD en utilisant le 
suivit de connexion ("-m state --state ...").


    Voir 
http://olivieraj.free.fr/fr/linux/information/firewall/pictures/filter.jpg
  pour la compréhension



    Bon, j'espère que c'est un peu plus clair maintenant. En fait, je pense 
que tu confonds le NAT et PORT FORWARDING. Ce n'est pas tout à fait la 
même chose, même si le PORT FORWARDING EST du NAT, mais que le NAT N'est 
PAS du PORT FORWARDING.


    Aiiii aiiii aiii, j'ai oublié de préciser qu'il fallait prendre 3 
aspirines avant de lire cette phrase.... Désolé... ;)


    Pour faire simple et pour résumer :
- le NAT, que tu indiques en début du mail, permet aux machines de ton 
réseau interne d'aller sur Internet


- le PORT FORWARDING permet, dans une certaine mesure, aux machines
d'Internet de dialoguer avec les machines de ton réseau interne.

> Voilà j'ai tout dis, sur ce bonne journée :)


    Toi aussi. Bon, j'espère que ce pavé n'aura pas été trop laborieux à 
lire, et qu'il est suffisamment clair.


    D'un autre coté, si tu utilisais les client P2P qui existent sous 
Linux, tu n'aurais pas eu à te poser de questions !!


http://www.xmule.org/
http://www.amule.org/
http://azureus.sourceforge.net/
....

    A plus,


                            Olivier


(*): C'est un peu faux. Il en existent, mais ils sont justement destiné
à empêcher le trafic emule !!! :)

(**): Le problème vient du fait que lorsque le emule de ton XP se
déclare sur Internet, il indique sur quels ports il écoute. Et donc
qu'il ne peut pas y avoir de différence entre les ports emule externe de
ta Debian, et ceux de ton XP

-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr/
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!