Le samedi 10 ao�t 2002, � 15:19, Gr�goire Cachet �crivait : > ce qui veut dire ?? (ouais, je sais je suis chiant ...)
Si en plus il faut expliquer... ;-) La r�gle que je t'indique autorise le passage des paquets qui viennent en r�ponse � ceux que tu as envoy�s. Sans cette r�gle, tes paquets originaires de 192.168.1.0/24 passent bien (www.free.fr re�oit bien tes pings), mais la r�ponse qui leur est donn�e, ne correspondant � aucune r�gle de la cha�ne FORWARD, est trait�e selon la politique de la cha�ne : DROP (tu ne re�oit donc pas la r�ponse de www.free.fr sur zwiffer, mais tu te rendrais compte, si tu loguais les paquets drop�s par la cha�ne Forward sur la passerelle, qu'ils sont bien arriv�s jusque l�). Je te renvoie � man iptables, � state, pour la signification des diff�rents �tats. Le processus de travers�e des diff�rentes tables est tr�s bien expliqu� dans le tutoriel d'Oskar Andreasson�: http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES > > Je me rends compte en relisant mon message d'hier soir qu'on ne devrait > > jamais r�pondre apr�s une soir�e bien arros�e et alors qu'il est temps > > d'aller se coucher... > > > > c'est possible ;-) Ma remarque sur le log des paquets est un relent d'ipchains, tout comme le fait que je n'ai pas vu tout de suite ce qui manquait dans tes r�gles (les paquets li�s � une connexion ��masquerad�e�� ne retraversent pas la cha�ne forward, avec ipchains -�qui ne permet pas le suivi de connexion). Ma remarque disant que ��c'est pas bien�� m�rite d'�tre mod�r�e. Apr�s tout, ce qui t'int�resse, c'est la translation d'adresses, pas le filtrage des paquets (pour autant que je puisse en juger). Et il vaut mieux �tre attentif � la configuration des d�mons et � la gestion des droits que faire n'importe quoi en se disant ��De toute fa�on, j'ai un pare-feu pour emp�cher les intrusions��. C'est une mesure de protection parmi d'autres, et ce n'est pas la plus importante. Mais si tu veux vraiment mettre en place un filtrage de paquet, une politique ACCEPT, c'est pas ce qu'il y a de mieux : tu laisseras passer tout ce que tu n'as pas pr�vu. Pour en revenir � ton probl�me initial et r�sumer, je te sugg�re (avec une politique de FORWARD � DROP)�: # Je te conseille de cr�er une cha�ne sp�cifique pour les interdictions # explicites. �a te permet d'y faire des ajouts ou des modifications # sans te soucier de l'ordre des r�gles. Et �a en rend la relecture plus # ais�e. iptables -N restrictions iptables -A restrictions -s 192.168.1.2 -d 213.193.13.0/24 -j DROP # On commence par v�rifier les restrictions. iptables -A FORWARD -j restrictions # Autorisation des paquets destin�s au nat. iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT # Autorisation des paquets li�s � une connexion en cours. iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT Apr�s avoir v�rifi� que �a fait bien ce que tu veux, un /etc/init.d/iptables save_active (ou save <nom_que_tu_veux>) montre que ce message a parfaitement sa place sur la liste... ;-)
