Problème de routage (iproute2 + iptables)

Dans le message <news:slrnd16m5j.m0d.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

Bonjour à tous,

Bonjour,

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.

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.

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

Ici vous dites que tous les paquets marqués 0xbb8 et 0xbb9, venant de
n'importe où, doivent utiliser la table de routage nommée intranet.

Root kant:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2

Dans la table de routage intranet, il n'y a qu'une seule route, une route
par défaut et qui dit que tous les paquets traversant cette table devront
être routés vers la passerelle 192.168.1.254 en passant par l'interface
eth2.

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Ici, on accepte *tout* dès le départ. Les règles suivantes de la chaîne
INPUT ne seront donc jamais traversées. J'imagine que cette règle a peut
être été introduite entre-temps pour faciliter le débuggage de votre
problème.

ACCEPT all -- anywhere kant.astelys.fr

Nous avons ici en adresse de destination un nom d'hôte, mais quelle est
l'adresse IP qui lui est associé sur votre machine ? L'adresse publique ou
l'adresse privée ?
S'il s'agit de l'adresse publique, il y a comme un soucis puisque votre
machine n'a, comme adresses de destination, que des adresses privées
(192.168.1.1, 192.168.254.1 et 192.168.0.128). Donc dans vos règles
iptables, les adresses de destination doivent correspondre exactement aux
adresses de vos interfaces.

La prochaine fois, pensez à ajouter l'option '-n' d'iptables pour avoir la
valeur numérique des adresses et des ports.

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

Si j'ai bien compris, le trafic à destination des ports 3000 et 3001 doit
être forwardé sur une autre machine et n'est pas à destination de votre
machine. Donc les deux dernières règles ne sont pas dans la bonne chaîne,
elles devraient être placées dans la chaîne FORWARD. En tout cas en restant
dans cette chaîne INPUT, elles n'auront *aucun* effet sur les connexions
forwardées.

Root kant:[~] > iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere kant.astelys.fr tcp
dpt:8000 to:192.168.0.130:8080
DNAT tcp -- anywhere thibon.astelys.fr tcp
dpt:3000 to:192.168.0.130:3000
DNAT tcp -- anywhere thibon.astelys.fr tcp
dpt:3001 to:192.168.0.130:3001

Ici, même remarque sur la destination que précédemment. Est-ce que le nom
d'hôte a pour adresse IP 192.168.1.1 ? Si non, alors les paquets venant de
l'interface eth2 et à destination des ports 3000 et 3001 ne seront jamais
natés.

Root kant:[~] > iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp -- anywhere anywhere tcp
dpt:3000 MARK set 0xbb8
MARK tcp -- anywhere anywhere tcp
dpt:3001 MARK set 0xbb9

Ici vous demandez à ce que tous les paquets à destination des ports 3000 et
3001 soient marqués. Comme on a vu précédemment, ces paquets marqués doivent
utiliser la table de routage intranet. Donc tous les paquets à destination
des ports 3000 et 3001 venant de n'importe où (eth2, mais aussi eth0 et
eth1) doivent sortir sur l'interface eth2 et router vers la passerelle
192.168.1.254.
Conclusion, les paquets à destination des ports 3000 et 3001 et venant de
l'interface eth2 ressortiront par cette même interface.

Une remarque générale sur vos règles iptables : il n'y figure jamais les
interfaces d'entrée et de sortie, car vous n'avez pas ajouté l'option '-v' à
la commande 'iptables -L'. Il se cache alors peut être des erreurs dans vos
règles iptables que nous ne pouvons voir ici.
D'une manière générale, je recommande toujours d'utiliser la commande
'iptabes-save' pour lister l'ensemble de ces règles.

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...

À quoi le voyez vous ?

Une idée ?

Oui, supprimer vos règles iproute2 et iptables concernant le marquage des
paquets, c'est-à-dire les règles suivantes :

32763: from all fwmark 0xbb9 lookup intranet
32764: from all fwmark 0xbb8 lookup intranet

et

MARK tcp -- anywhere anywhere tcp dpt:3000
MARK set 0xbb8
MARK tcp -- anywhere anywhere tcp dpt:3001
MARK set 0xbb9

