Problème routage ou config IP.

Salut,

J'ai une debian, avec 2 cartes réseaux, derrière un routeur WRT54G, au
firmware fondé sur du linux. Je viens d'ajouter une 2de addresse locale
au routeur, j'ai testé avec une machine dans chaque réseau, ça route
bien dans tous les sens, le routeur fait bien son travail.

Sur le routeur, 2 addresses ip sur le LAN, 172.16.0.1/24 et
172.16.1.1/24 et une addresse ip publique sur le net. le routeur fait du
NAT pour sortir et du port forwarding pour offrir un accès depuis
internet aux services web hébergés sur la debian.

Sur la Debian, 2 cartes réseaux, eth0, dédiée pour les services web,
adresse 172.16.1.2, et eth1, dédié service locaux, addresse 172.16.0.10.
eth0 est bridé en débit par wondershaper.

Si je comprends bien les deux interfaces sont sur le même réseau
ethernet. Ça peut nécessiter des précautions au niveau des paramètres
ARP du noyau comme 'arp_ignore=1' (par défaut la pile IP répond à une
requête ARP reçue sur une interface même si la requête concerne une
adresse IP attachée à une autre interface).

Les machines du LAN sont en 172.16.0.X

Comment doit être ma table de routage sur la Debian pour que les
machines locales, sur le réseau 172.16.0.0/24 puissent éventuellement
accéder sur le lan à eth0 (test), eth1 (DHCP, Samba, DNS local, sites
web d'admin), et aussi accéder aux services internet (web, messagerie,
ssh) à travers l'adresse publique (donc natté vers l'addresse publique
puis re-forwardé vers eth1),

Je ne vois pas trop en quoi la table de routage de la Debian est
concernée par tout ça.

au niveau de la Debian, tout le traffic
internet doit passer par eth0 (pour être bridé par le wondershaper),
tout le traffic local doit passer par eth1.

Si tu veux que le trafic internet sorte par eth0, il suffit de définir
la route par défaut via cette interface, avec l'adresse de passerelle
172.16.0.1.

Pour l'instant, j'ai:

~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
localnet * 255.255.255.0 U 0 0 0 eth1
172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 172.16.1.1 0.0.0.0 UG 0 0 0 eth0

Curieux, je n'ai jamais vu de route vers 127.0.0.0/8 dans la table de
routage principale d'une Debian (sa place est dans la table de routage
locale qui n'est pas affichée par 'route').

Quoi que je fasse, ça merdouille, au moins les service web marchent
depuis le web, mais en local ça tourne pas, impossible d'atteindre les
services web via l'addresse publique,

C'est du ressort du NAT du routeur (NAT source nécessaire en même temps
que les redirections de port).

impossible de joindre eth0,

C'est-à-dire ?
Tu as fait des captures de trafic ?

et le dhcp refuse de servir des ip sur eth1, ça m'énerve.

Ça dépend plus de la configuration du démon DHCP que du routage.

Question subsidiaire, pourquoi le réseau 172.16.0.0 est-il montré comme
"localnet" ? (en utilisant "ip route", la réponse est bien numérique)

Il doit y avoir une correspondance entre 'localnet' et 172.16.0.0 dans
le fichier /etc/networks, l'équivalent de /etc/hosts pour les adresses
de réseaux. L'option -n empêchera 'route' de chercher à résoudre les
adresses en noms.

[Supersedes]

Salut,

J'ai une debian, avec 2 cartes réseaux, derrière un routeur WRT54G, au
firmware fondé sur du linux. Je viens d'ajouter une 2de addresse locale
au routeur, j'ai testé avec une machine dans chaque réseau, ça route
bien dans tous les sens, le routeur fait bien son travail.

Sur le routeur, 2 addresses ip sur le LAN, 172.16.0.1/24 et
172.16.1.1/24 et une addresse ip publique sur le net. le routeur fait du
NAT pour sortir et du port forwarding pour offrir un accès depuis
internet aux services web hébergés sur la debian.

Sur la Debian, 2 cartes réseaux, eth0, dédiée pour les services web,
adresse 172.16.1.2, et eth1, dédié service locaux, addresse 172.16.0.10.
eth0 est bridé en débit par wondershaper.

