Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

problème de routage sur un meme brin ethernet

53 réponses
Avatar
Eric Belhomme
Bonjour,

J'ai un serveur GNU/Linux qui fait office de routeur IPv4, et j'ai
quelques problèmes que je ne comprends pas :

Voici la topologie :

LAN 192.168.1.0/24 ------ eth0 192.168.1.254 ROUTEUR eth1 -----
Internet
DMZ 192.168.100.0/24 ---- eth0:1 192.168.100.254

en fait, les réseaux 192.168.1.0/24 et 192.168.100.0/24 sont sur un même
brin ethernet, mais je veux forcer le passage de LAN vers DMZ via le
routeur sous linux

j'ai donc sur le routeur une route insérée comme ceci :
# ip route add 192.168.100.0/24 via 192.168.100.254

Le problème c'est que ca ne marche pas des masses !

en reniflant le réseau je vois :
1) que mes paquets partent bien vers le routeur
2) sur le routeur je vois 2 fois chaque paquet (une fois en entrée sur
l'interface eth0, une fois en sortie sur cette même interface)
3) sur la machine à atteindre en DMZ, je vois le paquet arriver, et un
paquet en réponse repartir vers la source
4) sur le routeur, je ne vois pas ce paquet retour !

Bien entendu la passerelle par défaut de la machine en DMZ est
192.168.100.254

Le routeur est une Debian Sarge, qui tourne avec un kernel "vanilla"
2.6.18.2, le firewall entre ces 2 réseau est désactivé, et le routage
est bien actif (d'ailleurs les autres interfaces sont bien routées)

Pour mon problème, j'hésite entre 2 causes :
1) ce que je veux faire est crado, et IP ne le permet pas,
2) Le problème est du coté de ma config Linux. mais dans ce cas je ne
vois pas où...

Merci pour toute l'aide que vous pourrez m'apporter :) et fu2 fcri


--
Rico

10 réponses

1 2 3 4 5
Avatar
Rahan
Eric Belhomme wrote:

Bonjour,

J'ai un serveur GNU/Linux qui fait office de routeur IPv4, et j'ai
quelques problèmes que je ne comprends pas :

Voici la topologie :

LAN 192.168.1.0/24 ------ eth0 192.168.1.254 ROUTEUR eth1 -----
Internet
DMZ 192.168.100.0/24 ---- eth0:1 192.168.100.254

en fait, les réseaux 192.168.1.0/24 et 192.168.100.0/24 sont sur un même
brin ethernet, mais je veux forcer le passage de LAN vers DMZ via le
routeur sous linux

j'ai donc sur le routeur une route insérée comme ceci :
# ip route add 192.168.100.0/24 via 192.168.100.254

Le problème c'est que ca ne marche pas des masses !

en reniflant le réseau je vois :
1) que mes paquets partent bien vers le routeur
2) sur le routeur je vois 2 fois chaque paquet (une fois en entrée sur
l'interface eth0, une fois en sortie sur cette même interface)
3) sur la machine à atteindre en DMZ, je vois le paquet arriver, et un
paquet en réponse repartir vers la source
4) sur le routeur, je ne vois pas ce paquet retour !

Bien entendu la passerelle par défaut de la machine en DMZ est
192.168.100.254

Le routeur est une Debian Sarge, qui tourne avec un kernel "vanilla"
2.6.18.2, le firewall entre ces 2 réseau est désactivé, et le routage
est bien actif (d'ailleurs les autres interfaces sont bien routées)

Pour mon problème, j'hésite entre 2 causes :
1) ce que je veux faire est crado, et IP ne le permet pas,
2) Le problème est du coté de ma config Linux. mais dans ce cas je ne
vois pas où...

Merci pour toute l'aide que vous pourrez m'apporter :) et fu2 fcri




Avoir deux réseau logique sur le même réseau physique n'est pas une
bonne idée surtout pour une DMZ. Je pense que le pb est quelque part ici.

Dans le cas d'une connexion TCP. La machine du réseau local ouvre un
canal de communication TCP via votre routeur Linux. Votre routeur Linux
créer une session TCP pour assurer la communication entre les deux
machines. cette session est maintenu jusqu'à ce que le poste DMZ ou du
réseau local envoi une trame avec un drapeau de type END (Fin). Le poste
du réseau local attend un retour de la machine située dans la DMZ via le
routeur linux, donc via la session deja ouverte et gerer par le routeur
Linux. Je pense que le poste de la DMZ envoi la réponse mais elle est
quelque part perdu ou non prise en compte par le poste du réseau local
car ce dernier peut recevoir la réponse sans passer par le routeur
puisque vous utiliser le même réseau physique alors qu'il attend la
réponse via le canal TCP déjà ouvert.