Elles sont inutiles dans ce que vous souhaitez faire et de plus, comme nous
avons pu le voir, font le contraire de ce que vous souhaitez puisqu'elles ne
permettent pas de forwarder vers l'interface eth1 les paquets venant de
l'interface eth2 à destination des ports 3000 et 3001.
Il n'y a pas besoin de règle particulière pour dire où doivent être forwardé
ces paquets venant de eth2. La table de routage principale suffit pour que
les paquets, une fois l'adresse de destination natée, puisse emprunter le
bon chemin, c'est-à-dire sortir sur l'interface eth1.

Par contre, les paquets retours venant de eth1, qui une fois seront «
dénatés » et qui auront donc comme adresse source 192.168.1.1, devront
savoir sur quelle passerelle et quelle interface sortir. Par défaut, nous
avons vu que c'est par l'interface eth0, alors qu'il faudrait, en principe,
qu'ils ressortent par là d'où ils venaient, donc par eth2.
C'est pourquoi que votre règle iproute2 suivante :

32765: from 192.168.1.1 lookup intranet

est à conserver et suffit pour router les paquets sur eth2 puisque la table
de routage intranet indique que les paquets doivent passer par eth2.

Il faudrait aussi s'assurer que le forwarding est activé sur chacune des
interfaces concernées en allant vérifier les entrées suivantes :

/proc/sys/net/ipv4/ip_forward

/proc/sys/net/ipv4/conf/{all,default,eth0,eth1,eth2}/forwarding

et, avant tous tests finaux, faire en sorte que la table des suivis des
connexions (/proc/net/ip_conntrack) soit vide ou du moins ne contienne pas
d'entrée sur des connexions vers les ports 3000 et 3001 pouvant venir de
connexions précédentes. En effet, si les règles de nat ont changé entre
temps, la table ip_conntrack peut avoir conservé des entrées avec les
précédentes règles, empêchant alors aux paquets retours d'être « dénatés »
comme il faut. Malheureusement, pour vider cette table il n'existe pas de
solution fiable. Soit attendre, parfois indéfiniment si la machine reste
connectée, ou soit rebooter... (le déchargement du module ip_conntrack
pouvant bloquer le système).

--
TiChou

Le 16-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :

Dans le message <news:slrnd16m5j.m0d.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

Bonjour à tous,

Bonjour,

Bonjour, et merci de vous intéresser à mon problème...

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.

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.

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

Ici vous dites que tous les paquets marqués 0xbb8 et 0xbb9, venant de
n'importe où, doivent utiliser la table de routage nommée intranet.

Exact.

Root kant:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2

Dans la table de routage intranet, il n'y a qu'une seule route, une route
par défaut et qui dit que tous les paquets traversant cette table devront
être routés vers la passerelle 192.168.1.254 en passant par l'interface
eth2.

Exact.

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Ici, on accepte *tout* dès le départ. Les règles suivantes de la chaîne
INPUT ne seront donc jamais traversées. J'imagine que cette règle a peut
être été introduite entre-temps pour faciliter le débuggage de votre
problème.

En fait, on le le voit pas ici, mais il s'agit d'une règle sur le
loopback.

ACCEPT all -- anywhere kant.astelys.fr

Nous avons ici en adresse de destination un nom d'hôte, mais quelle est
l'adresse IP qui lui est associé sur votre machine ? L'adresse publique ou
l'adresse privée ?

Toutes les adresses sont privées. J'ai deux routeurs qui eux
possèdent deux adresses publiques et qui font du NAT.

S'il s'agit de l'adresse publique, il y a comme un soucis puisque votre
machine n'a, comme adresses de destination, que des adresses privées
(192.168.1.1, 192.168.254.1 et 192.168.0.128). Donc dans vos règles
iptables, les adresses de destination doivent correspondre exactement aux
adresses de vos interfaces.

Ce sont bien les adresses des interfaces.

La prochaine fois, pensez à ajouter l'option '-n' d'iptables pour avoir la
valeur numérique des adresses et des ports.

Root kant:[~] > iptables -L -nv
Chain INPUT (policy DROP 975 packets, 124K bytes)
pkts bytes target prot opt in out source
destination
1993 436K ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
21968 2612K ACCEPT all -- * * 0.0.0.0/0
192.168.254.1
379 66389 ACCEPT all -- * * 0.0.0.0/0
192.168.0.128
786 55233 ACCEPT tcp -- * * 0.0.0.0/0
192.168.1.1 tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.1.1 tcp dpt:3000
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.1.1 tcp dpt:3001