Si je comprends bien les deux interfaces sont sur le même réseau
ethernet. Ça peut nécessiter des précautions au niveau des paramètres
ARP du noyau comme 'arp_ignore=1' (par défaut la pile IP répond à une
requête ARP reçue sur une interface même si la requête concerne une
adresse IP attachée à une autre interface).

Les machines du LAN sont en 172.16.0.X

Comment doit être ma table de routage sur la Debian pour que les
machines locales, sur le réseau 172.16.0.0/24 puissent éventuellement
accéder sur le lan à eth0 (test), eth1 (DHCP, Samba, DNS local, sites
web d'admin), et aussi accéder aux services internet (web, messagerie,
ssh) à travers l'adresse publique (donc natté vers l'addresse publique
puis re-forwardé vers eth1),

Je ne vois pas trop en quoi la table de routage de la Debian est
concernée par tout ça.

au niveau de la Debian, tout le traffic
internet doit passer par eth0 (pour être bridé par le wondershaper),
tout le traffic local doit passer par eth1.

Si tu veux que le trafic internet sorte par eth0, il suffit de définir
la route par défaut via cette interface, avec l'adresse de passerelle
172.16.1.1.

Pour l'instant, j'ai:

~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
localnet * 255.255.255.0 U 0 0 0 eth1
172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 172.16.1.1 0.0.0.0 UG 0 0 0 eth0

Curieux, je n'ai jamais vu de route vers 127.0.0.0/8 dans la table de
routage principale d'une Debian (sa place est dans la table de routage
locale qui n'est pas affichée par 'route').

Quoi que je fasse, ça merdouille, au moins les service web marchent
depuis le web, mais en local ça tourne pas, impossible d'atteindre les
services web via l'addresse publique,

C'est du ressort du NAT du routeur (NAT source nécessaire en même temps
que les redirections de port).

impossible de joindre eth0,

C'est-à-dire ?
Tu as fait des captures de trafic ?

et le dhcp refuse de servir des ip sur eth1, ça m'énerve.

Ça dépend plus de la configuration du démon DHCP que du routage.

Question subsidiaire, pourquoi le réseau 172.16.0.0 est-il montré comme
"localnet" ? (en utilisant "ip route", la réponse est bien numérique)

Il doit y avoir une correspondance entre 'localnet' et 172.16.0.0 dans
le fichier /etc/networks, l'équivalent de /etc/hosts pour les adresses
de réseaux. L'option -n empêchera 'route' de chercher à résoudre les
adresses en noms.

[Supersedes]

Salut,


Si je comprends bien les deux interfaces sont sur le même réseau
ethernet. Ça peut nécessiter des précautions au niveau des paramètres
ARP du noyau comme 'arp_ignore=1' (par défaut la pile IP répond à une
requête ARP reçue sur une interface même si la requête concerne une
adresse IP attachée à une autre interface).

Oui tout le monde est sur le même réseau ethernet, avec eth0 et eth1 en
direct sur le WRT54G, et les machines clientes sur un petit switch SMC.
Comment tuner ces paramètres ? Je n'ai jamais fait ce genre de manip.
Est-ce possible sans recompiler le noyau ?

Je ne vois pas trop en quoi la table de routage de la Debian est
concernée par tout ça.

C'était la piste sur laquelle je me focalisais, mais je doute de tout
maintenant...

au niveau de la Debian, tout le traffic internet doit passer par eth0 (pour
être bridé par le wondershaper), tout le traffic local doit passer par
eth1.

Si tu veux que le trafic internet sorte par eth0, il suffit de définir
la route par défaut via cette interface, avec l'adresse de passerelle
172.16.1.1.

C'est le cas.

Pour l'instant, j'ai:

~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
localnet * 255.255.255.0 U 0 0 0 eth1
172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 172.16.1.1 0.0.0.0 UG 0 0 0 eth0

Curieux, je n'ai jamais vu de route vers 127.0.0.0/8 dans la table de
routage principale d'une Debian (sa place est dans la table de routage
locale qui n'est pas affichée par 'route').

C'est le résultat d'un de mes tatonnements, je vais virer cette route
là.

J'ai maintenant:

~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1
172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0
eth0

Quoi que je fasse, ça merdouille, au moins les service web marchent depuis
le web, mais en local ça tourne pas, impossible d'atteindre les services
web via l'addresse publique,

C'est du ressort du NAT du routeur (NAT source nécessaire en même temps
que les redirections de port).

