Benjamin RIOU a écrit :
Oui, connlimit était l'idéal pour moi, mais il me répond continuellement : iptables: No chain/target/match by that name Bien que le fichier libipt_connlimit.ko est bien dans /lib/iptables/ Donc c'est parce que cela ne serait pas inclus au kernel ?
Voilà.
C'est étrange dans la mesure où : iptables -m connlimit --help répond correctement.
C'est la bibliothèque libipt_connlimit d'iptables qui répond.
et que le module connlimit est présent dans le man d'iptables...
Comme pour un grand nombre de cibles et de correspondances d'iptables, il faut deux éléments : - une bibliothèque libipt_truc.so située dans /lib/iptables/ et utilisée par le programme iptables lors de la création d'une règle ; - un module du noyau ipt_truc.[k]o ou xt_truc.ko situé dans /lib/modules/<version>/kernel/net/... qui réalise effectivement la fonction lorsqu'un paquet rencontre la règle. Notons que la fonction peut être compilée en dur dans le noyau et non en module.
Ici comme souvent, c'est le module noyau qui manque, car iptables contient depuis longtemps des extensions qui ne sont pas présentes en standard dans le noyau mais fournies à part dans le patch-o-matic[-ng]. Parfois c'est le contraire, par exemple quand la version d'iptables est trop ancienne pour le noyau. C'est le cas actuellement avec le dernier iptables 1.3.7, plus ancien que le dernier noyau 2.6.21. Il y a aussi le cas intermédiaire, quand un nouvelle option est ajoutée à une cible ou une correspondance existante ; il faut qu'à la fois le module du noyau et la bibliothèque d'iptables la prennent en charge pour pouvoir l'exploiter. Ce fut par exemple le cas du support des intervalles de ports dans la correspondance "multiport", introduit dans le noyau 2.6.11 et iptables 1.3.0 (je crois).