problème de routage sur un meme brin ethernet

On Wed, 08 Nov 2006 22:43:48 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> wrote:

Généralement, j'applique la convention qui veut que ce soit la dernière
adresse du sous-réseau.
Qui bien entendu n'a rien à voir avec une partie réseau et hôte. (en

fait c'est, en gros, tous les bits de la partie hôte à 1)

Mais c'est juste une convention aussi arbitraire
que la notion de sous-réseau, je pourrais aussi bien choisir une adresse
de broadcast arbitraire.
Les RFCs sont arbitraires, TCP/IP est arbitraire, et cet arbitraire a

l'excellente idée d'exister, mine de rien, parce que quand on doit
envoyer un broadcast c'est vachement plus pratique que tout le monde
soit d'accord sur ce que ça signifie :-)
Enfin bon tant que vous n'appliquez vos théories qu'entre votre salon
et votre chambre, ça ne dérange personne.
--
Nina

Eric Belhomme wrote:

Eric Masson <emss@free.fr> wrote in news:62e824-25k.ln1
@srvbsdnanssv.oursoides-associes.com:

Pas de conf de ce type sous la main pour vérifier, mais ce serait une
violation du fonctionnement standard du routage ip. Seule une machine
présente dans les deux domaines de broacast ip peut joindre les deux
réseaux directement.

C'est pourant ce qui semble se passer sur ma machine :

paris:/home/rico# tcpdump -n -i eth0 net 192.168.100.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:49:38.628020 IP 192.168.1.125 > 192.168.100.100: icmp 40: echo
request seq 56836
08:49:38.628130 IP 192.168.1.125 > 192.168.100.100: icmp 40: echo
request seq 56836
08:49:38.628293 IP 192.168.100.100 > 192.168.1.125: icmp 40: echo reply
seq 56836
08:49:38.628373 IP 192.168.100.254 > 192.168.100.100: icmp 68: redirect
192.168.1.125 to host 192.168.1.125
08:49:43.625948 arp who-has 192.168.100.100 tell 192.168.100.254
08:49:43.626050 arp reply 192.168.100.100 is-at 00:0a:5e:46:dd:5b


En plus je comprends pas le message icmp redirect 192.168.1.125 to
192.168.1.125 ???

Bonjour,

Les messages icmp redirect confirment un pb de routage lié sans doute au
fait que vos deux réseaux se trouvent sur le même réseau physique.

Généralement, une machine envoi des packet ICMP REDIRECT pour signaler
au routeur de nouvelle route. Le routeur prends en charge les packets
ICMP REDIRECT et change sa table de routage dynamiquement. Dans votre
cas, il dois y avoir une pagaille...

Pour éviter que la table de routage soit dynamiquement modifiée par un
host distant, donc pour des raisons de sécurité, il faut parametrer
Linux/Unix de manière a ignorer les packets ICMP REDIRECT.

Pour les mêmes raisons (sécurité), on fait en sorte que Linux/Unix
ignore les packets ICMP envoyés à adresse Multicast ou à l'adresse
Broadcast et faire en sorte que linux/unix ne forwarde pas les packets
avec l'option SOURCE ROUTING dans un systeme multihoming comme le votre.

Je vous propose donc de voir si votre installation Linux ignore ou pas
les messages ICMP REDIRECT et d'appliquer le changement pour voir quel
sera le comportement général.

Dans tous les cas, c'est juste pour expérimentation car il faudra plus
tard ajouter une seconde carte réseau à votre serveur linux pour bien
séparer les deux réseaux.

=============== Une question :
=============== Vous confirmer que vous utiliser un switche et pas un HUB !!!!????
Car si c'est un HUB, alors, ce qui vous arrive est presque normal avec
vos deux réseaux logiques sur le même réseau physique !!!


Cdlt
Rahan

Rahan <Rahan@rahan.net> wrote in
news:45525554$0$10038$426a74cc@news.free.fr:

Les messages icmp redirect confirment un pb de routage lié sans doute
au fait que vos deux réseaux se trouvent sur le même réseau physique.