Chain FORWARD (policy ACCEPT 147K packets, 15M bytes)
pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 31381 packets, 27M bytes)
pkts bytes target prot opt in out source
destination
Root kant:[~] >

Voilà qui est fait ;-)

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

Si j'ai bien compris, le trafic à destination des ports 3000 et 3001 doit
être forwardé sur une autre machine et n'est pas à destination de votre
machine. Donc les deux dernières règles ne sont pas dans la bonne chaîne,
elles devraient être placées dans la chaîne FORWARD. En tout cas en restant
dans cette chaîne INPUT, elles n'auront *aucun* effet sur les connexions
forwardées.

Nous sommes bien d'accord. J'avais mis ces deux règles pour tester
un ssh sur le port 3000/tcp.

Root kant:[~] > iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere kant.astelys.fr tcp
dpt:8000 to:192.168.0.130:8080
DNAT tcp -- anywhere thibon.astelys.fr tcp
dpt:3000 to:192.168.0.130:3000
DNAT tcp -- anywhere thibon.astelys.fr tcp
dpt:3001 to:192.168.0.130:3001

Ici, même remarque sur la destination que précédemment. Est-ce que le nom
d'hôte a pour adresse IP 192.168.1.1 ? Si non, alors les paquets venant de
l'interface eth2 et à destination des ports 3000 et 3001 ne seront jamais
natés.

Root kant:[~] > iptables -L -t nat -nv
Chain PREROUTING (policy ACCEPT 73056 packets, 3806K bytes)
pkts bytes target prot opt in out source
destination

0 0 DNAT tcp -- * * 0.0.0.0/0
192.168.254.
1 tcp dpt:8000 to:192.168.0.130:8080
25 1500 DNAT tcp -- * * 0.0.0.0/0
192.168.1.1
tcp dpt:3000 to:192.168.0.130:3000
0 0 DNAT tcp -- * * 0.0.0.0/0
192.168.1.1
tcp dpt:3001 to:192.168.0.130:3001
0 0 DNAT tcp -- * * 0.0.0.0/0
192.168.254.
1 tcp dpt:3000 to:192.168.0.130:3000
0 0 DNAT tcp -- * * 0.0.0.0/0
192.168.254.
1 tcp dpt:3001 to:192.168.0.130:3001

Chain POSTROUTING (policy ACCEPT 342 packets, 43258 bytes)
pkts bytes target prot opt in out source
destination

69657 3344K MASQUERADE all -- * eth0 192.168.0.0/24
0.0.0.0/0

247 12084 MASQUERADE all -- * eth2 192.168.0.0/24
0.0.0.0/0


Chain OUTPUT (policy ACCEPT 342 packets, 43258 bytes)
pkts bytes target prot opt in out source
destination

Root kant:[~] >

Root kant:[~] > iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp -- anywhere anywhere tcp
dpt:3000 MARK set 0xbb8
MARK tcp -- anywhere anywhere tcp
dpt:3001 MARK set 0xbb9

Ici vous demandez à ce que tous les paquets à destination des ports 3000 et
3001 soient marqués. Comme on a vu précédemment, ces paquets marqués doivent
utiliser la table de routage intranet. Donc tous les paquets à destination
des ports 3000 et 3001 venant de n'importe où (eth2, mais aussi eth0 et
eth1) doivent sortir sur l'interface eth2 et router vers la passerelle
192.168.1.254.
Conclusion, les paquets à destination des ports 3000 et 3001 et venant de
l'interface eth2 ressortiront par cette même interface.

Une remarque générale sur vos règles iptables : il n'y figure jamais les
interfaces d'entrée et de sortie, car vous n'avez pas ajouté l'option '-v' à
la commande 'iptables -L'. Il se cache alors peut être des erreurs dans vos
règles iptables que nous ne pouvons voir ici.
D'une manière générale, je recommande toujours d'utiliser la commande
'iptabes-save' pour lister l'ensemble de ces règles.

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...

À quoi le voyez vous ?

tcpdump

Une idée ?

Oui, supprimer vos règles iproute2 et iptables concernant le marquage des
paquets, c'est-à-dire les règles suivantes :

32763: from all fwmark 0xbb9 lookup intranet
32764: from all fwmark 0xbb8 lookup intranet

