Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :SI j'ai bien compris, les paquets provenant des ports 3000 et 3001
sont marqués par la table mangle et sont censés suivre la table
intranet, non ?
Oui.Où est le problème ?
Je ne sais pas. À priori, pas de vos règles iptables et iproute2.
Dans le message <news:slrnd195rc.t07.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
SI j'ai bien compris, les paquets provenant des ports 3000 et 3001
sont marqués par la table mangle et sont censés suivre la table
intranet, non ?
Oui.
Où est le problème ?
Je ne sais pas. À priori, pas de vos règles iptables et iproute2.
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :SI j'ai bien compris, les paquets provenant des ports 3000 et 3001
sont marqués par la table mangle et sont censés suivre la table
intranet, non ?
Oui.Où est le problème ?
Je ne sais pas. À priori, pas de vos règles iptables et iproute2.
écrivait :je peux écrire l'expression consacrée : chez moi ça marche (c).
Je n'ai pas tout mis en place comme dans ton installation, juste la
passerelle et une machine jouant le rôle de ton serveur, et rien sur les
interfaces vers les routeurs (finalement j'aurais pu faire avec une
seule carte réseau et deux interfaces dummy). La correspondance qui sert
à reconnaître les paquets à marquer est différente (sur adresse
destination pour faire simple) et il n'y avait pas de NAT mais je ne
pense pas que ça ait d'influence. J'ai bien réussi à faire en sorte que
des paquets émis par le serveur et marqués sortent par une interface
alors que la route normale passait par l'autre interface.
Et avec le NAT ? Puis-je avoir votre configuration iproute ?
Surtout l'équivalent de mon ip route list table intranet.
Pascal@plouf écrivait :
je peux écrire l'expression consacrée : chez moi ça marche (c).
Je n'ai pas tout mis en place comme dans ton installation, juste la
passerelle et une machine jouant le rôle de ton serveur, et rien sur les
interfaces vers les routeurs (finalement j'aurais pu faire avec une
seule carte réseau et deux interfaces dummy). La correspondance qui sert
à reconnaître les paquets à marquer est différente (sur adresse
destination pour faire simple) et il n'y avait pas de NAT mais je ne
pense pas que ça ait d'influence. J'ai bien réussi à faire en sorte que
des paquets émis par le serveur et marqués sortent par une interface
alors que la route normale passait par l'autre interface.
Et avec le NAT ? Puis-je avoir votre configuration iproute ?
Surtout l'équivalent de mon ip route list table intranet.
écrivait :je peux écrire l'expression consacrée : chez moi ça marche (c).
Je n'ai pas tout mis en place comme dans ton installation, juste la
passerelle et une machine jouant le rôle de ton serveur, et rien sur les
interfaces vers les routeurs (finalement j'aurais pu faire avec une
seule carte réseau et deux interfaces dummy). La correspondance qui sert
à reconnaître les paquets à marquer est différente (sur adresse
destination pour faire simple) et il n'y avait pas de NAT mais je ne
pense pas que ça ait d'influence. J'ai bien réussi à faire en sorte que
des paquets émis par le serveur et marqués sortent par une interface
alors que la route normale passait par l'autre interface.
Et avec le NAT ? Puis-je avoir votre configuration iproute ?
Surtout l'équivalent de mon ip route list table intranet.
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :écrivait :je peux écrire l'expression consacrée : chez moi ça marche (c).
Chez moi aussi et depuis fort bien longtemps.
Dans le message <news:slrnd1b6qa.3mh.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
Pascal@plouf écrivait :
je peux écrire l'expression consacrée : chez moi ça marche (c).
Chez moi aussi et depuis fort bien longtemps.
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :écrivait :je peux écrire l'expression consacrée : chez moi ça marche (c).
Chez moi aussi et depuis fort bien longtemps.
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :
écrivait :je peux écrire l'expression consacrée : chez moi ça marche (c).
Chez moi aussi et depuis fort bien longtemps.Je n'ai pas tout mis en place comme dans ton installation, juste la
passerelle et une machine jouant le rôle de ton serveur, et rien sur les
interfaces vers les routeurs (finalement j'aurais pu faire avec une
seule carte réseau et deux interfaces dummy). La correspondance qui sert
à reconnaître les paquets à marquer est différente (sur adresse
destination pour faire simple) et il n'y avait pas de NAT mais je ne
pense pas que ça ait d'influence. J'ai bien réussi à faire en sorte que
des paquets émis par le serveur et marqués sortent par une interface
alors que la route normale passait par l'autre interface.
Et avec le NAT ? Puis-je avoir votre configuration iproute ?
Surtout l'équivalent de mon ip route list table intranet.
Sur le principe, j'ai le même type de configuration que la votre (plusieurs
liens Internet, différents services derrière un lan devant être accédé que
par l'une ou par l'autre des connexions Internet, etc), mais le nombre de
règles iproute2, la diversité de ses règles iproute2 et le nombres de règles
iptables font que donner ma configuration n'aiderait pas à la compréhension
et serait un mauvais modèle.
C'est pour quoi j'ai monté comme l'a fait Pascal une petite machine pour
simuler quelque chose de beaucoup plus proche à votre configuration, à ceci
près que les interfaces ne sont pas toutes en Ethernet mais en PPP.
Soit la machine herbizarre avec la configuration réseau suivante :
herbizarre root # ip -4 addr show
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet 192.168.151.2/23 brd 192.168.151.255 scope global eth0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1200 qdisc pfifo_fast qlen 3
inet 192.168.254.1 peer 192.168.254.254/32 scope global ppp0
6: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1200 qdisc pfifo_fast qlen 3
inet 192.168.126.1 peer 192.168.126.254/32 scope global ppp1
herbizarre root # ip -4 route show table all
default via 192.168.126.254 dev ppp1 table web
192.168.126.0/24 dev ppp1 scope link
192.168.254.0/24 dev ppp0 scope link
192.168.150.0/23 dev eth0 proto kernel scope link src 192.168.151.2
default via 192.168.150.1 dev eth0
[snip broadcast and co]
herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
eth0 est l'interface du lien Internet principal, l'équivalent de votre
interface eth0.
ppp0 est l'interface où est accessible un serveur web (192.168.254.3),
l'équivalent de votre interface eth1.
ppp1 est l'interface d'un autre lien Internet par lequel doit être accéder
le serveur web 192.168.254.3 se trouvant derrière l'interface ppp0, bref
l'équivalent de votre interface eth2.
Les règles iptables :
iptables -t nat -A PREROUTING -p tcp -d 192.168.126.1 --dport 80
-j DNAT --to-destination 192.168.254.3
iptables -t mangle -A PREROUTING -p tcp -s 192.168.254.3 --sport 80
-j MARK --set-mark 0x1
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
Comme vous pouvez le voir, depuis une machine extérieure qui attaque
l'interface ppp1 sur son port 80 j'accède bien au serveur web se trouvant
derrière l'interface ppp0 alors que la route de sortie par défaut est se
fait sur eth0.
Si on supprime la règle iproute2 qui redirige les paquets marqués sur la
bonne table de routage, on observe alors que les paquets sortent bien sur
l'interface eth0, celle de la route par défaut :
http://magnolia.tichou.org/~tichou/JKB-sansmark
La machine tourne sur un vieux noyaux 2.4.20 sauce Gentoo (pas à jour du
tout... ;p), la version de iproute2 est la 2.6.10.20050112 (comme Pascal je
m'étonnais de la valeur des mark affichés contrairement à la votre mais cela
fonctionnait aussi très bien avec la version 20010824) et la version de
iptables est là 1.2.9.
Voilà, j'espère que le détail de la configuration et de ma démonstration
pourra vous aider ou vous mettre sur la bonne piste. À mon avis ça se situe
au niveau du cache de routage comme la fait remarquer Pascal ou des
paramètres du noyaux.
Dans le message <news:slrnd1b6qa.3mh.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
Pascal@plouf écrivait :
je peux écrire l'expression consacrée : chez moi ça marche (c).
Chez moi aussi et depuis fort bien longtemps.
Je n'ai pas tout mis en place comme dans ton installation, juste la
passerelle et une machine jouant le rôle de ton serveur, et rien sur les
interfaces vers les routeurs (finalement j'aurais pu faire avec une
seule carte réseau et deux interfaces dummy). La correspondance qui sert
à reconnaître les paquets à marquer est différente (sur adresse
destination pour faire simple) et il n'y avait pas de NAT mais je ne
pense pas que ça ait d'influence. J'ai bien réussi à faire en sorte que
des paquets émis par le serveur et marqués sortent par une interface
alors que la route normale passait par l'autre interface.
Et avec le NAT ? Puis-je avoir votre configuration iproute ?
Surtout l'équivalent de mon ip route list table intranet.
Sur le principe, j'ai le même type de configuration que la votre (plusieurs
liens Internet, différents services derrière un lan devant être accédé que
par l'une ou par l'autre des connexions Internet, etc), mais le nombre de
règles iproute2, la diversité de ses règles iproute2 et le nombres de règles
iptables font que donner ma configuration n'aiderait pas à la compréhension
et serait un mauvais modèle.
C'est pour quoi j'ai monté comme l'a fait Pascal une petite machine pour
simuler quelque chose de beaucoup plus proche à votre configuration, à ceci
près que les interfaces ne sont pas toutes en Ethernet mais en PPP.
Soit la machine herbizarre avec la configuration réseau suivante :
herbizarre root # ip -4 addr show
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet 192.168.151.2/23 brd 192.168.151.255 scope global eth0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1200 qdisc pfifo_fast qlen 3
inet 192.168.254.1 peer 192.168.254.254/32 scope global ppp0
6: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1200 qdisc pfifo_fast qlen 3
inet 192.168.126.1 peer 192.168.126.254/32 scope global ppp1
herbizarre root # ip -4 route show table all
default via 192.168.126.254 dev ppp1 table web
192.168.126.0/24 dev ppp1 scope link
192.168.254.0/24 dev ppp0 scope link
192.168.150.0/23 dev eth0 proto kernel scope link src 192.168.151.2
default via 192.168.150.1 dev eth0
[snip broadcast and co]
herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
eth0 est l'interface du lien Internet principal, l'équivalent de votre
interface eth0.
ppp0 est l'interface où est accessible un serveur web (192.168.254.3),
l'équivalent de votre interface eth1.
ppp1 est l'interface d'un autre lien Internet par lequel doit être accéder
le serveur web 192.168.254.3 se trouvant derrière l'interface ppp0, bref
l'équivalent de votre interface eth2.
Les règles iptables :
iptables -t nat -A PREROUTING -p tcp -d 192.168.126.1 --dport 80
-j DNAT --to-destination 192.168.254.3
iptables -t mangle -A PREROUTING -p tcp -s 192.168.254.3 --sport 80
-j MARK --set-mark 0x1
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
Comme vous pouvez le voir, depuis une machine extérieure qui attaque
l'interface ppp1 sur son port 80 j'accède bien au serveur web se trouvant
derrière l'interface ppp0 alors que la route de sortie par défaut est se
fait sur eth0.
Si on supprime la règle iproute2 qui redirige les paquets marqués sur la
bonne table de routage, on observe alors que les paquets sortent bien sur
l'interface eth0, celle de la route par défaut :
http://magnolia.tichou.org/~tichou/JKB-sansmark
La machine tourne sur un vieux noyaux 2.4.20 sauce Gentoo (pas à jour du
tout... ;p), la version de iproute2 est la 2.6.10.20050112 (comme Pascal je
m'étonnais de la valeur des mark affichés contrairement à la votre mais cela
fonctionnait aussi très bien avec la version 20010824) et la version de
iptables est là 1.2.9.
Voilà, j'espère que le détail de la configuration et de ma démonstration
pourra vous aider ou vous mettre sur la bonne piste. À mon avis ça se situe
au niveau du cache de routage comme la fait remarquer Pascal ou des
paramètres du noyaux.
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :
écrivait :je peux écrire l'expression consacrée : chez moi ça marche (c).
Chez moi aussi et depuis fort bien longtemps.Je n'ai pas tout mis en place comme dans ton installation, juste la
passerelle et une machine jouant le rôle de ton serveur, et rien sur les
interfaces vers les routeurs (finalement j'aurais pu faire avec une
seule carte réseau et deux interfaces dummy). La correspondance qui sert
à reconnaître les paquets à marquer est différente (sur adresse
destination pour faire simple) et il n'y avait pas de NAT mais je ne
pense pas que ça ait d'influence. J'ai bien réussi à faire en sorte que
des paquets émis par le serveur et marqués sortent par une interface
alors que la route normale passait par l'autre interface.
Et avec le NAT ? Puis-je avoir votre configuration iproute ?
Surtout l'équivalent de mon ip route list table intranet.
Sur le principe, j'ai le même type de configuration que la votre (plusieurs
liens Internet, différents services derrière un lan devant être accédé que
par l'une ou par l'autre des connexions Internet, etc), mais le nombre de
règles iproute2, la diversité de ses règles iproute2 et le nombres de règles
iptables font que donner ma configuration n'aiderait pas à la compréhension
et serait un mauvais modèle.
C'est pour quoi j'ai monté comme l'a fait Pascal une petite machine pour
simuler quelque chose de beaucoup plus proche à votre configuration, à ceci
près que les interfaces ne sont pas toutes en Ethernet mais en PPP.
Soit la machine herbizarre avec la configuration réseau suivante :
herbizarre root # ip -4 addr show
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet 192.168.151.2/23 brd 192.168.151.255 scope global eth0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1200 qdisc pfifo_fast qlen 3
inet 192.168.254.1 peer 192.168.254.254/32 scope global ppp0
6: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1200 qdisc pfifo_fast qlen 3
inet 192.168.126.1 peer 192.168.126.254/32 scope global ppp1
herbizarre root # ip -4 route show table all
default via 192.168.126.254 dev ppp1 table web
192.168.126.0/24 dev ppp1 scope link
192.168.254.0/24 dev ppp0 scope link
192.168.150.0/23 dev eth0 proto kernel scope link src 192.168.151.2
default via 192.168.150.1 dev eth0
[snip broadcast and co]
herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
eth0 est l'interface du lien Internet principal, l'équivalent de votre
interface eth0.
ppp0 est l'interface où est accessible un serveur web (192.168.254.3),
l'équivalent de votre interface eth1.
ppp1 est l'interface d'un autre lien Internet par lequel doit être accéder
le serveur web 192.168.254.3 se trouvant derrière l'interface ppp0, bref
l'équivalent de votre interface eth2.
Les règles iptables :
iptables -t nat -A PREROUTING -p tcp -d 192.168.126.1 --dport 80
-j DNAT --to-destination 192.168.254.3
iptables -t mangle -A PREROUTING -p tcp -s 192.168.254.3 --sport 80
-j MARK --set-mark 0x1
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
Comme vous pouvez le voir, depuis une machine extérieure qui attaque
l'interface ppp1 sur son port 80 j'accède bien au serveur web se trouvant
derrière l'interface ppp0 alors que la route de sortie par défaut est se
fait sur eth0.
Si on supprime la règle iproute2 qui redirige les paquets marqués sur la
bonne table de routage, on observe alors que les paquets sortent bien sur
l'interface eth0, celle de la route par défaut :
http://magnolia.tichou.org/~tichou/JKB-sansmark
La machine tourne sur un vieux noyaux 2.4.20 sauce Gentoo (pas à jour du
tout... ;p), la version de iproute2 est la 2.6.10.20050112 (comme Pascal je
m'étonnais de la valeur des mark affichés contrairement à la votre mais cela
fonctionnait aussi très bien avec la version 20010824) et la version de
iptables est là 1.2.9.
Voilà, j'espère que le détail de la configuration et de ma démonstration
pourra vous aider ou vous mettre sur la bonne piste. À mon avis ça se situe
au niveau du cache de routage comme la fait remarquer Pascal ou des
paramètres du noyaux.
Le 18-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 :
Bonjour,
Quelques remarques...
Le 18-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :
Dans le message <news:slrnd1b6qa.3mh.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
Bonjour,
Quelques remarques...
Le 18-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 :
Bonjour,
Quelques remarques...
Le 20-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
JKB écrivait dans fr.comp.os.linux.configuration :Le 18-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 :
Bonjour,
Quelques remarques...
Et quelques retours ;-)
Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT > MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué, puis relayé et hop, ressort par
eth0.
Feb 20 11:25:57 kant kernel: Forward : IN=eth1 OUT=eth0
SRC2.168.0.130 DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLc
ID=0 DF PROTO=TCP SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Pourtant, j'ai bien maintenant :
Root kant:[~] > ip rule list
0: from all lookup local
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:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2
Root kant:[~] >
J'ai essayé de rajouter :
ip route add table intranet 192.168.1.0/24 dev eth2 proto kernel scope
link src 192.168.1.1
mais le résultat est le même ! Et au passage, j'ai rebooté la machine
pour être sûr de vider le cache. Pourquoi est-ce que @#^{[@{^[
d'iproute ignore superbement ma table intranet ?
Le 20-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
JKB écrivait dans fr.comp.os.linux.configuration :
Le 18-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :
Dans le message <news:slrnd1b6qa.3mh.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
Bonjour,
Quelques remarques...
Et quelques retours ;-)
Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT > MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué, puis relayé et hop, ressort par
eth0.
Feb 20 11:25:57 kant kernel: Forward : IN=eth1 OUT=eth0
SRC2.168.0.130 DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLc
ID=0 DF PROTO=TCP SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Pourtant, j'ai bien maintenant :
Root kant:[~] > ip rule list
0: from all lookup local
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:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2
Root kant:[~] >
J'ai essayé de rajouter :
ip route add table intranet 192.168.1.0/24 dev eth2 proto kernel scope
link src 192.168.1.1
mais le résultat est le même ! Et au passage, j'ai rebooté la machine
pour être sûr de vider le cache. Pourquoi est-ce que @#^{[@{^[
d'iproute ignore superbement ma table intranet ?
Le 20-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
JKB écrivait dans fr.comp.os.linux.configuration :Le 18-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 :
Bonjour,
Quelques remarques...
Et quelques retours ;-)
Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT > MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué, puis relayé et hop, ressort par
eth0.
Feb 20 11:25:57 kant kernel: Forward : IN=eth1 OUT=eth0
SRC2.168.0.130 DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLc
ID=0 DF PROTO=TCP SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Pourtant, j'ai bien maintenant :
Root kant:[~] > ip rule list
0: from all lookup local
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:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2
Root kant:[~] >
J'ai essayé de rajouter :
ip route add table intranet 192.168.1.0/24 dev eth2 proto kernel scope
link src 192.168.1.1
mais le résultat est le même ! Et au passage, j'ai rebooté la machine
pour être sûr de vider le cache. Pourquoi est-ce que @#^{[@{^[
d'iproute ignore superbement ma table intranet ?
herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > ip rule show
0: from all lookup local
32764: from all fwmark 0x1 lookup intranet
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Le problème ne viendrait-il pas d'ici ? Inversion des deux règles
fwmark et lookup intranet ?
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 ?
herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > ip rule show
0: from all lookup local
32764: from all fwmark 0x1 lookup intranet
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Le problème ne viendrait-il pas d'ici ? Inversion des deux règles
fwmark et lookup intranet ?
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 ?
herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > ip rule show
0: from all lookup local
32764: from all fwmark 0x1 lookup intranet
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Le problème ne viendrait-il pas d'ici ? Inversion des deux règles
fwmark et lookup intranet ?
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 ?
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > ip rule show
0: from all lookup local
32764: from all fwmark 0x1 lookup intranet
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Le problème ne viendrait-il pas d'ici ? Inversion des deux règles
fwmark et lookup intranet ?
L'ordre des règles concernant la table intranet n'a ici aucune importance
ainsi que leurs numéros de priotités.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.
Dans le message <news:slrnd1gm55.ea0.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > ip rule show
0: from all lookup local
32764: from all fwmark 0x1 lookup intranet
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Le problème ne viendrait-il pas d'ici ? Inversion des deux règles
fwmark et lookup intranet ?
L'ordre des règles concernant la table intranet n'a ici aucune importance
ainsi que leurs numéros de priotités.
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.
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :herbizarre root # ip rule show
0: from all lookup local
100: from 192.168.126.1 lookup web
101: from all fwmark 0x1 lookup web
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > ip rule show
0: from all lookup local
32764: from all fwmark 0x1 lookup intranet
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Le problème ne viendrait-il pas d'ici ? Inversion des deux règles
fwmark et lookup intranet ?
L'ordre des règles concernant la table intranet n'a ici aucune importance
ainsi que leurs numéros de priotités.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 loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT > MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué,
Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT > MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué,
Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT > MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué,
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT >> MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué,
Qu'est ce qui vous permet d'affirmer que le paquet est bien marqué ? Car
finallement rien ne nous permet de l'affirmer et c'est bien une lacune du
noyau Linux.
Dans le message <news:slrnd1gpsf.ea0.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :
Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT >> MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué,
Qu'est ce qui vous permet d'affirmer que le paquet est bien marqué ? Car
finallement rien ne nous permet de l'affirmer et c'est bien une lacune du
noyau Linux.
Dans le message <news:,
*JKB* tapota sur f.c.o.l.configuration :Je loggue la chaîne forward de la table main et la chaîne prerouting
de mangle :
rayleigh:[~] > telnet monserveur 3000
Feb 20 11:25:57 kant kernel: Forward : IN=eth2 OUT=eth1
SRC!3.41.173.141 DST2.168.0.130 LEN` TOS=0x10 PREC=0x00 TTLX
IDX903 DF PROTO=TCP SPTC452 DPT000 WINDOWX40 RES=0x00 SYN URGP=0
La propagation se fait donc bien sur le bon port du bon serveur qui
répond :
Feb 20 11:25:57 kant kernel: Mangle : IN=eth1 OUT >> MAC:00:20:c0:ff:ee:00:11:11:10:93:05:08:00 SRC2.168.0.130
DST!3.41.173.141 LEN` TOS=0x00 PREC=0x00 TTLd ID=0 DF PROTO=TCP
SPT000 DPTC452 WINDOWW92 RES=0x00 ACK SYN URGP=0
Le paquet est donc bine marqué,
Qu'est ce qui vous permet d'affirmer que le paquet est bien marqué ? Car
finallement rien ne nous permet de l'affirmer et c'est bien une lacune du
noyau Linux.
