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...
J'ai réussi à compiler un 2.6.10 (et à booter, ce qui n'est pas une mince affaire) sur mon UltraSPARC. Même motif, même punition. Par contre, un coup de patch-o-matic avec ipt_ROUTE et la règle :
résout mon problème. Je penche donc pour un bug spécifique à l'architecture Sparc64 du style int/long, petit ou grand boutiste. Je n'ai pas de PC sous la main pour tester le truc, dommage...
Tant mieux :) Je connaissais le patch ROUTE, mais je ne peux me débarrasser du préjugé que faire du routage dans Netfilter, en dehors des points de décision de routage normaux, a quelque chose de très très sale.
De mon côté, j'ai pu terminer mes essais sur le 2.4.29 x86 avec un bout de réseau similaire au tien (les deux routeurs sont juste remplacés par une seule machine à 3 interfaces). Il m'avait déjà servi pour expérimenter des combinaisons de bridge+VLAN+bonding. Ça marche comme prévu, les paquets de réponse du serveur marqués par la passerelle repartent bien par la bonne interface. Il y a juste un petit souci avec les éventuels ICMP liés (TTL exceeded d'un tcptraceroute par exemple) qui eux ne sortent pas par la bonne interface. C'était prévisible.
Donc si bug il y a, il est bien vicelard et probablement dépendant de l'architecture comme tu l'as supposé. A tout hasard, j'indique les versions des logiciels utilisés :
Noyau Linux 2.4.29 x86 avec les patches Netfilter suivants : CONNMARK HOPLIMIT (HL IPv6) NETMAP REJECT (IPv6) TTL iprange mport directx_conntrack_nat h323_conntrack_nat mms_conntrack_nat (options : http://www.plouf.fr.eu.org/bazar/config-2.4.29) iproute2 20010824 iptables v1.2.6a
-- Boîte à spam :
J'ai réussi à compiler un 2.6.10 (et à booter, ce qui n'est pas une
mince affaire) sur mon UltraSPARC. Même motif, même punition. Par
contre, un coup de patch-o-matic avec ipt_ROUTE et la règle :
résout mon problème. Je penche donc pour un bug spécifique à
l'architecture Sparc64 du style int/long, petit ou grand boutiste.
Je n'ai pas de PC sous la main pour tester le truc, dommage...
Tant mieux :)
Je connaissais le patch ROUTE, mais je ne peux me débarrasser du préjugé
que faire du routage dans Netfilter, en dehors des points de décision de
routage normaux, a quelque chose de très très sale.
De mon côté, j'ai pu terminer mes essais sur le 2.4.29 x86 avec un bout
de réseau similaire au tien (les deux routeurs sont juste remplacés par
une seule machine à 3 interfaces). Il m'avait déjà servi pour
expérimenter des combinaisons de bridge+VLAN+bonding. Ça marche comme
prévu, les paquets de réponse du serveur marqués par la passerelle
repartent bien par la bonne interface. Il y a juste un petit souci avec
les éventuels ICMP liés (TTL exceeded d'un tcptraceroute par exemple)
qui eux ne sortent pas par la bonne interface. C'était prévisible.
Donc si bug il y a, il est bien vicelard et probablement dépendant de
l'architecture comme tu l'as supposé. A tout hasard, j'indique les
versions des logiciels utilisés :
Noyau Linux 2.4.29 x86 avec les patches Netfilter suivants :
CONNMARK
HOPLIMIT (HL IPv6)
NETMAP
REJECT (IPv6)
TTL
iprange
mport
directx_conntrack_nat
h323_conntrack_nat
mms_conntrack_nat
(options : http://www.plouf.fr.eu.org/bazar/config-2.4.29)
iproute2 20010824
iptables v1.2.6a
J'ai réussi à compiler un 2.6.10 (et à booter, ce qui n'est pas une mince affaire) sur mon UltraSPARC. Même motif, même punition. Par contre, un coup de patch-o-matic avec ipt_ROUTE et la règle :
résout mon problème. Je penche donc pour un bug spécifique à l'architecture Sparc64 du style int/long, petit ou grand boutiste. Je n'ai pas de PC sous la main pour tester le truc, dommage...
Tant mieux :) Je connaissais le patch ROUTE, mais je ne peux me débarrasser du préjugé que faire du routage dans Netfilter, en dehors des points de décision de routage normaux, a quelque chose de très très sale.
De mon côté, j'ai pu terminer mes essais sur le 2.4.29 x86 avec un bout de réseau similaire au tien (les deux routeurs sont juste remplacés par une seule machine à 3 interfaces). Il m'avait déjà servi pour expérimenter des combinaisons de bridge+VLAN+bonding. Ça marche comme prévu, les paquets de réponse du serveur marqués par la passerelle repartent bien par la bonne interface. Il y a juste un petit souci avec les éventuels ICMP liés (TTL exceeded d'un tcptraceroute par exemple) qui eux ne sortent pas par la bonne interface. C'était prévisible.
Donc si bug il y a, il est bien vicelard et probablement dépendant de l'architecture comme tu l'as supposé. A tout hasard, j'indique les versions des logiciels utilisés :
Noyau Linux 2.4.29 x86 avec les patches Netfilter suivants : CONNMARK HOPLIMIT (HL IPv6) NETMAP REJECT (IPv6) TTL iprange mport directx_conntrack_nat h323_conntrack_nat mms_conntrack_nat (options : http://www.plouf.fr.eu.org/bazar/config-2.4.29) iproute2 20010824 iptables v1.2.6a