j'ai 2 sous-réseaux différents sur un même réseau ethernet. De fait, IP

ne _doit_ pas permettre à ces réseaux de communiquer directement, mais
par le biais d'un routeur IP.

Il me semble donc que Eric Masson ait bien raison, la pile IP de mon
routeur envoie à tord un ICMP redirect, puisque un machine du sous réseau
A n'est pas capable de joindre une machine du sous réseau B
Donc soit il s'agit d'un problème de config, dû à mon incompétence, soit
il s'agit d'un bug dans iproute2...

Pour éviter que la table de routage soit dynamiquement modifiée par un
host distant, donc pour des raisons de sécurité, il faut parametrer
Linux/Unix de manière a ignorer les packets ICMP REDIRECT.

la machine du sous réseau B qui recoit le message ICMP redirect n'en

tient pas compte puisque le sous reseau A lui est inconnu !
Sa table de routage est donc correcte

avec l'option SOURCE ROUTING dans un systeme multihoming comme le
votre.

le source routing ne gène pas dans ce cas, puisque les adresses sources

et destinations sont routables du point de vue de ma machine routeur

Vous confirmer que vous utiliser un switche et pas un HUB !!!!????
Car si c'est un HUB, alors, ce qui vous arrive est presque normal avec
vos deux réseaux logiques sur le même réseau physique !!!

Il s'agit de switches exclusivement. Mais je ne vois pas en quoi le fait

de mettre un switch ou un hub influerait sur des problèmes de routage
IP...

--
Rico

Eric Masson <emss@free.fr> wrote in news:dgd924-6ml.ln1
@srvbsdnanssv.oursoides-associes.com:

Première possibilité : ouais mais justement je ne sais pas comment
joindre 192.168.100.100 directement, donc j'ignore l'ICMP Redirect.

Pour moi, c'est ce qui devrait se passer.

je confirme, c'est bien ce qui se passe sur ma machine cible sur mon réseau

"DMZ" (Linux aussi)
Ce que je ne m'explique pas, c'est pourquoi le routeur envoie ce message
icmp redirect ??? est-ce un bug, ou une mauvaise config de ma part ???

Au vu de ce dont j'ai la pratique, j'ai de sérieux doutes, mais
peut-être que linux permet ce genre de bidouilles.

à ma connaissance, c'est impossible, mais je suis loin d'étre un guru IP,

ni meme un guru Linux ;)

--
Rico

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote in news:eit00h$k3b$1
@biggoron.nerim.net:

Il devrait faire les deux, si je ne m'abuse.
Il est aussi étonnant que l'émetteur de l'echo request n'ait pas aussi
eu droit à un ICMP Redirect.

j'ai fini par résoudre mon problème : un bête problème de règle iptables là

où j'étais _persuadé_ qu'il n'y en avait pas, de problème... UNe fois de
plus _le_ soucis etait situé entre la chaise et le clavier ;)

Pour revenir à question de l'icmp redirect, tu as raison de soulever le
fait que le routeur l'envoie à la destination, mais pas à la source ?

Qu'est-ce que ça donne si tu désactives l'envoi des ICMP Redirect sur le
routeur (send_redirects=0) ?
# sysctl -w net/ipv4/conf/eth0/send_redirects=0
# sysctl -w net/ipv4/conf/all/send_redirects=0
Je l'ai désactivé le routeur n'émet plus de icmp redirect. C'est déjà ca...

