Mise à jour. Apparemment ce n'est pas le routing, mais le NAT j'avais cherchà dans la mauvaise direction. :-( Il semble que les paquets ne soit pas soumis au NAT.
donc: - je ping l'adresse interne, p.e. 192.168.3.100 - les paquet arrivent au routeur qui Ãtablit la connexion - la connexion monte et la route + le NAT sont mis en place - les paquets sont forwardÃs chez le serveur distant qui reÃoit 192.168.3.100 comme adresse pour le ping en cours et la bonne adresse, p.e. 10.1.2.3 pour toutes les connexions suivantes (mÃmes des pings). Donc finalement le ping qui a servi à Ãtablir la connexion n'est pas NATtà correctement. Moi je croyais que le ping Ãtait non connectÃ, donc je m'imaginais de voir router indÃpendamment chaque paquet (et de mÃme pour le NAT). Mais apparemment le ping ouvre une connexion ICMP avec la machine distante et envoie toutes les requÃtes sur cette connexion. La chose me parait trÃs bizarre sinon impossible (car comment peut on Ãtablir une connexion ICMP pour un ping alors que la destination n'est parfois mÃme pas up?). Il y à quelque part quelque chose que je n'ai pas complÃtement compris sur le fonctionnement du ping. Je ne connais pas de tool pour tester le UDP, donc je n'ai pas pu tester un protocole qui est sÃrement pas connectÃ. Le TCP (testà avec telnet et ssh) souffrent du mÃme problÃme, mais là je comprends, si le paquet SYN n'est pas routà correctement il est impossible que la connexion s'Ãtablisse. Le but du ping est justement celui de lancer la connexion et de voir quand elle monte grÃce aux paquets reÃus en retour. ciao, Leo On Thu, 2004-10-07 at 16:19, Leopoldo Ghielmetti wrote: > 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
