J'ai un souci, un truc incompréhensible... Considérons une machine
qui possède trois cartes réseau avec trois adresses :
192.168.1.1 -> eth2 sur un routeur ADSL et une adresse IP fixe
publique
192.168.254.1 -> eth0, même configuration
192.168.0.128 -> eth1, réseau local.
Tous les services (http, https, pop3s, imaps, smtp...) passent par
eth0 et fonctionnent. Toutes les requêtes du réseau local sont
reroutées sur eth0 (la machine fait du nat).
Le port 8000 entrant sur eth0 est rerouté par iptables sur eth1:8080
et fonctionne.
Seuls trois ports sont autorisés sur eth2 : ssh et les 3000 et 3001.
Le ssh fonctionne, donc l'interface est bien configurée. Par contre,
pas moyen de forwarder les ports 3000 et 3001 sur une machine du
réseau local. Par contre, je peux forwarder les ports entrant 3000
et 3001 du port eth0 vers cette machine. Un peu comme s'il était
impossible de fowarder un port arrivant sur une table de routage
autre que main. J'ai googlisé sans succès depuis avant-hier et je
sèche.
Pour information :
Root kant:[~] > ip rule list
0: from all lookup local
32763: from all fwmark 0xbb9 lookup intranet
32764: from all fwmark 0xbb8 lookup intranet
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2
Root kant:[~] > ip route list table main
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.128
192.168.254.0/24 dev eth0 proto kernel scope link src 192.168.254.1
default via 192.168.254.254 dev eth0
Root kant:[~] > Root kant:[~] > iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere kant.astelys.fr
ACCEPT all -- anywhere bergson.astelys.fr
ACCEPT tcp -- anywhere thibon.astelys.fr tcp dpt:ssh
ACCEPT tcp -- anywhere thibon.astelys.fr tcp
dpt:3000
ACCEPT tcp -- anywhere thibon.astelys.fr tcp
dpt:3001
Je ne vois vraiment pas ce qui coince. La machine est une UltraSparc
tournant sous Debian (noyau officiel 2.4.29). Je précise que je vois
arriver les paquets sur eth2:3000, mais que ceux-ci sont ignorés par
les règles de la table nat d'iptables...
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
J'ai rajouté une règle pour que : Root kant:[/var/log] > ip rule show 0: from all lookup local 90: from 192.168.0.130 lookup intranet 100: from 192.168.1.1 lookup intranet 101: from all fwmark 0x1 lookup intranet 32766: from all lookup main 32767: from all lookup default Root kant:[/var/log] >
Et là, tous mes paquets issus de 192.168.0.130 sortent par l'interface eth2 (or je ne veux que les ports 3000 et 3001).
Ce qui indique que le reste de la configuration est donc correcte.
Donc, ce qui coince, c'est la règle 101 sur la marque 0x1.
Oui. Soit parce que les paquets ne sont pas marqués ou soit parce que les paquets sont marqués mais pas vu comme tel ou avec la bonne valeur de mark. En tout cas tout semble indiquer que le problème se situe au niveau du marquage des paquets.
J'ai pourtant autant de paquets marqués que loggués :
59 3540 MARK tcp -- * * 192.168.0.130 0.0.0.0/0 tcp spts:3000:3001 MARK set 0x1 59 3540 LOG all -- * * 192.168.0.130 0.0.0.0/0 LOG flags 0 level 4 prefix `Mangle : '
Plus on avance et plus c'est incompréhensible. À croire qu'il s'agisse d'un bug de iproute2 ou du noyau mais cela me paraît assez impropable. Essayez avec une autre version de noyau et/ou une autre version de iproute2. Je vous ai mit à l'URL suivante :
http://magnolia.tichou.org/~tichou/ip.bz2
une version statique de la commande ip et qui fonctionne bien chez moi, cela vous servira peut-être. C'est la version iproute2-ss050112.
Essayez aussi, dans votre règle iptables, de vous limiter au seul port 3000 (soit --sport 3000) et aussi avec d'autre valeur de mark.
-- TiChou
Dans le message <news:slrnd1h20g.ea0.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
J'ai rajouté une règle pour que :
Root kant:[/var/log] > ip rule show
0: from all lookup local
90: from 192.168.0.130 lookup intranet
100: from 192.168.1.1 lookup intranet
101: from all fwmark 0x1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Root kant:[/var/log] >
Et là, tous mes paquets issus de 192.168.0.130 sortent par
l'interface eth2 (or je ne veux que les ports 3000 et 3001).
Ce qui indique que le reste de la configuration est donc correcte.
Donc, ce qui coince, c'est la règle 101 sur la marque 0x1.
Oui. Soit parce que les paquets ne sont pas marqués ou soit parce que les
paquets sont marqués mais pas vu comme tel ou avec la bonne valeur de mark.
En tout cas tout semble indiquer que le problème se situe au niveau du
marquage des paquets.
J'ai pourtant autant de paquets marqués que loggués :
59 3540 MARK tcp -- * * 192.168.0.130
0.0.0.0/0 tcp spts:3000:3001 MARK set 0x1
59 3540 LOG all -- * * 192.168.0.130
0.0.0.0/0 LOG flags 0 level 4 prefix `Mangle : '
Plus on avance et plus c'est incompréhensible. À croire qu'il s'agisse d'un
bug de iproute2 ou du noyau mais cela me paraît assez impropable. Essayez
avec une autre version de noyau et/ou une autre version de iproute2. Je vous
ai mit à l'URL suivante :
http://magnolia.tichou.org/~tichou/ip.bz2
une version statique de la commande ip et qui fonctionne bien chez moi, cela
vous servira peut-être. C'est la version iproute2-ss050112.
Essayez aussi, dans votre règle iptables, de vous limiter au seul port 3000
(soit --sport 3000) et aussi avec d'autre valeur de mark.
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
J'ai rajouté une règle pour que : Root kant:[/var/log] > ip rule show 0: from all lookup local 90: from 192.168.0.130 lookup intranet 100: from 192.168.1.1 lookup intranet 101: from all fwmark 0x1 lookup intranet 32766: from all lookup main 32767: from all lookup default Root kant:[/var/log] >
Et là, tous mes paquets issus de 192.168.0.130 sortent par l'interface eth2 (or je ne veux que les ports 3000 et 3001).
Ce qui indique que le reste de la configuration est donc correcte.
Donc, ce qui coince, c'est la règle 101 sur la marque 0x1.
Oui. Soit parce que les paquets ne sont pas marqués ou soit parce que les paquets sont marqués mais pas vu comme tel ou avec la bonne valeur de mark. En tout cas tout semble indiquer que le problème se situe au niveau du marquage des paquets.
J'ai pourtant autant de paquets marqués que loggués :
59 3540 MARK tcp -- * * 192.168.0.130 0.0.0.0/0 tcp spts:3000:3001 MARK set 0x1 59 3540 LOG all -- * * 192.168.0.130 0.0.0.0/0 LOG flags 0 level 4 prefix `Mangle : '
Plus on avance et plus c'est incompréhensible. À croire qu'il s'agisse d'un bug de iproute2 ou du noyau mais cela me paraît assez impropable. Essayez avec une autre version de noyau et/ou une autre version de iproute2. Je vous ai mit à l'URL suivante :
http://magnolia.tichou.org/~tichou/ip.bz2
une version statique de la commande ip et qui fonctionne bien chez moi, cela vous servira peut-être. C'est la version iproute2-ss050112.
Essayez aussi, dans votre règle iptables, de vous limiter au seul port 3000 (soit --sport 3000) et aussi avec d'autre valeur de mark.
-- TiChou
JKB
Le 20-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), TiChou écrivait dans fr.comp.os.linux.configuration :
Oui. Soit parce que les paquets ne sont pas marqués ou soit parce que les paquets sont marqués mais pas vu comme tel ou avec la bonne valeur de mark. En tout cas tout semble indiquer que le problème se situe au niveau du marquage des paquets.
J'ai pourtant autant de paquets marqués que loggués :
59 3540 MARK tcp -- * * 192.168.0.130 0.0.0.0/0 tcp spts:3000:3001 MARK set 0x1 59 3540 LOG all -- * * 192.168.0.130 0.0.0.0/0 LOG flags 0 level 4 prefix `Mangle : '
Plus on avance et plus c'est incompréhensible. À croire qu'il s'agisse d'un bug de iproute2 ou du noyau mais cela me paraît assez impropable. Essayez avec une autre version de noyau et/ou une autre version de iproute2. Je vous ai mit à l'URL suivante :
http://magnolia.tichou.org/~tichou/ip.bz2
Je tente un 2.6.10 (sauce debian), mais je ne risque pas un reboot à distance sur un tel noyau compilé pour sparc64... La suite demain...
une version statique de la commande ip et qui fonctionne bien chez moi, cela vous servira peut-être. C'est la version iproute2-ss050112.
Ip ne sert qu'à écrire dans les tables du noyau, non ? Je pencherais plutôt pour un bug du noyau...
Essayez aussi, dans votre règle iptables, de vous limiter au seul port 3000 (soit --sport 3000) et aussi avec d'autre valeur de mark.
Déjà essayé ;-)
JKB
Le 20-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :
Oui. Soit parce que les paquets ne sont pas marqués ou soit parce que les
paquets sont marqués mais pas vu comme tel ou avec la bonne valeur de mark.
En tout cas tout semble indiquer que le problème se situe au niveau du
marquage des paquets.
J'ai pourtant autant de paquets marqués que loggués :
59 3540 MARK tcp -- * * 192.168.0.130
0.0.0.0/0 tcp spts:3000:3001 MARK set 0x1
59 3540 LOG all -- * * 192.168.0.130
0.0.0.0/0 LOG flags 0 level 4 prefix `Mangle : '
Plus on avance et plus c'est incompréhensible. À croire qu'il s'agisse d'un
bug de iproute2 ou du noyau mais cela me paraît assez impropable. Essayez
avec une autre version de noyau et/ou une autre version de iproute2. Je vous
ai mit à l'URL suivante :
http://magnolia.tichou.org/~tichou/ip.bz2
Je tente un 2.6.10 (sauce debian), mais je ne risque pas un reboot à
distance sur un tel noyau compilé pour sparc64... La suite demain...
une version statique de la commande ip et qui fonctionne bien chez moi, cela
vous servira peut-être. C'est la version iproute2-ss050112.
Ip ne sert qu'à écrire dans les tables du noyau, non ? Je pencherais
plutôt pour un bug du noyau...
Essayez aussi, dans votre règle iptables, de vous limiter au seul port 3000
(soit --sport 3000) et aussi avec d'autre valeur de mark.
Le 20-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), TiChou écrivait dans fr.comp.os.linux.configuration :
Oui. Soit parce que les paquets ne sont pas marqués ou soit parce que les paquets sont marqués mais pas vu comme tel ou avec la bonne valeur de mark. En tout cas tout semble indiquer que le problème se situe au niveau du marquage des paquets.
J'ai pourtant autant de paquets marqués que loggués :
59 3540 MARK tcp -- * * 192.168.0.130 0.0.0.0/0 tcp spts:3000:3001 MARK set 0x1 59 3540 LOG all -- * * 192.168.0.130 0.0.0.0/0 LOG flags 0 level 4 prefix `Mangle : '
Plus on avance et plus c'est incompréhensible. À croire qu'il s'agisse d'un bug de iproute2 ou du noyau mais cela me paraît assez impropable. Essayez avec une autre version de noyau et/ou une autre version de iproute2. Je vous ai mit à l'URL suivante :
http://magnolia.tichou.org/~tichou/ip.bz2
Je tente un 2.6.10 (sauce debian), mais je ne risque pas un reboot à distance sur un tel noyau compilé pour sparc64... La suite demain...
une version statique de la commande ip et qui fonctionne bien chez moi, cela vous servira peut-être. C'est la version iproute2-ss050112.
Ip ne sert qu'à écrire dans les tables du noyau, non ? Je pencherais plutôt pour un bug du noyau...
Essayez aussi, dans votre règle iptables, de vous limiter au seul port 3000 (soit --sport 3000) et aussi avec d'autre valeur de mark.
Déjà essayé ;-)
JKB
Pascal
Salut,
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
Salut,
Pour mon problème, je suis en train de me demander si ce n'est pas
un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je
referai la manip grandeur nature ce soir avec lui si d'ici là ton
problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
TiChou
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
Ip ne sert qu'à écrire dans les tables du noyau, non ?
Tout à fait, mais votre commande 'ip' peut très bien être buggé et mal écrire ou lire dans ces tables.
Je pencherais plutôt pour un bug du noyau...
Moi aussi.
-- TiChou
Dans le message <news:slrnd1hkta.kto.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
Ip ne sert qu'à écrire dans les tables du noyau, non ?
Tout à fait, mais votre commande 'ip' peut très bien être buggé et mal
écrire ou lire dans ces tables.
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
Est-ce que vous pourriez tenter l'expérience avec un 2.4.29 (je ne peux pas changer le noyau de la machine en question facilement) ?
Moi non plus ou pas dans l'immédiat en tout cas.
-- TiChou
TiChou
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.254.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -o ppp1 -s 192.168.254.0/24 -j MASQUERADE Pourquoi natez-vous l'interface qui ne sert qu'à votre serveur web ?
Je ne comprends pas bien votre question. D'autant plus que vous en faites de même sur votre machine et vous faites bien de le faire. Il faut que les paquets venant de l'interface ppp0 et qui seront forwardés vers l'interface ppp1 soient natés sinon la passerelle/routeur se trouvant derrière l'interface ppp1 ne sera pas où renvoyer les paquets retours.
Je ne nate qu'une interface, le lien principal.
Dans votre copie de iptables-save :
http://www.systella.fr/~bertrand/fichier
vous natez bien les paquets venant de eth1 et sortant sur eth0 ou eth2.
Je ne vois pas l'intérêt de le faire pour ma connexion intranet. Les paquets sortent avec une adresse IP publique, et le routage suffit.
Mais si vous ne natez pas sur l'interface de sortie eth2, les paquets entrant sur l'interface eth1 et sortant sur l'interface eth2 auront comme adresse IP source une adresse dans la plage 192.168.0.0/24 et est-ce qu'alors le routeur se trouvant derrière cette interface est autorisé à router les paquets dont l'adresse IP source est dans la plage 192.168.0.0/24 ? Pourquoi pas après tout, mais alors pourquoi ça serait le cas sur le routeur se situant derrière eth2 et pas le cas pour le routeur se situant derrière eth0 ?
-- TiChou
Dans le message <news:slrnd1hdtq.kto.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.254.0/24 -j
MASQUERADE
iptables -t nat -A POSTROUTING -o ppp1 -s 192.168.254.0/24
-j MASQUERADE
Pourquoi natez-vous l'interface qui ne sert qu'à votre serveur web ?
Je ne comprends pas bien votre question. D'autant plus que vous en
faites de même sur votre machine et vous faites bien de le faire. Il
faut que les paquets venant de l'interface ppp0 et qui seront forwardés
vers l'interface ppp1 soient natés sinon la passerelle/routeur se
trouvant derrière l'interface ppp1 ne sera pas où renvoyer les paquets
retours.
Je ne nate qu'une interface, le lien principal.
Dans votre copie de iptables-save :
http://www.systella.fr/~bertrand/fichier
vous natez bien les paquets venant de eth1 et sortant sur eth0 ou eth2.
Je ne vois pas l'intérêt de le faire pour ma connexion intranet. Les
paquets sortent avec une adresse IP publique, et le routage suffit.
Mais si vous ne natez pas sur l'interface de sortie eth2, les paquets
entrant sur l'interface eth1 et sortant sur l'interface eth2 auront comme
adresse IP source une adresse dans la plage 192.168.0.0/24 et est-ce
qu'alors le routeur se trouvant derrière cette interface est autorisé à
router les paquets dont l'adresse IP source est dans la plage 192.168.0.0/24
? Pourquoi pas après tout, mais alors pourquoi ça serait le cas sur le
routeur se situant derrière eth2 et pas le cas pour le routeur se situant
derrière eth0 ?
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.254.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -o ppp1 -s 192.168.254.0/24 -j MASQUERADE Pourquoi natez-vous l'interface qui ne sert qu'à votre serveur web ?
Je ne comprends pas bien votre question. D'autant plus que vous en faites de même sur votre machine et vous faites bien de le faire. Il faut que les paquets venant de l'interface ppp0 et qui seront forwardés vers l'interface ppp1 soient natés sinon la passerelle/routeur se trouvant derrière l'interface ppp1 ne sera pas où renvoyer les paquets retours.
Je ne nate qu'une interface, le lien principal.
Dans votre copie de iptables-save :
http://www.systella.fr/~bertrand/fichier
vous natez bien les paquets venant de eth1 et sortant sur eth0 ou eth2.
Je ne vois pas l'intérêt de le faire pour ma connexion intranet. Les paquets sortent avec une adresse IP publique, et le routage suffit.
Mais si vous ne natez pas sur l'interface de sortie eth2, les paquets entrant sur l'interface eth1 et sortant sur l'interface eth2 auront comme adresse IP source une adresse dans la plage 192.168.0.0/24 et est-ce qu'alors le routeur se trouvant derrière cette interface est autorisé à router les paquets dont l'adresse IP source est dans la plage 192.168.0.0/24 ? Pourquoi pas après tout, mais alors pourquoi ça serait le cas sur le routeur se situant derrière eth2 et pas le cas pour le routeur se situant derrière eth0 ?
-- TiChou
JKB
Le 21-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Salut,
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
Je suis en train d'essayer de booter un 2.6.10 sur la machine en question, mais il s'agit d'une Sparc64 et le 2.6.10 n'a pas l'air de vouloir reconnaître mon raid lors du boot...
JKB
Le 21-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
Salut,
Pour mon problème, je suis en train de me demander si ce n'est pas
un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je
referai la manip grandeur nature ce soir avec lui si d'ici là ton
problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
Je suis en train d'essayer de booter un 2.6.10 sur la machine en
question, mais il s'agit d'une Sparc64 et le 2.6.10 n'a pas l'air de
vouloir reconnaître mon raid lors du boot...
Le 21-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Salut,
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
Je suis en train d'essayer de booter un 2.6.10 sur la machine en question, mais il s'agit d'une Sparc64 et le 2.6.10 n'a pas l'air de vouloir reconnaître mon raid lors du boot...
JKB
JKB
Le 21-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), TiChou écrivait dans fr.comp.os.linux.configuration :
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.254.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -o ppp1 -s 192.168.254.0/24 -j MASQUERADE Pourquoi natez-vous l'interface qui ne sert qu'à votre serveur web ?
Je ne comprends pas bien votre question. D'autant plus que vous en faites de même sur votre machine et vous faites bien de le faire. Il faut que les paquets venant de l'interface ppp0 et qui seront forwardés vers l'interface ppp1 soient natés sinon la passerelle/routeur se trouvant derrière l'interface ppp1 ne sera pas où renvoyer les paquets retours.
Je ne nate qu'une interface, le lien principal.
Dans votre copie de iptables-save :
http://www.systella.fr/~bertrand/fichier
vous natez bien les paquets venant de eth1 et sortant sur eth0 ou eth2.
Possible, mais c'est idiot ;-)
Je ne vois pas l'intérêt de le faire pour ma connexion intranet. Les paquets sortent avec une adresse IP publique, et le routage suffit.
Mais si vous ne natez pas sur l'interface de sortie eth2, les paquets entrant sur l'interface eth1 et sortant sur l'interface eth2 auront comme adresse IP source une adresse dans la plage 192.168.0.0/24 et est-ce qu'alors le routeur se trouvant derrière cette interface est autorisé à router les paquets dont l'adresse IP source est dans la plage 192.168.0.0/24 ? Pourquoi pas après tout, mais alors pourquoi ça serait le cas sur le routeur se situant derrière eth2 et pas le cas pour le routeur se situant derrière eth0 ?
De toute façon, avec ou sans NAT, le résultat est le même. De toute façon, tant que les paquets n'arrivent pas sur le routeur en question, la question ne se pose même pas ;-)
JKB
Le 21-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :
Dans le message <news:slrnd1hdtq.kto.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.254.0/24 -j
MASQUERADE
iptables -t nat -A POSTROUTING -o ppp1 -s 192.168.254.0/24
-j MASQUERADE
Pourquoi natez-vous l'interface qui ne sert qu'à votre serveur web ?
Je ne comprends pas bien votre question. D'autant plus que vous en
faites de même sur votre machine et vous faites bien de le faire. Il
faut que les paquets venant de l'interface ppp0 et qui seront forwardés
vers l'interface ppp1 soient natés sinon la passerelle/routeur se
trouvant derrière l'interface ppp1 ne sera pas où renvoyer les paquets
retours.
Je ne nate qu'une interface, le lien principal.
Dans votre copie de iptables-save :
http://www.systella.fr/~bertrand/fichier
vous natez bien les paquets venant de eth1 et sortant sur eth0 ou eth2.
Possible, mais c'est idiot ;-)
Je ne vois pas l'intérêt de le faire pour ma connexion intranet. Les
paquets sortent avec une adresse IP publique, et le routage suffit.
Mais si vous ne natez pas sur l'interface de sortie eth2, les paquets
entrant sur l'interface eth1 et sortant sur l'interface eth2 auront comme
adresse IP source une adresse dans la plage 192.168.0.0/24 et est-ce
qu'alors le routeur se trouvant derrière cette interface est autorisé à
router les paquets dont l'adresse IP source est dans la plage 192.168.0.0/24
? Pourquoi pas après tout, mais alors pourquoi ça serait le cas sur le
routeur se situant derrière eth2 et pas le cas pour le routeur se situant
derrière eth0 ?
De toute façon, avec ou sans NAT, le résultat est le même. De toute
façon, tant que les paquets n'arrivent pas sur le routeur en
question, la question ne se pose même pas ;-)
Le 21-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), TiChou écrivait dans fr.comp.os.linux.configuration :
Dans le message <news:, *JKB* tapota sur f.c.o.l.configuration :
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.254.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -o ppp1 -s 192.168.254.0/24 -j MASQUERADE Pourquoi natez-vous l'interface qui ne sert qu'à votre serveur web ?
Je ne comprends pas bien votre question. D'autant plus que vous en faites de même sur votre machine et vous faites bien de le faire. Il faut que les paquets venant de l'interface ppp0 et qui seront forwardés vers l'interface ppp1 soient natés sinon la passerelle/routeur se trouvant derrière l'interface ppp1 ne sera pas où renvoyer les paquets retours.
Je ne nate qu'une interface, le lien principal.
Dans votre copie de iptables-save :
http://www.systella.fr/~bertrand/fichier
vous natez bien les paquets venant de eth1 et sortant sur eth0 ou eth2.
Possible, mais c'est idiot ;-)
Je ne vois pas l'intérêt de le faire pour ma connexion intranet. Les paquets sortent avec une adresse IP publique, et le routage suffit.
Mais si vous ne natez pas sur l'interface de sortie eth2, les paquets entrant sur l'interface eth1 et sortant sur l'interface eth2 auront comme adresse IP source une adresse dans la plage 192.168.0.0/24 et est-ce qu'alors le routeur se trouvant derrière cette interface est autorisé à router les paquets dont l'adresse IP source est dans la plage 192.168.0.0/24 ? Pourquoi pas après tout, mais alors pourquoi ça serait le cas sur le routeur se situant derrière eth2 et pas le cas pour le routeur se situant derrière eth0 ?
De toute façon, avec ou sans NAT, le résultat est le même. De toute façon, tant que les paquets n'arrivent pas sur le routeur en question, la question ne se pose même pas ;-)
JKB
Pascal
Re,
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
J'ai eu le temps de faire un petit test vite fait juste pour tester le marquage+routage du noyau 2.4.29. A priori il n'est pas en cause ; les paquets marqués sont routés sur la bonne interface. La suite ce soir.
-- Adresse attrape-spam :
Re,
Pour mon problème, je suis en train de me demander si ce n'est pas
un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je
referai la manip grandeur nature ce soir avec lui si d'ici là ton
problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
J'ai eu le temps de faire un petit test vite fait juste pour tester le
marquage+routage du noyau 2.4.29. A priori il n'est pas en cause ; les
paquets marqués sont routés sur la bonne interface. La suite ce soir.
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
J'ai eu le temps de faire un petit test vite fait juste pour tester le marquage+routage du noyau 2.4.29. A priori il n'est pas en cause ; les paquets marqués sont routés sur la bonne interface. La suite ce soir.
-- Adresse attrape-spam :
JKB
Le 21-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Re,
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
J'ai eu le temps de faire un petit test vite fait juste pour tester le marquage+routage du noyau 2.4.29. A priori il n'est pas en cause ; les paquets marqués sont routés sur la bonne interface. La suite ce soir.
Bon, moi aussi, j'avance ;-)
J'ai réussi à compiler un 2.6.10 (et à booter, ce qui n'est pas une mince affaire) sur mon UltraSPARC. Même motif, même punition. Par contre, un coup de patch-o-matic avec ipt_ROUTE et la règle :
résout mon problème. Je penche donc pour un bug spécifique à l'architecture Sparc64 du style int/long, petit ou grand boutiste. Je n'ai pas de PC sous la main pour tester le truc, dommage...
Merci à tous ceux qui m'ont aidé.
Cordialement,
JKB
Le 21-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
Re,
Pour mon problème, je suis en train de me demander si ce n'est pas
un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je
referai la manip grandeur nature ce soir avec lui si d'ici là ton
problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
J'ai eu le temps de faire un petit test vite fait juste pour tester le
marquage+routage du noyau 2.4.29. A priori il n'est pas en cause ; les
paquets marqués sont routés sur la bonne interface. La suite ce soir.
Bon, moi aussi, j'avance ;-)
J'ai réussi à compiler un 2.6.10 (et à booter, ce qui n'est pas une
mince affaire) sur mon UltraSPARC. Même motif, même punition. Par
contre, un coup de patch-o-matic avec ipt_ROUTE et la règle :
résout mon problème. Je penche donc pour un bug spécifique à
l'architecture Sparc64 du style int/long, petit ou grand boutiste.
Je n'ai pas de PC sous la main pour tester le truc, dommage...
Le 21-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Re,
Pour mon problème, je suis en train de me demander si ce n'est pas un bug du noyau 2.4.29.
J'ai reconstruit un noyau 2.4.29 sans le patch MARK-operations. Je referai la manip grandeur nature ce soir avec lui si d'ici là ton problème n'est pas résolu ou cette hypothèse infirmée/confirmée.
J'ai eu le temps de faire un petit test vite fait juste pour tester le marquage+routage du noyau 2.4.29. A priori il n'est pas en cause ; les paquets marqués sont routés sur la bonne interface. La suite ce soir.
Bon, moi aussi, j'avance ;-)
J'ai réussi à compiler un 2.6.10 (et à booter, ce qui n'est pas une mince affaire) sur mon UltraSPARC. Même motif, même punition. Par contre, un coup de patch-o-matic avec ipt_ROUTE et la règle :
résout mon problème. Je penche donc pour un bug spécifique à l'architecture Sparc64 du style int/long, petit ou grand boutiste. Je n'ai pas de PC sous la main pour tester le truc, dommage...