J'espere que c'est claire ce que je voulais dire.

Bon, faites un traceroute ou tracert pour voir comment la machine de la
DMZ arrive à l'autre réseau, si ça ne passe pas, ça permettra
d'identifié à quel moment ça coince.

Afficher la table de routage de la machine située sur la DMZ pour etre
sure que vous n'avez pas une route statique avec un metric qui renderai
un autre itinéraire prioritaire (ce que je ne pense pas).

Si vous avez une seconde carte réseau sur votre routeur Linux, je vous
recommande de l'utiliser pour bien séparer les deux réseaux logiquement
et physiquement.

Tenez nous informer des tests.

Cdlt
Rahan

Avatar
Pascal Hambourg
Salut Rico, tout le monde,


J'ai un serveur GNU/Linux qui fait office de routeur IPv4, et j'ai
quelques problèmes que je ne comprends pas :

Voici la topologie :

LAN 192.168.1.0/24 ---- eth0 192.168.1.254 ROUTEUR eth1 --- Internet
DMZ 192.168.100.0/24 -- eth0:1 192.168.100.254


Pas bien les traits trop longs, ça fait des sauts de ligne parasites. ;-)

en fait, les réseaux 192.168.1.0/24 et 192.168.100.0/24 sont sur un même
brin ethernet, mais je veux forcer le passage de LAN vers DMZ via le
routeur sous linux


Comme Rahan, je suis très dubitatif sur le fait de mettre LAN et DMZ sur
le même réseau physique.

j'ai donc sur le routeur une route insérée comme ceci :
# ip route add 192.168.100.0/24 via 192.168.100.254


Inutile sinon nuisible. Pour ton routeur, 192.168.100.254 est une
adresse locale, pas une adresse de passerelle, et je ne sais pas du tout
comment Linux réagit à une telle route. Je sais comment réagirait
Windows, mais justement Linux et Windows n'ont pas la même façon de
représenter les routes directes.

Bref, la bonne route, qui a dû être créée automatiquement quand tu as
configuré eth0:1 avec 192.168.100.254/24, est celle-ci :

192.168.100.0/24 dev eth0 src 192.168.100.254 [autres options]

Le problème c'est que ca ne marche pas des masses !

en reniflant le réseau je vois :
1) que mes paquets partent bien vers le routeur
2) sur le routeur je vois 2 fois chaque paquet (une fois en entrée sur
l'interface eth0, une fois en sortie sur cette même interface)
3) sur la machine à atteindre en DMZ, je vois le paquet arriver, et un
paquet en réponse repartir vers la source


Avec quelle adresse MAC destination ?

4) sur le routeur, je ne vois pas ce paquet retour !


Le vois-tu sur l'émetteur du paquet initial ?
As-tu reniflé aussi le trafic ICMP et ARP sur les trois machines qui
peut être instructif ?
Le routeur fait-il du NAT entre LAN et DMZ ?

Bien entendu la passerelle par défaut de la machine en DMZ est
192.168.100.254

Le routeur est une Debian Sarge, qui tourne avec un kernel "vanilla"
2.6.18.2, le firewall entre ces 2 réseau est désactivé, et le routage
est bien actif (d'ailleurs les autres interfaces sont bien routées)


Un paquet est entré et ressorti par eth0 donc de ce côté ça semble bon.

Pour mon problème, j'hésite entre 2 causes :
1) ce que je veux faire est crado, et IP ne le permet pas,


C'est crado, mais IP le permet. Sinon ce ne serait pas crado mais
impossible. La pile IP de Linux est très "souple", je dirais.

Avatar
Eric Masson
Pascal Hambourg writes:

'Lut,

C'est crado, mais IP le permet.


Ça s'appelle même "router on a stick" ou "one armed router"

Sinon ce ne serait pas crado mais impossible. La pile IP de Linux est
très "souple", je dirais.