Oui et non, j'ai l'impression que le Nat seul n'est pas en cause.
Depuis internet, je peux accéder au site web. Depuis le Lan, je pouvais
y accéder avant, en utilisant l'ip publique, mais

maintenant ça ne fonctionne plus.

impossible de joindre eth0,

C'est-à-dire ?
Tu as fait des captures de trafic ?

Oui, plein !

Par exemple, pour un ping de 172.16.0.156 vers 172.16.1.56 (qui passe)
puis vers le eth0 de la Debian, j'ai:

C:Program FilesEthereal>tethereal.exe -i 2
Capturing on Marvell Gigabit Ethernet Controller (Microsoft's Packet
Scheduler)

1 0.000000 172.16.0.156 -> 172.16.1.56 ICMP Echo (ping) request
2 0.001724 172.16.1.56 -> 172.16.0.156 ICMP Echo (ping) reply
3 0.988564 172.16.0.156 -> 172.16.1.56 ICMP Echo (ping) request
4 0.990299 172.16.1.56 -> 172.16.0.156 ICMP Echo (ping) reply
5 1.988673 172.16.0.156 -> 172.16.1.56 ICMP Echo (ping) request
6 1.990387 172.16.1.56 -> 172.16.0.156 ICMP Echo (ping) reply
7 2.988708 172.16.0.156 -> 172.16.1.56 ICMP Echo (ping) request
8 2.990422 172.16.1.56 -> 172.16.0.156 ICMP Echo (ping) reply
9 4.663683 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
10 10.004952 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
11 10.005711 172.16.0.1 -> 172.16.0.156 ICMP Redirect (Redirect for
host)
12 15.505303 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
13 15.506057 172.16.0.1 -> 172.16.0.156 ICMP Redirect (Redirect for
host)
14 21.005752 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
15 21.006509 172.16.0.1 -> 172.16.0.156 ICMP Redirect (Redirect for
host)

et le dhcp refuse de servir des ip sur eth1, ça m'énerve.

Ça dépend plus de la configuration du démon DHCP que du routage.

avec ça pourtant, ça devrait bien fournir les ip sur eth1, non ?

# Local LAN
subnet 172.16.0.0 netmask 255.255.255.0 {
<Options Config IP, pour faire court>
}
# LAN DMZ
subnet 172.16.1.0 netmask 255.255.255.0 {
}

Tant que j'ai eth0 up sur le debian, j'ai ce genre de dialogue:
66 12.999667 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover -
Transaction ID 0xc6485e79
67 13.000284 172.16.0.10 -> 172.16.0.100 DHCP DHCP Offer -
Transaction ID 0xc6485e79
68 13.000809 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request -
Transaction ID 0xc6485e79
69 13.001263 172.16.1.2 -> 255.255.255.255 DHCP DHCP NAK -
Transaction ID 0xc6485e79
70 13.001496 172.16.0.10 -> 172.16.0.100 DHCP DHCP ACK -
Transaction ID 0xc6485e79
71 14.000006 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover -
Transaction ID 0xe6b35a0b
72 14.000646 172.16.0.10 -> 172.16.0.100 DHCP DHCP Offer -
Transaction ID 0xe6b35a0b
73 14.001163 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request -
Transaction ID 0xe6b35a0b
74 14.001627 172.16.1.2 -> 255.255.255.255 DHCP DHCP NAK -
Transaction ID 0xe6b35a0b
75 14.001849 172.16.0.10 -> 172.16.0.100 DHCP DHCP ACK -
Transaction ID 0xe6b35a0b
76 14.999937 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover -
Transaction ID 0x8ecd9cd0
77 15.000700 172.16.0.10 -> 172.16.0.100 DHCP DHCP Offer -
Transaction ID 0x8ecd9cd0
78 15.001330 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request -
Transaction ID 0x8ecd9cd0
79 15.001793 172.16.1.2 -> 255.255.255.255 DHCP DHCP NAK -
Transaction ID 0x8ecd9cd0
80 15.002020 172.16.0.10 -> 172.16.0.100 DHCP DHCP ACK -
Transaction ID 0x8ecd9cd0

