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...
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à.
J'arrive maintenant à toucher mon serveur intranet derrière la passerelle :
Mon serveur intranet répond (vérifié avec tcpdump -i eth1 port 3000), mais les paquets ne sont pas routés en sortie vers eth2...
Pourtant, j'ai bien :
Root kant:[~] > ip rule list 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 Root kant:[~] > ip route list table intranet default via 192.168.1.254 dev eth2 Root kant:[~] >
Les paquets ne sont jamais envoyés vers eth2 (pas de forward ni de postrouting). Pourquoi ?
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.
C'était cela qui m'avait échappé. Merci.
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.
Ce n'est hélas pas possible...
Cordialement,
JKB
Le 17-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
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
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à.
J'arrive maintenant à toucher mon serveur intranet derrière la
passerelle :
Mon serveur intranet répond (vérifié avec tcpdump -i eth1 port
3000), mais les paquets ne sont pas routés en sortie vers eth2...
Pourtant, j'ai bien :
Root kant:[~] > ip rule list
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
Root kant:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2
Root kant:[~] >
Les paquets ne sont jamais envoyés vers eth2 (pas de forward ni de
postrouting). Pourquoi ?
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.
C'était cela qui m'avait échappé. Merci.
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.
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à.
J'arrive maintenant à toucher mon serveur intranet derrière la passerelle :
Mon serveur intranet répond (vérifié avec tcpdump -i eth1 port 3000), mais les paquets ne sont pas routés en sortie vers eth2...
Pourtant, j'ai bien :
Root kant:[~] > ip rule list 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 Root kant:[~] > ip route list table intranet default via 192.168.1.254 dev eth2 Root kant:[~] >
Les paquets ne sont jamais envoyés vers eth2 (pas de forward ni de postrouting). Pourquoi ?
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.
C'était cela qui m'avait échappé. Merci.
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.
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.
Merci pour ces informations. Voir mon dernier message, ça progresse ;-) C'est maintenant le retoure qui coince...
JKB
Le 17-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
TiChou écrivait dans fr.comp.os.linux.configuration :
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
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.
Merci pour ces informations. Voir mon dernier message, ça progresse
;-) C'est maintenant le retoure qui coince...
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.
Merci pour ces informations. Voir mon dernier message, ça progresse ;-) C'est maintenant le retoure qui coince...
JKB
JKB
Le 17-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), JKB écrivait dans fr.comp.os.linux.configuration :
Le 17-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
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
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à.
J'arrive maintenant à toucher mon serveur intranet derrière la passerelle :
Mon serveur intranet répond (vérifié avec tcpdump -i eth1 port 3000), mais les paquets ne sont pas routés en sortie vers eth2...
Pourtant, j'ai bien :
Root kant:[~] > ip rule list 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 Root kant:[~] > ip route list table intranet default via 192.168.1.254 dev eth2 Root kant:[~] >
Oups, erreur de ma part : il y a du prerouting, forward et postrouting... Erreur de copier coller de ma part...
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 ? Où est le problème ?
Cordialement,
JKB
Le 17-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
JKB écrivait dans fr.comp.os.linux.configuration :
Le 17-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
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
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à.
J'arrive maintenant à toucher mon serveur intranet derrière la
passerelle :
Mon serveur intranet répond (vérifié avec tcpdump -i eth1 port
3000), mais les paquets ne sont pas routés en sortie vers eth2...
Pourtant, j'ai bien :
Root kant:[~] > ip rule list
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
Root kant:[~] > ip route list table intranet
default via 192.168.1.254 dev eth2
Root kant:[~] >
Oups, erreur de ma part : il y a du prerouting, forward et
postrouting... Erreur de copier coller de ma part...
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 ? Où est le problème ?
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à.
J'arrive maintenant à toucher mon serveur intranet derrière la passerelle :
Mon serveur intranet répond (vérifié avec tcpdump -i eth1 port 3000), mais les paquets ne sont pas routés en sortie vers eth2...
Pourtant, j'ai bien :
Root kant:[~] > ip rule list 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 Root kant:[~] > ip route list table intranet default via 192.168.1.254 dev eth2 Root kant:[~] >
Oups, erreur de ma part : il y a du prerouting, forward et postrouting... Erreur de copier coller de ma part...
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 ? Où est le problème ?
Cordialement,
JKB
Pascal
Oups, erreur de ma part : il y a du prerouting, forward et postrouting... Erreur de copier coller de ma part...
Pas de souci, j'avais compris en regardant des interfaces d'entrée et de sortie :)
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 ?
Je dirais oui d'après le contenu de tes messages. Ceci dit, je n'ai jamais utilisé le marquage de paquets dans Netfilter pour faire du routage.
Où est le problème ?
Aucune idée, désolé. Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Par contre tu peux oublier ma suggestion concernant la cible CONNMARK. Je ne devais pas encore être bien réveillé de ma sieste quand j'ai écrit ça.
Oups, erreur de ma part : il y a du prerouting, forward et
postrouting... Erreur de copier coller de ma part...
Pas de souci, j'avais compris en regardant des interfaces d'entrée et de
sortie :)
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 ?
Je dirais oui d'après le contenu de tes messages. Ceci dit, je n'ai
jamais utilisé le marquage de paquets dans Netfilter pour faire du routage.
Où est le problème ?
Aucune idée, désolé. Déjà il faudrait un moyen de vérifier que les
paquets ciblés sont bien marqués. Peut-être une cible LOG avec
correspondance "-m mark" placée dans la chaîne FORWARD ?
Par contre tu peux oublier ma suggestion concernant la cible CONNMARK.
Je ne devais pas encore être bien réveillé de ma sieste quand j'ai écrit ça.
Oups, erreur de ma part : il y a du prerouting, forward et postrouting... Erreur de copier coller de ma part...
Pas de souci, j'avais compris en regardant des interfaces d'entrée et de sortie :)
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 ?
Je dirais oui d'après le contenu de tes messages. Ceci dit, je n'ai jamais utilisé le marquage de paquets dans Netfilter pour faire du routage.
Où est le problème ?
Aucune idée, désolé. Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Par contre tu peux oublier ma suggestion concernant la cible CONNMARK. Je ne devais pas encore être bien réveillé de ma sieste quand j'ai écrit ça.
JKB
Le 17-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Oups, erreur de ma part : il y a du prerouting, forward et postrouting... Erreur de copier coller de ma part...
Pas de souci, j'avais compris en regardant des interfaces d'entrée et de sortie :)
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 ?
Je dirais oui d'après le contenu de tes messages. Ceci dit, je n'ai jamais utilisé le marquage de paquets dans Netfilter pour faire du routage.
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute... ip quelque chose fait des trucs dans le dos comme le réarrangement de l'ordre des règles !
Où est le problème ?
Aucune idée, désolé. Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t mangle -n -v -L permet de l'avoir... Les paquets passent bien par cette règle...
JKB, de plus en plus perplexe...
Le 17-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
Oups, erreur de ma part : il y a du prerouting, forward et
postrouting... Erreur de copier coller de ma part...
Pas de souci, j'avais compris en regardant des interfaces d'entrée et de
sortie :)
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 ?
Je dirais oui d'après le contenu de tes messages. Ceci dit, je n'ai
jamais utilisé le marquage de paquets dans Netfilter pour faire du routage.
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute... ip
quelque chose fait des trucs dans le dos comme le réarrangement de
l'ordre des règles !
Où est le problème ?
Aucune idée, désolé. Déjà il faudrait un moyen de vérifier que les
paquets ciblés sont bien marqués. Peut-être une cible LOG avec
correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t
mangle -n -v -L permet de l'avoir... Les paquets passent bien par
cette règle...
Le 17-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Oups, erreur de ma part : il y a du prerouting, forward et postrouting... Erreur de copier coller de ma part...
Pas de souci, j'avais compris en regardant des interfaces d'entrée et de sortie :)
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 ?
Je dirais oui d'après le contenu de tes messages. Ceci dit, je n'ai jamais utilisé le marquage de paquets dans Netfilter pour faire du routage.
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute... ip quelque chose fait des trucs dans le dos comme le réarrangement de l'ordre des règles !
Où est le problème ?
Aucune idée, désolé. Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t mangle -n -v -L permet de l'avoir... Les paquets passent bien par cette règle...
JKB, de plus en plus perplexe...
Pascal
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ? http://www.policyrouting.org/iproute2-toc.html En tout cas c'est tout ce que j'ai.
Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t mangle -n -v -L permet de l'avoir... Les paquets passent bien par cette règle...
En effet, tu as raison.
Bon, je viens d'essayer chez moi une version simplifiée de ta manip histoire de savoir enfin de quoi je parle dans ce fil. Je savais bien qu'un PC avec 3 cartes réseau pouvait être utile. Par la même occasion j'ai appris des trucs, comme quoi j'avais inconsidérement patché mon dernier noyau 2.4.29 de test à grands coups de patch-o-matic-ng comme un gros goret, rendant le module ipt_MARK incompatible avec mon iptables version 1.2.6a que j'ai la flemme de mettre à jour. Ou comme quoi mon iproute2 version 20010824 interprète et affiche la valeur de fwmark comme de l'hexa même sans 0x devant :- .
Un reboot sur un ancien noyau 2.4.18 plus tard, 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.
Ah, un détail pratique qui peut être utile : après changement dans les tables et règles de routage, il vaut mieux vider le cache de routage avec "ip route flush cache" sinon les routes en cache restent actives jusqu'à ce qu'elles expirent.
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ?
http://www.policyrouting.org/iproute2-toc.html
En tout cas c'est tout ce que j'ai.
Déjà il faudrait un moyen de vérifier que les
paquets ciblés sont bien marqués. Peut-être une cible LOG avec
correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t
mangle -n -v -L permet de l'avoir... Les paquets passent bien par
cette règle...
En effet, tu as raison.
Bon, je viens d'essayer chez moi une version simplifiée de ta manip
histoire de savoir enfin de quoi je parle dans ce fil. Je savais bien
qu'un PC avec 3 cartes réseau pouvait être utile. Par la même occasion
j'ai appris des trucs, comme quoi j'avais inconsidérement patché mon
dernier noyau 2.4.29 de test à grands coups de patch-o-matic-ng comme un
gros goret, rendant le module ipt_MARK incompatible avec mon iptables
version 1.2.6a que j'ai la flemme de mettre à jour. Ou comme quoi mon
iproute2 version 20010824 interprète et affiche la valeur de fwmark
comme de l'hexa même sans 0x devant :- .
Un reboot sur un ancien noyau 2.4.18 plus tard, 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.
Ah, un détail pratique qui peut être utile : après changement dans les
tables et règles de routage, il vaut mieux vider le cache de routage
avec "ip route flush cache" sinon les routes en cache restent actives
jusqu'à ce qu'elles expirent.
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ? http://www.policyrouting.org/iproute2-toc.html En tout cas c'est tout ce que j'ai.
Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t mangle -n -v -L permet de l'avoir... Les paquets passent bien par cette règle...
En effet, tu as raison.
Bon, je viens d'essayer chez moi une version simplifiée de ta manip histoire de savoir enfin de quoi je parle dans ce fil. Je savais bien qu'un PC avec 3 cartes réseau pouvait être utile. Par la même occasion j'ai appris des trucs, comme quoi j'avais inconsidérement patché mon dernier noyau 2.4.29 de test à grands coups de patch-o-matic-ng comme un gros goret, rendant le module ipt_MARK incompatible avec mon iptables version 1.2.6a que j'ai la flemme de mettre à jour. Ou comme quoi mon iproute2 version 20010824 interprète et affiche la valeur de fwmark comme de l'hexa même sans 0x devant :- .
Un reboot sur un ancien noyau 2.4.18 plus tard, 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.
Ah, un détail pratique qui peut être utile : après changement dans les tables et règles de routage, il vaut mieux vider le cache de routage avec "ip route flush cache" sinon les routes en cache restent actives jusqu'à ce qu'elles expirent.
JKB
Le 18-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ? http://www.policyrouting.org/iproute2-toc.html En tout cas c'est tout ce que j'ai.
Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t mangle -n -v -L permet de l'avoir... Les paquets passent bien par cette règle...
En effet, tu as raison.
Bon, je viens d'essayer chez moi une version simplifiée de ta manip histoire de savoir enfin de quoi je parle dans ce fil. Je savais bien qu'un PC avec 3 cartes réseau pouvait être utile. Par la même occasion j'ai appris des trucs, comme quoi j'avais inconsidérement patché mon dernier noyau 2.4.29 de test à grands coups de patch-o-matic-ng comme un gros goret, rendant le module ipt_MARK incompatible avec mon iptables version 1.2.6a que j'ai la flemme de mettre à jour. Ou comme quoi mon iproute2 version 20010824 interprète et affiche la valeur de fwmark comme de l'hexa même sans 0x devant :- .
Un reboot sur un ancien noyau 2.4.18 plus tard, je peux écrire l'expression consacrée : chez moi ça marche (c).
Peut-être, mais ça ne m'aide pas...
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.
Ah, un détail pratique qui peut être utile : après changement dans les tables et règles de routage, il vaut mieux vider le cache de routage avec "ip route flush cache" sinon les routes en cache restent actives jusqu'à ce qu'elles expirent.
J'ai toujours vidé le cache...
Cordialement,
JKB
Le 18-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ?
http://www.policyrouting.org/iproute2-toc.html
En tout cas c'est tout ce que j'ai.
Déjà il faudrait un moyen de vérifier que les
paquets ciblés sont bien marqués. Peut-être une cible LOG avec
correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t
mangle -n -v -L permet de l'avoir... Les paquets passent bien par
cette règle...
En effet, tu as raison.
Bon, je viens d'essayer chez moi une version simplifiée de ta manip
histoire de savoir enfin de quoi je parle dans ce fil. Je savais bien
qu'un PC avec 3 cartes réseau pouvait être utile. Par la même occasion
j'ai appris des trucs, comme quoi j'avais inconsidérement patché mon
dernier noyau 2.4.29 de test à grands coups de patch-o-matic-ng comme un
gros goret, rendant le module ipt_MARK incompatible avec mon iptables
version 1.2.6a que j'ai la flemme de mettre à jour. Ou comme quoi mon
iproute2 version 20010824 interprète et affiche la valeur de fwmark
comme de l'hexa même sans 0x devant :- .
Un reboot sur un ancien noyau 2.4.18 plus tard, je peux écrire
l'expression consacrée : chez moi ça marche (c).
Peut-être, mais ça ne m'aide pas...
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.
Ah, un détail pratique qui peut être utile : après changement dans les
tables et règles de routage, il vaut mieux vider le cache de routage
avec "ip route flush cache" sinon les routes en cache restent actives
jusqu'à ce qu'elles expirent.
Le 18-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ? http://www.policyrouting.org/iproute2-toc.html En tout cas c'est tout ce que j'ai.
Déjà il faudrait un moyen de vérifier que les paquets ciblés sont bien marqués. Peut-être une cible LOG avec correspondance "-m mark" placée dans la chaîne FORWARD ?
Pas besoin, il y a un compteur qui s'incrémente et iptables -t mangle -n -v -L permet de l'avoir... Les paquets passent bien par cette règle...
En effet, tu as raison.
Bon, je viens d'essayer chez moi une version simplifiée de ta manip histoire de savoir enfin de quoi je parle dans ce fil. Je savais bien qu'un PC avec 3 cartes réseau pouvait être utile. Par la même occasion j'ai appris des trucs, comme quoi j'avais inconsidérement patché mon dernier noyau 2.4.29 de test à grands coups de patch-o-matic-ng comme un gros goret, rendant le module ipt_MARK incompatible avec mon iptables version 1.2.6a que j'ai la flemme de mettre à jour. Ou comme quoi mon iproute2 version 20010824 interprète et affiche la valeur de fwmark comme de l'hexa même sans 0x devant :- .
Un reboot sur un ancien noyau 2.4.18 plus tard, je peux écrire l'expression consacrée : chez moi ça marche (c).
Peut-être, mais ça ne m'aide pas...
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.
Ah, un détail pratique qui peut être utile : après changement dans les tables et règles de routage, il vaut mieux vider le cache de routage avec "ip route flush cache" sinon les routes en cache restent actives jusqu'à ce qu'elles expirent.
J'ai toujours vidé le cache...
Cordialement,
JKB
JKB
Le 18-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ? http://www.policyrouting.org/iproute2-toc.html En tout cas c'est tout ce que j'ai.
C'est bien ce que je disais ;-) Celle-là, je l'ai lue et relue sans aucun résultat. Je ne vois pas trop la différence entre ma configuration et celle décrite dans la doc. Je ne comprends toujours pas pourquoi mes paquets marqués ne suivent pas la table intranet :
Root kant:[~] > ip route show table intranet default via 192.168.1.254 dev eth2 Root kant:[~] > ip rule show 0: from all lookup local 32761: from 192.168.1.1 lookup intranet 32762: from all fwmark 0x1 lookup intranet 32766: from all lookup main 32767: from all lookup default Root kant:[~] >
Mon serveur intranet est toujours en 192.168.0.130. La règle 32761 est nécessaire pour pouvoir attaquer la passerelle en ssh. Si j'ai bien compris, iptables me marque les paquets (ça marche) arrivant de 192.168.0.130:3000 par eth1. Je me suis dis que iproute était un peu bête et j'ai rajouté
ip rule add from 192.168.0.130 lookup intranet (ce qui est aberrant, car la règle 32762 stipule que tous les paquets marqués doivent suivre la table intranet). Même motif, même punition, les paquets suivent toujours la table main (j'ai réinitialisé le cache d'iproute à chaque modification). J'ai essayé de truander en rajoutant des règles iptables (pour rediriger les paquets vers eth2, mais d'eth2, ils reppartent en suivant la table main... Tu m'étonnes...).
Je sèche complètement et je ne sais plus pas où investiguer...
JKB
Le 18-02-2005, à propos de
Re: Problème de routage (iproute2 + iptables),
Pascal@plouf écrivait dans fr.comp.os.linux.configuration :
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ?
http://www.policyrouting.org/iproute2-toc.html
En tout cas c'est tout ce que j'ai.
C'est bien ce que je disais ;-) Celle-là, je l'ai lue et relue sans
aucun résultat. Je ne vois pas trop la différence entre ma
configuration et celle décrite dans la doc. Je ne comprends toujours
pas pourquoi mes paquets marqués ne suivent pas la table intranet :
Root kant:[~] > ip route show table intranet
default via 192.168.1.254 dev eth2
Root kant:[~] > ip rule show
0: from all lookup local
32761: from 192.168.1.1 lookup intranet
32762: from all fwmark 0x1 lookup intranet
32766: from all lookup main
32767: from all lookup default
Root kant:[~] >
Mon serveur intranet est toujours en 192.168.0.130. La règle 32761
est nécessaire pour pouvoir attaquer la passerelle en ssh. Si j'ai
bien compris, iptables me marque les paquets (ça marche) arrivant de
192.168.0.130:3000 par eth1. Je me suis dis que iproute était un peu
bête et j'ai rajouté
ip rule add from 192.168.0.130 lookup intranet (ce qui est aberrant,
car la règle 32762 stipule que tous les paquets marqués doivent
suivre la table intranet). Même motif, même punition, les paquets
suivent toujours la table main (j'ai réinitialisé le cache d'iproute
à chaque modification). J'ai essayé de truander en rajoutant des
règles iptables (pour rediriger les paquets vers eth2, mais d'eth2,
ils reppartent en suivant la table main... Tu m'étonnes...).
Je sèche complètement et je ne sais plus pas où investiguer...
Le 18-02-2005, à propos de Re: Problème de routage (iproute2 + iptables), écrivait dans fr.comp.os.linux.configuration :
Ce qui serait bien, c'est d'avoir une vrai doc d'iproute...
Comme ça ? http://www.policyrouting.org/iproute2-toc.html En tout cas c'est tout ce que j'ai.
C'est bien ce que je disais ;-) Celle-là, je l'ai lue et relue sans aucun résultat. Je ne vois pas trop la différence entre ma configuration et celle décrite dans la doc. Je ne comprends toujours pas pourquoi mes paquets marqués ne suivent pas la table intranet :
Root kant:[~] > ip route show table intranet default via 192.168.1.254 dev eth2 Root kant:[~] > ip rule show 0: from all lookup local 32761: from 192.168.1.1 lookup intranet 32762: from all fwmark 0x1 lookup intranet 32766: from all lookup main 32767: from all lookup default Root kant:[~] >
Mon serveur intranet est toujours en 192.168.0.130. La règle 32761 est nécessaire pour pouvoir attaquer la passerelle en ssh. Si j'ai bien compris, iptables me marque les paquets (ça marche) arrivant de 192.168.0.130:3000 par eth1. Je me suis dis que iproute était un peu bête et j'ai rajouté
ip rule add from 192.168.0.130 lookup intranet (ce qui est aberrant, car la règle 32762 stipule que tous les paquets marqués doivent suivre la table intranet). Même motif, même punition, les paquets suivent toujours la table main (j'ai réinitialisé le cache d'iproute à chaque modification). J'ai essayé de truander en rajoutant des règles iptables (pour rediriger les paquets vers eth2, mais d'eth2, ils reppartent en suivant la table main... Tu m'étonnes...).
Je sèche complètement et je ne sais plus pas où investiguer...
JKB
TiChou
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.
-- TiChou
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.
