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 !!