(il faut les deux, c'est un OU logique)

tu veux dire un ET ?

--
Rico

Il est aussi étonnant que l'émetteur de l'echo request n'ait pas aussi
eu droit à un ICMP Redirect.

j'ai fini par résoudre mon problème : un bête problème de règle iptables là
où j'étais _persuadé_ qu'il n'y en avait pas, de problème...

Sur le routeur ? Ça m'apprendra à faire confiance aux gens qui écrivent
"le firewall entre ces 2 réseau est désactivé". Trust no one. :-D

Pour revenir à question de l'icmp redirect, tu as raison de soulever le
fait que le routeur l'envoie à la destination, mais pas à la source ?

C'est une question ?
Le routeur devrait traiter les deux sous-réseaux de la même façon.
L'absence d'ICMP redirect ne viendrait-elle pas aussi du même problème
de règle iptables ?

Qu'est-ce que ça donne si tu désactives l'envoi des ICMP Redirect sur le
routeur (send_redirects=0) ?
# sysctl -w net/ipv4/conf/eth0/send_redirects=0
# sysctl -w net/ipv4/conf/all/send_redirects=0

Je l'ai désactivé le routeur n'émet plus de icmp redirect. C'est déjà ca...

(il faut les deux, c'est un OU logique)

tu veux dire un ET ?

Ça dépend dans quel sens on le prend. Je voulais dire que la valeur
opérationnelle est un OU logique entre les deux paramètres. En logique
positive, il faut l'un OU l'autre à 1 pour activer l'émission des ICMP
Redirect sur eth0. Réciproquement, en logique négative, il faut l'un ET
l'autre à 0 pour désactiver l'émission des ICMP Redirect sur eth0.

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote in
news:eiuvnq$1ctm$1@biggoron.nerim.net:

Sur le routeur ? Ça m'apprendra à faire confiance aux gens qui
écrivent "le firewall entre ces 2 réseau est désactivé". Trust no one.
:-D

ben oui, la config de ce routeur est assez complexe : il a plusieurs

interfaces (je veux dire des vraies, branchées avec des cables ;), il
NATte, translate, et même en ponte certaines entre elles... et filtre le
tout !
Ca fait un fouillis de règles dans lequel il m'arrive de me perdre ;-/

C'est une question ?
Le routeur devrait traiter les deux sous-réseaux de la même façon.
L'absence d'ICMP redirect ne viendrait-elle pas aussi du même problème
de règle iptables ?

c'est possible, mais j'ai pas vérifié. Il faudrais que je teste sur un

autre machine pour voir...

Ça dépend dans quel sens on le prend. Je voulais dire que la valeur
opérationnelle est un OU logique entre les deux paramètres. En logique
positive, il faut l'un OU l'autre à 1 pour activer l'émission des ICMP
Redirect sur eth0. Réciproquement, en logique négative, il faut l'un
ET l'autre à 0 pour désactiver l'émission des ICMP Redirect sur eth0.

a oui, vu comme ca !

--
Rico

Eric Belhomme wrote:

Rahan <Rahan@rahan.net> wrote in
news:45525554$0$10038$426a74cc@news.free.fr:

Les messages icmp redirect confirment un pb de routage lié sans doute
au fait que vos deux réseaux se trouvent sur le même réseau physique.

j'ai 2 sous-réseaux différents sur un même réseau ethernet. De fait, IP
ne _doit_ pas permettre à ces réseaux de communiquer directement, mais
par le biais d'un routeur IP.

Non, ce n'est pas aussi simple que cela. Séparer physiquement les réseau
n'a seul comme but de réduire le trafic sur un segment mais aussi pour
des raisons de sécurité. Les machines du réseau receveront les paquets
émis de l'autre réseau mais effectiviement, sur le plan théorique, la
couche IP devrait refuser ces trames provenant d'un autre réseau. Puis,
sur le plan pratique, je prefere ne pas raisoner de cette machine en
séparant mes deux réseaux.

Il me semble donc que Eric Masson ait bien raison, la pile IP de mon
routeur envoie à tord un ICMP redirect, puisque un machine du sous réseau
A n'est pas capable de joindre une machine du sous réseau B
Donc soit il s'agit d'un problème de config, dû à mon incompétence, soit
il s'agit d'un bug dans iproute2...

Une erreur de config, je veux bien. Mais un bug aussi flagrant, je dis
non ! ce que vous exposer n'est pas un cas complexe pour etre
difficilement repérable.

Pour éviter que la table de routage soit dynamiquement modifiée par un
host distant, donc pour des raisons de sécurité, il faut parametrer
Linux/Unix de manière a ignorer les packets ICMP REDIRECT.

la machine du sous réseau B qui recoit le message ICMP redirect n'en
tient pas compte puisque le sous reseau A lui est inconnu !
Sa table de routage est donc correcte

cela concerne uniquement les machines qui recoivent les messages ICMP
REDIRECT et qui font tourner un service de routage. Votre machine ignore
en effet les messages ICMP REDIRECT, mais votre routeur est perturbé par
ces messages puisque il dit découvrir un nouveau réseau alors qu'il a
une interface réseau sur le réseau en question !

avec l'option SOURCE ROUTING dans un systeme multihoming comme le
votre.

le source routing ne gène pas dans ce cas, puisque les adresses sources
et destinations sont routables du point de vue de ma machine routeur

Tout a fait, je me suis mal exprimé sur ce point, c'etait pour donner
exemple uniquement. Votre machine ne fait pas du multihoming car votre
serveur à qu'un seule interface réseau physique.

Vous confirmer que vous utiliser un switche et pas un HUB !!!!????
Car si c'est un HUB, alors, ce qui vous arrive est presque normal avec
vos deux réseaux logiques sur le même réseau physique !!!

Il s'agit de switches exclusivement. Mais je ne vois pas en quoi le fait
de mettre un switch ou un hub influerait sur des problèmes de routage
IP...

Pas sur un probleme de routage. Si c'est un HUB, les trames envoyées par
le host du réseau A arriverons au host du réseau B de maniere sure (le
hub broadcast les packets à tous ses ports) ce qui compliquera encore
l'analyse bien que la couche IP est sencée ignoré ces trames provenant
d'un autre réseau car et le routeur et le host de destination receverons
les packets provenant du host emeteur.

Rahan <Rahan@rahan.net> writes:

Les machines du réseau receveront les paquets émis de l'autre réseau
mais effectiviement, sur le plan théorique, la couche IP devrait
refuser ces trames provenant d'un autre réseau.

Pas les refuser, les ignorer.

Puis, sur le plan pratique, je prefere ne pas raisoner de cette
machine en séparant mes deux réseaux.

Dans la vraie vie (tm), il y a des cas ou il n'est pas possible de faire
autrement, c'est donc un setup que l'on peut être amené à rencontrer,
donc à comprendre et gérer correctement (renumérotation incrémentale de
lan avec machines devant être jointes sur leurs anciennes ou nouvelles
adresses pendant la transition, par exemple)

--
C'est tout bête mais avec OE 4 je n'arrive plus à envoyer de
mails (...) alors que j'arrive à me connecter sur le net, à
envoyer des mails,... Please please sauvez-moi...
-+- JC in GNU : Docteur, quand je fais ca, je n'y arrive pas ! -+-

Eric Masson wrote:

Rahan <Rahan@rahan.net> writes:

Les machines du réseau receveront les paquets émis de l'autre réseau
mais effectiviement, sur le plan théorique, la couche IP devrait
refuser ces trames provenant d'un autre réseau.

Pas les refuser, les ignorer.

tout a fait.

Puis, sur le plan pratique, je prefere ne pas raisoner de cette
machine en séparant mes deux réseaux.

Dans la vraie vie (tm), il y a des cas ou il n'est pas possible de faire
autrement, c'est donc un setup que l'on peut être amené à rencontrer,
donc à comprendre et gérer correctement (renumérotation incrémentale de
lan avec machines devant être jointes sur leurs anciennes ou nouvelles
adresses pendant la transition, par exemple)

Dans la vraie vie :) lorsque on trouve ce type de config qui à la base
est une erreur de conception et en aucun cas parceque on ne pouvait pas
faire autrement, il faut apporter les corrections pour des raisons de
sécurité, performance et de gestion.

C'est un setup que l'on peut etre amener à rencontrer et dans ce cas il
faut apporter les corrections. Mais pas un setup qu'on met en place.

Il y a déjà assez de pb qu'il faut résoudre dans des architectures
seines, on ne va pas mettre un baton sur la roue et comprendre ce qui se
passe, si non, on avance pas.

Cdlt
Rahan