VoilÃ, pour le moment j'ai trouvà une solution effectivement beaucoup plus facile que celle de commencer à patcher kernel+iptables. Merci pour le conseil.
La solution consiste à rediriger les adresses internes sur les diffÃrentes interfaces tap crÃes par diald. Ensuite quand l'interface est up un script se charge de faire le NAT entre les adresses internes concernÃs par l'interface sur les adresses externes, et d'implÃmenter les routes nÃcessaires. Le NAT et les routes sont dÃtruites dÃs que la connexion tombe. Ceci me permet de rediriger uniquement les adresses internes qui m'intÃressent. Comme solution n'est pas trop mal tant qu'on à un seul modem. Ãa peut par contre poser des problÃmes si on veut avoir plusieurs connexion en mÃme temps et avec des clients avec les mÃmes numÃros IP. Ãa peut mÃme poser des problÃmes si on veut se connecter chez un client qui a la mÃme adresse IP que le PC depuis lequel on veut se connecter (mais ce cas peut Ãtre facilement reconnu et ÃvitÃ). Par contre j'ai maintenant un autre problÃme. Je commence la connexion en faisant un ping, mais mÃme si la connexion monte je n'obtiens aucune rÃponse. Il faut l'arrÃter et le relancer et à ce moment les paquets seront routes correctement. Il semblerait que mÃme en changeant les routes via le script au moment que la connexion monte, le routage ne se fait correctement. Comme si le paquets Ãtaient toujours dirigÃs vers l'interface tap au lieu de l'interface ppp. Seul les nouvelles connexions (et les nouveaux ping) sont correctement routes. Ãa fait maintenant 2 jours que j'essaie de comprendre ce phÃnomÃne, mais je n'ai pas rÃussi. Quelqu'un à une idÃe? ciao, Leo On Fri, 2004-10-01 at 17:20, Marc SCHAEFER wrote: > On Fri, Oct 01, 2004 at 04:21:10PM +0200, Leopoldo Ghielmetti wrote: > > Seulement que iptables fait le DNAT puis le routing et ensuite le SNAT > > et il n'y a pas moyen de faire l'inverse. Et qui plus est il n'y a pas > > Si, c'est possible. Voir les commandes ip rule et ip route. On peut > crÃer plusieurs tables de routage, activÃes en fonction de rÃgle de > marquage du firewall. > > Par exemple (exemple compliquÃ, peut-Ãtre n'est-il pas nÃcessaire > d'aller jusque-lÃ). Ce que Ãa fait: les paquets provenant de la machine > locale sont routÃes en fonction de l'adresse source. Les paquets > traversants sont marquÃs à l'entrÃe en fonction de leur adresse source, > puis à la sortie la marque est utilisÃe. > > La seule particularità est qu'on utilise un patch à iptables qui permet > de rendre les marques *persistantes* sur un nexus (si tu veux une > `connexion' au sens du firewall stateful iptables: pas forcÃment du TCP). > Sans ce patch `--save-mark' est impossible. > > Sans ce patch il est difficile de router correctement les paquets en > retour dans le cas gÃnÃral. > > Je ne suis pas sÃr que tu as besoin d'une solution si complexe, mais > peut-Ãtre que cela te mettra dans la bonne direction (tables de routage > multiples dÃcidÃes en fonction d'une marque du firewall). > > # New routing table > ip route add default via 192.168.2.1 table 4 > > # For local host both ways > ip rule add from 192.168.2.10/32 table 4 > > # No martians > echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter > > iptables -t mangle -F > > iptables -A PREROUTING \ > -i eth0 -s 192.168.3.0/24 -p tcp --sport 25 \ > -t mangle -j CONNMARK --restore-mark > > iptables -A PREROUTING \ > -i eth0 -s 192.168.3.0/24 -p tcp --sport 25 \ > -m mark --mark 2 \ > -t mangle -j MARK --set-mark 4 > > iptables -A PREROUTING -t mangle -m mark ! --mark 0 -j ACCEPT > > iptables -A PREROUTING \ > -i eth1 -d 192.168.2.10/32 -p tcp --dport 25 \ > -t mangle -j MARK --set-mark 2 > > iptables -A PREROUTING \ > -i eth1 -d 192.168.2.10/32 -p tcp --dport 25 \ > -t mangle -j CONNMARK --save-mark > > # Special routing depending on mark > ip rule add fwmark 4 table 4 > > _______________________________________________ > gull mailing list > [EMAIL PROTECTED] > http://lists.alphanet.ch/mailman/listinfo/gull > >
signature.asc
Description: This is a digitally signed message part
