> J'aurais volontier dit que les reponses de ma machine etaient
> autorisees par cette regle, sans qu'il soit besoin de faire usage du
> suivi de connexion:
>
> iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s $WAN_IP -d
> $WAN_NETWORK -p all -m state --state ! INVALID -j ACCEPT
Non, car cette règle a pour but de laisser passer les RÉPONSES des
paquets qui ont précédemment été traités par le module de suivit de
connexion ("-m state --state xxxx"). Or tes précédentes règles P2P en
INPUT N'utilisent PAS le module de connexion. Donc la règle ci-dessus NE
peut PAS les gérer, car ces paquets ne font pas parti de ceux que le
module doit surveiller.
Comme tu l'as fais, tu peux très bien écrire certaines règles qui
utilisent le conntrack et d'autres non. C'est particulièrement utile si
tu as de gros volumes de connexions à traiter, et que tu veux garder un
bon temps de réponse malgrès un CPU faible. Dans ce cas là, tu peux
écrire certaines règles qui n'utilisent pas suivit de connexion. Mais il
faut alors que tu sois sûr à 100% de la machine avec qui tu dialogues
pour ces connexions-ci. Ors avec le P2P, ce n'est pas le cas, donc il
faut que tes règles en INPUT utilisent le conntrack.
> C'est pas grave si les statistiques ne font pas la différence entre
> les différents réseaux P2P... Je ne me doutais pas que regrouper les
> règles ipatables puisse améliorer les perfomances de netfiter. La
> différence est-elle significative ?
C'est une bonne question : Tout va dépendre de la puissance du
processeur et de la quantité de paquets qu'il y a à traiter. Sur une
grosse passerelle connectée à un gros réseau LAN, cela peut être
sensible. Dans le cas de ta connexion modem, si en plus tu as un
processeur qui n'est pas trop chargé, la différence sera peu visible. En
fait, c'est au niveau du ping (le temps de transmission de l'information
d'un bout à l'autre d'une connexion) que cela se verra.
Olivier
