pascal a écrit :
iptables -P INPUT ACCEPTLes 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'ai oublié de dire que je ne voyais pas non plus de règle autorisant le trafic en sortie sur eth1, l'interface vers le LAN.
[...]
-A POSTROUTING -s 192.162.2.21 -o eth0 -j SNAT --to-source 192.168.1.20 -A POSTROUTING -s 192.162.2.23 -o eth0 -j SNAT --to-source 192.168.1.20^^^ Je pense qu'il y a une petite erreur de frappe dans les adresses des options -s : 192.162 au lieu de 192.168.Rhaa c'est pas vrai. Quelle honte de laisser passer des coquilles pareilles !
Tu l'as dit. Quelle honte que je n'aie pas vu ça lors de ma première réponse...
Aussi, pourquoi ne pas créer une seule règle avec -s 192.168.2.0/24 ? Si tu ne veux autoriser que ces deux postes à sortir, il vaut mieux le faire dans les règles de filtrage plutôt que dans les règles de NAT.
[...]
Hé bien primitivement, c'était sous cette forme qu'était rédigée la règle concernant ces deux postes. Mais voilà : comme ils appartiennent à deux jeunes filles d'âges différents je voulais pouvoir agir sur ces postes de façon différente grâce à une ligne dans la crontab...
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.
Si l'erreur est corrigée ils seront bien Natés tout de même, non ?
Oui, bien sûr.
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.