iptable > ipchain ????

[bri2]

Beaucoup de membres ont l'air préssé de voir aparaitre une distrib passerelle basé sur un 2.4 pour pouvoir utiliser iptable en lieu et place de ipchain, j'ai trouvé des docs sur les deux, je les trouve différents et iptable un peu plus...moderne !!! Mais au niveau efficacité je me demande ce qui justifie un tel empressement !!! <BR>Je suis sur que plusieurs membres ont la réponse !!!

[tomtom]

Pour moi la grosse avancée de iptables, c'est le filtrage par adresses mac ! <BR> <BR>

[arapaho]

voila les principales raison de l'attente de distribs intégrant NetFilter: <BR> <BR> 1. Pas d'infrastructure établie pour passer des paquets au userspace: <BR> * La programmation kernel est difficile. <BR> * La programmation kernel doit être faite en C/C++ <BR> * Les polices de filtrage dynamiques n'ont pas de place justifiée dans le kernel. <BR> * 2.2 a introduit la possibilité de copier des paquets vers le userspace via netlink, mais re-injecter des paquets était lent, et sujet aux vérifications de `sanité'. ex: la re-injection d'un paquet se disant provenir d'une interface existante n'était pas possible. <BR> 2. Le proxy transparent était bordellique : <BR> * On vérifie tous les paquets pour voir si il y une socket attachée à cette adresse. <BR> * root a le droit d'attacher une socket à une adresse étrangère. <BR> * Impossible de rediriger les paquets générés localement. <BR> * REDIRECT ne gère pas les réponses UDP : rediriger les paquets UDP de named vers le port 1153 ne marche pas parce que quelques clients n'aiment pas que la réponse arrive avec un port source diffèrent de 53. <BR> * REDIRECT ne se synchronise pas avec l'allocation de port TCP/UDP : un utilisateur peut avoir un port masqué par une règle REDIRECT. <BR> * A été cassé au moins 2 fois pendant la série des 2.1. <BR> * Le code est extrêmement intrusif. Considérez les stats sur le nombre de `#ifdef CONFIG_IP_TRANSPARENT_PROXY' dans le 2.2.1 : 34 occurrences dans 11 fichiers. Comparez cela à `CONFIG_IP_FIREWALL', qui a 10 occurrences dans 5 fichiers. <BR> 3. Créer une règle de filtrage de paquets indépendamment de l'adresse de l'interface n'est pas possible: <BR> * Obligation de savoir l'adresse de l'interface locale pour distinguer les paquets générés localement ou les paquet terminant en local, des paquets qui traversent seulement. <BR> * Même cela n'est pas suffisant dans les cas de redirection ou de masquerading. <BR> * La chaîne FORWARD seule a les informations sur le paquet qui sortent, ce qui veut dire que vous avez à deviner d'où le paquet est venu, ou vous avez besoin d'une bonne connaissance de la topologie du réseau que vous utilisez. <BR> 4. Le masquerading est cloué sur le filtrage de paquets: <BR> <BR> Les interactions entre le masquerading et le filtrage de paquets rendent le firewalling complexe. <BR> * Lors du filtrage dans INPUT, les paquets semblent être destinés à la machine elle même. <BR> * Lors du filtrage dans FORWARD, les paquets démasqueradés ne sont pas vu du tout. <BR> * Lors du filtrage dans OUTPUT, les paquets semblent venir de la machine locale <BR> <BR> 5. La manipulation du TOS, redirection, ``ICMP unreachable'' et le marquage de paquets (qui peu affecter le port-forwarding, le routage, et le QoS) sont cloués sur le code de filtrage de paquets aussi. <BR> 6. Le code d'ipchains n'est ni modulaire, ni extensible (par exemple: le filtrage basé sur la adresse MAC, le filtrage des options, etc). <BR> 7. Le manque d'infrastructure suffisante a mené à la profusion de différentes techniques : <BR> * Masquerading, plus des modules pour certains protocoles. <BR> * La NAT rapide par le code de routage (n'a pas de module qui gère certains protocoles). <BR> * Le port-forwarding, la redirection, et le auto-forwarding <BR> 8. Incompatibilité entre CONFIG_NET_FASTROUTE et le filtrage de paquets: <BR> * Les paquets qui ne font que nous traverser doivent passer par trois chaînes de toutes façons. <BR> * Impossible de dire si ces chaînes peuvent être évitées. <BR> 9. L'inspection de paquets détruits est impossible à cause d'une protection de routage (par exemple: la vérification d'adresse source). <BR> 10. Impossible de lire automatiquement les compteurs sur les règle de filtrage de paquets. <BR> 11. CONFIG_IP_ALWAYS_DEFRAG est une option à la compilation seulement, rendant la vie difficile pour les distributions qui veulent un kernel général. <BR> <BR> <BR>(tout ceci est extrait du NetFilter How-ti de Rusty Russel, concepteur et développeur de NetFilter) <BR> <BR>Mais je suis sur que pour la majorité des membres, NetFilter ne représente que kelke chose de nouveau. En effet, je pense que les membres les plus attirés vers NetFilter ont déja viré leur distrib firewall pour installer une distrib Linux 'normale' pour bénéficier du support NetFilter, qui existe depuis bientot près de 2 ans.