Pascal Hambourg a écrit : > pascal a écrit : >>> >>> Les politiques par défaut des chaînes INPUT et FORWARD ne sont pas >>> modifiées. Donc si elles étaient à DROP elle le restent, ce qui bloque >>> le trafic sortant et routé. > > Correction : je voulais dire "des chaînes *OUTPUT* et FORWARD" bien sûr.
J'avais corrigé...A tel point que je n'avais même pas vu l'erreur. > > Soit, mais comme je l'ai déjà dit, il vaut mieux faire ce filtrage dans > la chaîne FORWARD de la table 'filter' qui est là pour ça. Les chaînes > de la table 'nat' sont faites pour le NAT et rien d'autre. Compte tenu > de leur comportement particulier (elles ne voient passer que le premier > paquet d'une nouvelle connexion), s'en servir pour faire du filtrage > expose à des effets de bord. En particulier la création et la > suppression de règles NAT n'ont aucune influence sur les paquets > appartenant ou liés aux connexions déjà établies : les paquets des > connexions existantes continuent d'être NATés de la même façon. > > Exemple pratique : > Pendant que la règle SNAT est en place, l'utilisatrice établit une > connexion avec un logiciel de messagerie instantanée. Arrive l'heure où > la règle SNAT est supprimée. Malgré cela, tant que la connexion > existante reste établie, la translation d'adresse et de port mise en > place pour elle par le passage du premier paquet reste active et > l'utilisatrice peut continuer à tchatter jusqu'à pas d'heure. > > Il faut plutôt introduire ces adresses dans les règles de filtrage de la > chaîne FORWARD, y compris celles gérant l'état ESTABLISHED,RELATED sinon > les connexions existantes continueront à passer. Et lors de la coupure > utiliser la cible REJECT au lieu de DROP afin de signaler que le > connexion est coupée, c'est plus poli. Ca me parle cet exemple :-) Et en plus j'avais (au moins) assimilé cet aspect du NAT. Néanmoins... Heu en fait elles y sont ces règles. Mais bon comme je craignais qu'elles fassent double emplois et pour ne pas aggraver mon cas je ne les ai pas présentées içi. Oui je sais... Mais là, à cette heure, je ne suis plus à ça près ... En plus (faut pas taper) elles n'ont pas la bonne forme : iptables -A FORWARD -i $LAN_IFACE -o $INET_IFACE -m state --state ! INVALID -j ACCEPT iptables -A FORWARD -i $INET_IFACE -o $LAN_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT Et si je ne craignais pas d'abuser... Il faut donc que ces deux systèmes de règle soient présents (l'un pour le SNAT et l'autre pour le filtrage) à la fois ? Et il n' y a pas là de redondance, alors ? Mais dans la chaîne FORWARD de la table filter, puis-je distinguer les deux machines (via "-s") ou suis-je contraint comme dans les lignes précédentes à raisonner en termes d'interface d'entrée et de sortie du routeur ? Merci encore pour ton attention. En fait je crois avoir du mal à m'imaginer les relations exactes et précises liant les tables aux chaînes. A m'en faire une représentation mentale. Ca n'est pas très clair pour moi. Malgré mes lectures. >> Juste au passage : "plouf" ça me rappelle linux.fr et la tribune . Il y >> a de celà quelques années...Il y a un lien ? > > Je ne crois pas. J'ai créé et commencé à utiliser ce domaine en été > 2004, et je n'ai jamais participé à des discussions sur ces sites. > OK. Au temps pour moi. Hé bien bonne nuit...Ou ce qu'il en reste. P. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