Sous Open, ça passe sans problème, il n'y a pas de route à monter autres
que celles liées à la configuration de l'interface (ifconfig inet, puis
ifconfig alias).

Les machines sur le brin doivent avoir l'adresse de l'interface du
routeur dans leur réseau ip comme route vers l'autre réseau ip.

Par contre, en termes de confidentialité, c'est particulièrement naze,
le domaine de broadcast ethernet restant le même.

--
BC> je ne fais rire que les dinos
Mais vous faites gerber tous les autres.
-+-AC in <http://www.le-gnu.net&gt; : Dépôt de gerbe -+-

Avatar
Pascal Hambourg

Sinon ce ne serait pas crado mais impossible. La pile IP de Linux est
très "souple", je dirais.


Sous Open, ça passe sans problème, il n'y a pas de route à monter autres
que celles liées à la configuration de l'interface (ifconfig inet, puis
ifconfig alias).


Idem sous Linux.

Les machines sur le brin doivent avoir l'adresse de l'interface du
routeur dans leur réseau ip comme route vers l'autre réseau ip.

Par contre, en termes de confidentialité, c'est particulièrement naze,
le domaine de broadcast ethernet restant le même.


Ah ça, je suis bien d'accord. Je me demandais par contre, les ICMP
Redirect qui peuvent être émis par le routeur ont-ils une influence ?
Font-ils comprendre aux machines que la destination est joignable
directement ?


Avatar
Olivier Thauvin
Eric Belhomme wrote:

Bonjour,

J'ai un serveur GNU/Linux qui fait office de routeur IPv4, et j'ai
quelques problèmes que je ne comprends pas :

Voici la topologie :

LAN 192.168.1.0/24 ------ eth0 192.168.1.254 ROUTEUR eth1 -----
Internet
DMZ 192.168.100.0/24 ---- eth0:1 192.168.100.254

en fait, les réseaux 192.168.1.0/24 et 192.168.100.0/24 sont sur un même
brin ethernet, mais je veux forcer le passage de LAN vers DMZ via le
routeur sous linux

j'ai donc sur le routeur une route insérée comme ceci :
# ip route add 192.168.100.0/24 via 192.168.100.254


Ca, ça peut pas marcher par définition:

Tu demande au routeur d'utiliser une passerelle pour aller sur un réseau,
hors cette passerelle serait elle même sur le réseau, donc pour atteindre
la passerelle, faut acceder à la passerelle, donc au reseau... Bref ça se
mord la queue.

La route dont tu as besoin serait plutot:

ip route add 192.168.100.0/24 dev eth0:1

Si j'ai tout suivi (ce qui est pas sûr).

Sauf que sous Unix, en tout cas linux, cette route est ajouté de facto à la
configuration de l'interface:

[ rsync]# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use
Iface
192.168.76.0 * 255.255.255.0 U 0 0 0 eth1
default gw.nanardon 0.0.0.0 UG 0 0 0 eth1

[ rsync]# ifconfig eth0 192.168.3.0
[ rsync]# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use
Iface
192.168.3.0 * 255.255.255.0 U 0 0 0 eth0

Oh, une nouvelle route.

D'ailleurs voici une machine qui est dans la config que tu essaye de faire:

Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use
Iface
1.X.170.0 * 255.255.255.0 U 0 0 0
eth0
1.X.16.0 * 255.255.255.0 U 0 0 0
eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default routeur 0.0.0.0 UG 0 0 0 eth0

Et je te garantie que les machines configuré en /24 passeront pas le routeur
si elle n'ont pas une patte dans chaque réseau (c'est pour éviter ça
justement que nos serveurs on deux adresses car nous avons 2 reseau en /24
non contigus)

Hope this help.

Avatar
Eric Belhomme
Pascal Hambourg wrote in
news:eiqtar$2r9o$:

Pas bien les traits trop longs, ça fait des sauts de ligne parasites.
;-)

désolé :)


Comme Rahan, je suis très dubitatif sur le fait de mettre LAN et DMZ
sur le même réseau physique.

oui, enfin j'appelle ça DMZ, mais ca n'en est pas vraiment une, en tout cas

pas au sens où vous l'entendez ;)

Inutile sinon nuisible. Pour ton routeur, 192.168.100.254 est une
adresse locale, pas une adresse de passerelle, et je ne sais pas du
tout comment Linux réagit à une telle route. Je sais comment réagirait
Windows, mais justement Linux et Windows n'ont pas la même façon de
représenter les routes directes.