et

MARK tcp -- anywhere anywhere tcp dpt:3000
MARK set 0xbb8
MARK tcp -- anywhere anywhere tcp dpt:3001
MARK set 0xbb9

Elles sont inutiles dans ce que vous souhaitez faire et de plus, comme nous
avons pu le voir, font le contraire de ce que vous souhaitez puisqu'elles ne
permettent pas de forwarder vers l'interface eth1 les paquets venant de
l'interface eth2 à destination des ports 3000 et 3001.
Il n'y a pas besoin de règle particulière pour dire où doivent être forwardé
ces paquets venant de eth2. La table de routage principale suffit pour que
les paquets, une fois l'adresse de destination natée, puisse emprunter le
bon chemin, c'est-à-dire sortir sur l'interface eth1.

Par contre, les paquets retours venant de eth1, qui une fois seront «
dénatés » et qui auront donc comme adresse source 192.168.1.1, devront
savoir sur quelle passerelle et quelle interface sortir. Par défaut, nous
avons vu que c'est par l'interface eth0, alors qu'il faudrait, en principe,
qu'ils ressortent par là d'où ils venaient, donc par eth2.
C'est pourquoi que votre règle iproute2 suivante :

32765: from 192.168.1.1 lookup intranet

est à conserver et suffit pour router les paquets sur eth2 puisque la table
de routage intranet indique que les paquets doivent passer par eth2.

Il faudrait aussi s'assurer que le forwarding est activé sur chacune des
interfaces concernées en allant vérifier les entrées suivantes :

/proc/sys/net/ipv4/ip_forward

/proc/sys/net/ipv4/conf/{all,default,eth0,eth1,eth2}/forwarding

Il est actif.

et, avant tous tests finaux, faire en sorte que la table des suivis des
connexions (/proc/net/ip_conntrack) soit vide ou du moins ne contienne pas
d'entrée sur des connexions vers les ports 3000 et 3001 pouvant venir de
connexions précédentes. En effet, si les règles de nat ont changé entre
temps, la table ip_conntrack peut avoir conservé des entrées avec les
précédentes règles, empêchant alors aux paquets retours d'être « dénatés »
comme il faut. Malheureusement, pour vider cette table il n'existe pas de
solution fiable. Soit attendre, parfois indéfiniment si la machine reste
connectée, ou soit rebooter... (le déchargement du module ip_conntrack
pouvant bloquer le système).

J'ai fait les modifications comme indiquées. Mais le résultat est le
même : un tcpdump -i eth2 me montre des paquets entrant sur le port
3000, mais rien sur l'interface eth1...

Root kant:[~] > ip rule list
0: from all lookup local
32765: from 192.168.1.1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Root kant:[~] > iptables -L -nv
Chain INPUT (policy DROP 107 packets, 17004 bytes)
pkts bytes target prot opt in out source
destination
252 26706 ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
4900 394K ACCEPT all -- * * 0.0.0.0/0
192.168.254.1
67 11954 ACCEPT all -- * * 0.0.0.0/0
192.168.0.128
970 72602 ACCEPT tcp -- * * 0.0.0.0/0
192.168.1.1 tcp dpt:22

Chain FORWARD (policy ACCEPT 1401 packets, 825K bytes)
pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 7700 packets, 8302K bytes)
pkts bytes target prot opt in out source
destination
Root kant:[~] > iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 347 packets, 36437 bytes)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- * * 0.0.0.0/0
192.168.254.1 tcp dpt:8000 to:192.168.0.130:8080
6 360 DNAT tcp -- * * 0.0.0.0/0
192.168.1.1 tcp dpt:3000 to:192.168.0.130:3000
6 360 DNAT tcp -- * * 0.0.0.0/0
192.168.1.1 tcp dpt:3001 to:192.168.0.130:3001
0 0 DNAT tcp -- * * 0.0.0.0/0
192.168.254.1 tcp dpt:3000 to:192.168.0.130:3000
0 0 DNAT tcp -- * * 0.0.0.0/0
192.168.254.1 tcp dpt:3001 to:192.168.0.130:3001

Chain POSTROUTING (policy ACCEPT 44 packets, 4753 bytes)
pkts bytes target prot opt in out source
destination
29 1822 MASQUERADE all -- * eth0 192.168.0.0/24
0.0.0.0/0
0 0 MASQUERADE all -- * eth2 192.168.0.0/24
0.0.0.0/0