De plus, si je fais un "ifconfig eth0 down" , dhcp se remet à marcher.
1 0.000000 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover -
Transaction ID 0xb5c78c12
2 0.000531 172.16.0.10 -> 172.16.0.100 DHCP DHCP Offer -
Transaction ID 0xb5c78c12
3 0.001011 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request -
Transaction ID 0xb5c78c12
4 0.001433 172.16.0.10 -> 172.16.0.100 DHCP DHCP ACK -
Transaction ID 0xb5c78c12
5 0.006685 172.16.0.100 -> Broadcast ARP Who has 172.16.0.100?
Gratuitous ARP
6 0.560652 172.16.0.100 -> Broadcast ARP Who has 172.16.0.100?
Gratuitous ARP
7 1.560733 172.16.0.100 -> Broadcast ARP Who has 172.16.0.100?
Gratuitous ARP

Question subsidiaire, pourquoi le réseau 172.16.0.0 est-il montré comme
"localnet" ? (en utilisant "ip route", la réponse est bien numérique)

Il doit y avoir une correspondance entre 'localnet' et 172.16.0.0 dans
le fichier /etc/networks, l'équivalent de /etc/hosts pour les adresses
de réseaux. L'option -n empêchera 'route' de chercher à résoudre les
adresses en noms.

Merci de m'aider à progresser dans la compréhension de mes soucis ! :)

--
Miaou

Si je comprends bien les deux interfaces sont sur le même réseau
ethernet. Ça peut nécessiter des précautions au niveau des paramètres
ARP du noyau comme 'arp_ignore=1' (par défaut la pile IP répond à une
requête ARP reçue sur une interface même si la requête concerne une
adresse IP attachée à une autre interface).

Oui tout le monde est sur le même réseau ethernet, avec eth0 et eth1 en
direct sur le WRT54G, et les machines clientes sur un petit switch SMC.
Comment tuner ces paramètres ? Je n'ai jamais fait ce genre de manip.
Est-ce possible sans recompiler le noyau ?

Oui, ce sont des paramètres dynamiques, pas des options de compilation,
n des options de démarrage. On y accède soit par le pseudo-système de
fichiers /proc/sys/net/ipv4 ou avec le programme 'sysctl'. Par exemple :

$ echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
ou :
$ sysctl -w net/ipv4/conf/all/arp_ignore=1

La description des paramètres réseau est dans le fichier
Documentation/networking/ip-sysctl.txt de la documentation du noyau,
fournie avec les sources ou avec les paquets Debian kernel-doc-2.x.y.

[...]

J'ai maintenant:

~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 eth0

Ça me paraît suffisant.

Quoi que je fasse, ça merdouille, au moins les service web marchent
depuis le web, mais en local ça tourne pas, impossible d'atteindre
les services web via l'addresse publique,

C'est du ressort du NAT du routeur (NAT source nécessaire en même temps
que les redirections de port).

Oui et non, j'ai l'impression que le Nat seul n'est pas en cause. Depuis
internet, je peux accéder au site web.

Depuis internet il n'y a pas besoin de NAT source car c'est un réseau
distinct du LAN. Le problème se pose quand la destination de la
redirection de port est dans le même réseau que le client.

Depuis le Lan, je pouvais y accéder avant, en utilisant l'ip publique,
mais maintenant ça ne fonctionne plus.

Qu'avais-tu fait pour que ça marche ? Qu'as-tu changé depuis ?

impossible de joindre eth0,

C'est-à-dire ?
Tu as fait des captures de trafic ?

Oui, plein !

Par exemple, pour un ping de 172.16.0.156 vers 172.16.1.56 (qui passe)

A quoi correspondent ces adresses ?

puis vers le eth0 de la Debian, j'ai:

C:Program FilesEthereal>tethereal.exe -i 2
Capturing on Marvell Gigabit Ethernet Controller (Microsoft's Packet
Scheduler)

1 0.000000 172.16.0.156 -> 172.16.1.56 ICMP Echo (ping) request
2 0.001724 172.16.1.56 -> 172.16.0.156 ICMP Echo (ping) reply

9 4.663683 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
10 10.004952 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
11 10.005711 172.16.0.1 -> 172.16.0.156 ICMP Redirect (Redirect for host)

Ici le routeur signale à 172.16.0.156 qu'il y a une route plus directe
vers 172.16.0.156. Cela signifie que 172.16.0.156 n'a pas de route
directe explicite vers 172.16.0.0/24 et a utilisé la route par défaut.
Je m'étonne que cela ne se soit pas produit lors du ping de 172.16.1.56.