oui je me suis trompé dans ma définition :


paris:/home/rico# ip route
...
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.254
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254
...

Avec quelle adresse MAC destination ?

voici les paquets qui transitent sur le routeur pour un ping:


1) ip src -> ip dst (mac src -> mac routeur)
"echo request" original
2) ip src -> ip dst (mac routeur -> mac dst)
"echo request" ré-émis par le routeur
3) ip dst -> ip src (mac dst -> mac routeur)
"echo reply" envoyé vers le routeur
4) ip routeur -> ip dst (mac routeur -> mac dst)
"icmp redirect" (redirect for host)

Clairement, le routeur ne réémet pas la réponse à la machine source, il
envoie à la place un icmp redirect à la machine destination !

As-tu reniflé aussi le trafic ICMP et ARP sur les trois machines qui
peut être instructif ?


au niveau ip et icmp, meme combat, au niveau arp, ben comme c'est du
broadcast au niveau ethernet, toutes les machines voient toutes les
requetes arp...

Le routeur fait-il du NAT entre LAN et DMZ ?

non


Un paquet est entré et ressorti par eth0 donc de ce côté ça semble
bon.

oui mais ca n'a l'air de marcher _que_ dans un sens, c'est ca qui me

gonfle...

C'est crado, mais IP le permet. Sinon ce ne serait pas crado mais
impossible. La pile IP de Linux est très "souple", je dirais.


oui, meme un peu trop ;)

--
Rico

Avatar
Eric Masson
Pascal Hambourg writes:

'Lut,

Idem sous Linux.


Jamais eu à le faire avec un linusque, donc je te fais confiance ;)

Ah ça, je suis bien d'accord. Je me demandais par contre, les ICMP
Redirect qui peuvent être émis par le routeur ont-ils une influence ?
Font-ils comprendre aux machines que la destination est joignable
directement ?


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.

--
Contresens. Le contenu de la signature doit respecter la charte du NG
sur *tous* les sujets. Aussi bien la pub que la Netiquette. C'est pas
une zone de non-droit, les 4 lignes de signature.
-+- Lapin in <www.le-gnu.net> : Oui-Oui casque bleu à Neuneuland -+-

Avatar
Eric Belhomme
Eric Masson 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 ???


--
Rico

Avatar
Eric Masson
Eric Belhomme <{rico}+no/ writes:

'Lut,

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


<Snip tcpdump>

À partir de quelle bécane tu lances le tcpdump ?

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


Je l'assimilerais à un bug de la pile ip du routeur, les deux domaines
de broadcast ip étant sur le même domaine de broadcast ethernet,
celui-ci envoie un redirect qui n'aura aucun effet, puisqu'il reste le
seul moyen de passer d'un réseau à l'autre.

--
Mettre d'un coté ceux qui nous pompent l'air, de l'autre ceux qui
brassent du vent. Nous obtiendrons un Usenet climatisé, c'est ça le
génie français. Ca risque même d'être un peu trop ventilé.
-+- MP in <http://www.le-gnu.net&gt; : Clim et châtiment -+-

Avatar
Eric Belhomme
Eric Masson wrote in news:v1g824-25k.ln1
@srvbsdnanssv.oursoides-associes.com:

<Snip tcpdump>

À partir de quelle bécane tu lances le tcpdump ?

sur le routeur


sur la machine cible ca donne ceci :

:~# tcpdump -n -i eth0 net 192.168.100.0/24 and not port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:44:47.479398 IP 192.168.1.125 > 192.168.100.100: icmp 40: echo
request seq 261
09:44:47.479662 IP 192.168.100.100 > 192.168.1.125: icmp 40: echo reply
seq 261

Donc la mchine recoit un paquet du routeur et y répond au routeur (j'ai
vérifié les adresses MAC, je vous épargne le dump hexa de tcpdump ;)

Je l'assimilerais à un bug de la pile ip du routeur, les deux domaines
de broadcast ip étant sur le même domaine de broadcast ethernet,
celui-ci envoie un redirect qui n'aura aucun effet, puisqu'il reste le
seul moyen de passer d'un réseau à l'autre.

...ou une mauvaise config ! mais il y a tellement de parametres avec

lesquels jouer via sysctl...

--
Rico

1 2 3 4 5