Chain OUTPUT (policy ACCEPT 44 packets, 4753 bytes)
pkts bytes target prot opt in out source
destination
Root kant:[~] >

Cela s'éclaire tout doucement, mais ce n'est pas encore ça ;-)

Cordialement,

JKB

Dans le message <news:slrnd178ao.nbn.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

[...]

Puis-je vous demander de publier vos sorties de commandes dans un fichier ?
La coupure des lignes de nos clients Usenet ne facilite pas la lecture des
règles.

--
TiChou

Le 16-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :

Dans le message <news:slrnd178ao.nbn.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

[...]

Puis-je vous demander de publier vos sorties de commandes dans un fichier ?
La coupure des lignes de nos clients Usenet ne facilite pas la lecture des
règles.

Oui. Que vous faut-il ?

JKB

Dans le message <news:slrnd1796t.nbn.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

Que vous faut-il ?

Tout. :)

Ou plus exactement :

iptables-save -c
ip rule show
ip -4 route show table all

--
TiChou

Le 16-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :

Dans le message <news:slrnd1796t.nbn.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

Que vous faut-il ?

Tout. :)

Mais encore ;-)

Ou plus exactement :

iptables-save -c
ip rule show
ip -4 route show table all

http://www.systella.fr/~bertrand/fichier

JKB

Dans le message <news:slrnd178ao.nbn.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

Bonjour, et merci de vous intéresser à mon problème...

De rien.

En fait, on le le voit pas ici, mais il s'agit d'une règle sur le
loopback.

D'où, vous comprenez, l'importance de l'option '-v' qui peut nous conduire à
des confusions ou des erreurs.

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...

À quoi le voyez vous ?

tcpdump

Êtes vous sûr que les paquets « eth2:3000 » ne sont pas natés (adresse de
destination modifiée en 192.168.0.130) ?
Je pense, vu ce que je vais dire par la suite, que le problème ne se situe
pas au niveau des paquets venant de eth2 mais plutôt au niveau des paquets
retours venant de 192.168.0.130.
Un tcpdump sur la machine 192.168.0.130 ne trace aucun paquet pouvant venir
de l'interface eth2 ?

Par contre, les paquets retours venant de eth1, qui une fois seront «
dénatés » et qui auront donc comme adresse source 192.168.1.1, devront
savoir sur quelle passerelle et quelle interface sortir. Par défaut,
nous avons vu que c'est par l'interface eth0, alors qu'il faudrait, en
principe, qu'ils ressortent par là d'où ils venaient, donc par
eth2. C'est pourquoi que votre règle iproute2 suivante :

32765: from 192.168.1.1 lookup intranet

est à conserver et suffit pour router les paquets sur eth2 puisque la
table de routage intranet indique que les paquets doivent passer par
eth2.

Je me rends compte maintenant que j'ai parlé un peu trop vite et oublié un
détail important... Le processus de « dénatage » dont je parlais se fait
après la décision de routage. Donc les paquets retours seront déjà routés
sur la route par défaut, c'est-à-dire celle empruntant l'interface eth0, car
à ce moment là les paquets retours auront encore comme adresse source
l'adresse 192.168.0.130 et non pas 192.168.1.1. La règle de source routing
ne peut donc ici s'appliquer.
Il faut donc penser à une règle de routage qui puisse diriger les paquets
retours vers la bonne table de routage. Finalement, l'idée du marquage des
paquets peut s'avérer une bonne solution. Cela donnerait :

iptables -t mangle -A PREROUTING -p tcp --sport 3000:3001
-s 192.168.0.130 -j MARK --set-mark 1

ip rule add fwmark 0x01 table intranet

Une autre manière de faire, celle que j'utilise sur mes passerelles
multihoming, c'est d'attribuer aux machines du réseau local une adresse d'IP
d'une classe d'IP différente selon la connexion Internet qui sera utilisée
ou bien d'attribuer autant d'adresses IP à chaque machine locale qu'il y a
de connexion Internet si ces machines locales ont besoin d'utiliser plus
d'une connexion Internet. Cela donnerait pour le premier quelque chose comme
:

iptables -A POSTROUTING -o eth0 -s 192.168.0.0/24
-j SNAT --to-source 192.168.254.1
iptables -A POSTROUTING -o eth0 -s 192.168.2.0/24
-j SNAT --to-source 192.168.1.1

ip rule add from 192.168.0.0/24 to 192.168.0.0/24 table main
ip rule add from 192.168.2.0/24 to 192.168.2.0/24 table main
ip rule add from 192.168.0.0/24 table intranet1
ip rule add from 192.168.2.0/24 table intranet2
ip rule add from 192.168.1.1 table intranet1
ip rule add from 192.168.254.1 table intranet2

ip route add table intranet1 via 192.168.1.254 dev eth2
ip route add table intranet2 via 192.168.254.254 dev eth0

ou pour le deuxième cas :

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.1 --dport 3000:3001
-j DNAT --to-destination 192.168.0.131

ip rule add from 192.168.0.130 table main (inutile)
ip rule add from 192.168.0.131 table intranet

ip route add table intranet via 192.168.1.254 dev eth2

J'ai fait les modifications comme indiquées. Mais le résultat est le
même

Essayez avec mes indications précédentes.

un tcpdump -i eth2 me montre des paquets entrant sur le port
3000, mais rien sur l'interface eth1...

J'ai du mal à comprendre comment ça puisse être le cas.
Essayez d'en savoir plus avec les règles suivantes qui permettront de tracer
le paquet de son entrée et à sa sortie :

iptables -t mangle -A PREROUTING -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: prerouting: '
iptables -t mangle -A FORWARD -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: forward: '
iptables -t mangle -A POSTROUTING -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: postrouting: '

le résultat des logs dans les messages du noyau.

Cela s'éclaire tout doucement, mais ce n'est pas encore ça ;-)

On y presque. ;-)

--
TiChou

Le 16-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :

Dans le message <news:slrnd178ao.nbn.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

J'ai remis ceci :

iptables -t mangle -A PREROUTING -p tcp --sport 3000:3001
-s 192.168.0.130 -j MARK --set-mark 1

ip rule add fwmark 0x01 table intranet

et cela :

iptables -t mangle -A PREROUTING -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: prerouting: '
iptables -t mangle -A FORWARD -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: forward: '
iptables -t mangle -A POSTROUTING -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: postrouting: '

le résultat des logs dans les messages du noyau.

et j'obtiens :

Feb 17 10:34:30 kant kernel: NETFILTER: prerouting: IN=eth2 OUT MAC:00:20:c0:ff:ee:00:20:ea:f9:d5:f3:08:00 SRC‚.101.6.157
DST2.168.1.1 LEN` TOS=0x00 PREC=0x00 TTLW IDC208 DF PROTO=TCP
SPTR431 DPT000 WINDOWX40 RES=0x00 CWR ECE SYN URGP=0

En attaquant sur l'autre interface, j'obtiens :

Feb 17 10:35:29 kant kernel: NETFILTER: prerouting: IN=eth0 OUT MAC:00:20:c0:ff:ee:00:0b:23:0e:cf:74:08:00 SRC‚.101.6.157
DST2.168.254.1 LENR TOS=0x00 PREC=0x00 TTLV ID0749 DF PROTO=TCP
SPTR440 DPT000 WINDOWX40 RES=0x00 ACK URGP=0
Feb 17 10:35:29 kant kernel: NETFILTER: forward: IN=eth0 OUT=eth1
SRC‚.101.6.157 DST2.168.0.130 LENR TOS=0x00 PREC=0x00 TTLU
ID0749 DF PROTO=TCP SPTR440 DPT000 WINDOWX40 RES=0x00 ACK URGP=0
Feb 17 10:35:29 kant kernel: NETFILTER: postrouting: IN= OUT=eth1
SRC‚.101.6.157 DST2.168.0.130 LENR TOS=0x00 PREC=0x00 TTLU
ID0749 DF PROTO=TCP SPTR440 DPT000 WINDOWX40 RES=0x00 ACK URGP=0

Je sèche de plus en plus. On y est presque, le tout est dans le
presque ;-)

Cordialement,

JKB

Salut,

Feb 17 10:34:30 kant kernel: NETFILTER: prerouting: IN=eth2 OUT > MAC:00:20:c0:ff:ee:00:20:ea:f9:d5:f3:08:00 SRC‚.101.6.157
DST2.168.1.1 LEN` TOS=0x00 PREC=0x00 TTLW IDC208 DF PROTO=TCP
SPTR431 DPT000 WINDOWX40 RES=0x00 CWR ECE SYN URGP=0