12 15.505303 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
13 15.506057 172.16.0.1 -> 172.16.0.156 ICMP Redirect (Redirect for host)
14 21.005752 172.16.0.156 -> 172.16.1.2 ICMP Echo (ping) request
15 21.006509 172.16.0.1 -> 172.16.0.156 ICMP Redirect (Redirect for host)

Il faudrait aussi faire des captures au niveau du routeur et de la
Debian en incluant aussi les paquets ARP pour voir pourquoi l'echo-reply
ne revient pas.

et le dhcp refuse de servir des ip sur eth1, ça m'énerve.
[...]

Tant que j'ai eth0 up sur le debian, j'ai ce genre de dialogue:
66 12.999667 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover -
Transaction ID 0xc6485e79
67 13.000284 172.16.0.10 -> 172.16.0.100 DHCP DHCP Offer -
Transaction ID 0xc6485e79
68 13.000809 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request -
Transaction ID 0xc6485e79
69 13.001263 172.16.1.2 -> 255.255.255.255 DHCP DHCP NAK -
Transaction ID 0xc6485e79
70 13.001496 172.16.0.10 -> 172.16.0.100 DHCP DHCP ACK -
Transaction ID 0xc6485e79

eth0 reçoit aussi la requête du client pour l'adresse 172.16.0.100 (qui
est broadcastée, donc normal) et y répond négativement (NAK, normal
encore) alors que eth1 répond positivement (ACK). Manque de bol, la
réponse négative arrive avant la réponse positive. Pas de bol... Je ne
sais pas s'il y a une solution autre que désactiver le serveur DHCP sur
eth0.

De plus, si je fais un "ifconfig eth0 down" , dhcp se remet à marcher.

Logique.

Bon, à priori mes soucis n'étaient pas au niveau de l'arp, du moins pas
tel que l'on partait, mais plutôt étaient masqué par le rp_filter mis à
1 par défaut.

Du coup j'ai vilament bougé tout ça, fait un réseau en 172.16.0.X pour
les postes, 172.16.1.2 pour la patte Web et 172.16.2.2 pour la patte
LAN, donc le routeur a maintenant 3 ip, une dans chaque réseau. j'ai
ajouté sur le serveur une route statique de 172.16.2.X vers 172.16.0.X
passant par le routeur, et là je couvre tout, même le flux repassant
par l'addresse publique et revenant vers le serveur en
port-foorwarding.
Par contre, j'ai du reconfier le DHCP sur le routeur, dhcp3 refusant
d'offrir des ip pour un réseau dans lequel il n'est pas.

En tout merci de m'avoir guidé dans mes errements.

Christophe

Oui, ce sont des paramètres dynamiques, pas des options de compilation, n des
options de démarrage. On y accède soit par le pseudo-système de fichiers
/proc/sys/net/ipv4 ou avec le programme 'sysctl'. Par exemple :

$ echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
ou :
$ sysctl -w net/ipv4/conf/all/arp_ignore=1

La description des paramètres réseau est dans le fichier
Documentation/networking/ip-sysctl.txt de la documentation du noyau, fournie
avec les sources ou avec les paquets Debian kernel-doc-2.x.y.

[...]

Ça me paraît suffisant.

Depuis internet il n'y a pas besoin de NAT source car c'est un réseau
distinct du LAN. Le problème se pose quand la destination de la redirection
de port est dans le même réseau que le client.

Qu'avais-tu fait pour que ça marche ? Qu'as-tu changé depuis ?

A quoi correspondent ces adresses ?

Ici le routeur signale à 172.16.0.156 qu'il y a une route plus directe vers
172.16.0.156. Cela signifie que 172.16.0.156 n'a pas de route directe
explicite vers 172.16.0.0/24 et a utilisé la route par défaut. Je m'étonne
que cela ne se soit pas produit lors du ping de 172.16.1.56.

Il faudrait aussi faire des captures au niveau du routeur et de la Debian en
incluant aussi les paquets ARP pour voir pourquoi l'echo-reply ne revient
pas.

[...]

eth0 reçoit aussi la requête du client pour l'adresse 172.16.0.100 (qui est
broadcastée, donc normal) et y répond négativement (NAK, normal encore) alors
que eth1 répond positivement (ACK). Manque de bol, la réponse négative arrive
avant la réponse positive. Pas de bol... Je ne sais pas s'il y a une solution
autre que désactiver le serveur DHCP sur eth0.

Logique.

--
Miaou