En attaquant sur l'autre interface, j'obtiens :

Feb 17 10:35:29 kant kernel: NETFILTER: prerouting: IN=eth0 OUT > MAC:00:20:c0:ff:ee:00:0b:23:0e:cf:74:08:00 SRC‚.101.6.157
DST2.168.254.1 LENR TOS=0x00 PREC=0x00 TTLV ID0749 DF PROTO=TCP
SPTR440 DPT000 WINDOWX40 RES=0x00 ACK URGP=0

Feb 17 10:35:29 kant kernel: NETFILTER: forward: IN=eth0 OUT=eth1
SRC‚.101.6.157 DST2.168.0.130 LENR TOS=0x00 PREC=0x00 TTLU
ID0749 DF PROTO=TCP SPTR440 DPT000 WINDOWX40 RES=0x00 ACK URGP=0

Je sèche de plus en plus. On y est presque, le tout est dans le
presque ;-)

As-tu bien mis la règle de NAT destination avec l'adresse de l'interface
eth2 ? Tu peux ajouter une règle LOG dans la chaîne INPUT pour voir si
le paquet ne partirait pas par là.

Vérifie aussi que le reverse path filtering est désactivé sur eth2 au
moins. /proc/sys/net/ipv4/conf/eth2/rp_filter doit contenir 0. Sinon
tout paquet entrant sur eth2 avec une adresse source ne correspondant
pas à une route sortant par cette interface (ce qui est le cas puisque
la route par défaut normale passe par eth0) est rejeté. Le symptôme
correspond à ce que tu observes : le paquet traverse PREROUTING mais ne
va pas plus loin.

Autrement, quelques suggestion en vrac et sans garantie.

- La cible CONNMARK du patch-o-matic pourrait être intéressante dans ton
cas pour marquer les paquets retour avant la décision de routage
(problème évoqué par Tichou dans le message auquel tu répondais).

- Si le routeur relié à eth2 est capable de faire du NAT source (SNAT)
dans le sens extérieur -> intérieur et que tu n'as pas besoin de voir
les véritables adresses sources sur le serveur, ça éviterait d'avoir à
jouer sur le routage de la passerelle.

Dans le message <news:slrnd18pgb.slg.knatschke@rayleigh.systella.fr>,
*JKB* tapota sur f.c.o.l.configuration :

J'ai remis ceci :

iptables -t mangle -A PREROUTING -p tcp --sport 3000:3001
-s 192.168.0.130 -j MARK --set-mark 1

ip rule add fwmark 0x01 table intranet

et cela :

iptables -t mangle -A PREROUTING -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: prerouting: '
iptables -t mangle -A FORWARD -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: forward: '
iptables -t mangle -A POSTROUTING -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: postrouting: '

le résultat des logs dans les messages du noyau.

et j'obtiens :

Feb 17 10:34:30 kant kernel: NETFILTER: prerouting: IN=eth2 OUT > MAC:00:20:c0:ff:ee:00:20:ea:f9:d5:f3:08:00 SRC‚.101.6.157
DST2.168.1.1 LEN` TOS=0x00 PREC=0x00 TTLW IDC208 DF PROTO=TCP
SPTR431 DPT000 WINDOWX40 RES=0x00 CWR ECE SYN URGP=0

et en ajoutant :

iptables -t mangle -A INPUT -p tcp --dport 3000
-j LOG --log-prefix 'NETFILTER: input: '

obtenez-vous quelque chose de plus ?

De plus, vu que la connexion n'aboutit pas, elle se termine par un «
timeout » ou un « connection refused » ?

Je sèche de plus en plus.

Soit le paquet n'est pas naté et on devrait vraisemblament le « voir » dans
la chaîne INPUT de la table mangle.
Soit le paquet est bien naté, mais alors dans ce cas il n'est pas routé vu
qu'il n'est pas loggé dans la chaîne FORWARD. Comme les tables de routage
semblent correctes, il pourrait alors s'agir d'un problème de forwarding.

On y est presque, le tout est dans le presque ;-)

J'espère parce que j'avoue commence à sécher un peu.

--
TiChou