j'ai un soucis avec un routeur sur GNU/Linux Debian Sarge (kernel 2.6.8.2)
dont voici la config :
paris:/tmp# ip -4 addr ls eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.1.254/23 brd 192.168.1.255 scope global eth0
paris:/tmp# ip route ls
195.6.191.112/28 dev eth1 proto kernel scope link src 195.6.191.124
192.168.0.0/23 dev eth0 proto kernel scope link src 192.168.1.254
172.18.0.0/16 via 192.168.1.250 dev eth0
default via 195.6.191.126 dev eth1
Ce que je souhaite obtenir, c'est que mon routeur emette un message icmp
redirect vers le routeur 192.168.1.250 lorsqu'un poste du réseau local
accède au réseau 172.18.0.0/16
Mais pour une raison qui m'échappe, le message icmp redirect n'est pas émis
par mon routeur !
paris:/tmp# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:11:50.436921 IP 192.168.1.20 > 172.18.100.13: icmp 40: echo request seq
6913
14:11:51.449882 IP 192.168.1.20 > 172.18.100.13: icmp 40: echo request seq
7169
14:11:52.949791 IP 192.168.1.20 > 172.18.100.13: icmp 40: echo request seq
7425
14:11:54.449863 IP 192.168.1.20 > 172.18.100.13: icmp 40: echo request seq
7681
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TiChou
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
j'ai un soucis avec un routeur sur GNU/Linux Debian Sarge (kernel 2.6.8.2) dont voici la config :
[conf]
Ce que je souhaite obtenir, c'est que mon routeur emette un message icmp redirect vers le routeur 192.168.1.250 lorsqu'un poste du réseau local accède au réseau 172.18.0.0/16 Mais pour une raison qui m'échappe, le message icmp redirect n'est pas émis par mon routeur !
[tcpdump]
Une suggestion ?
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
-- TiChou
Dans le message <news:Xns9666916CB545Aericbelhommefreefr@212.27.42.70>,
*Eric Belhomme* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
j'ai un soucis avec un routeur sur GNU/Linux Debian Sarge (kernel 2.6.8.2)
dont voici la config :
[conf]
Ce que je souhaite obtenir, c'est que mon routeur emette un message icmp
redirect vers le routeur 192.168.1.250 lorsqu'un poste du réseau local
accède au réseau 172.18.0.0/16
Mais pour une raison qui m'échappe, le message icmp redirect n'est pas
émis par mon routeur !
[tcpdump]
Une suggestion ?
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
Bonjour,
Bonjour,
j'ai un soucis avec un routeur sur GNU/Linux Debian Sarge (kernel 2.6.8.2) dont voici la config :
[conf]
Ce que je souhaite obtenir, c'est que mon routeur emette un message icmp redirect vers le routeur 192.168.1.250 lorsqu'un poste du réseau local accède au réseau 172.18.0.0/16 Mais pour une raison qui m'échappe, le message icmp redirect n'est pas émis par mon routeur !
[tcpdump]
Une suggestion ?
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
-- TiChou
Eric Belhomme
"TiChou" wrote in news::
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
ben non... le protocole icmp est _totalement_ non filtré sur cette
interface en input, output, et forward de eth0 vers eth0.
dans le doute j'ai même essayé en désactivant totalement le firewall (policy à ACCEPT) avec le même résultat :-/
-- Rico
"TiChou" <gro.uohcit@uohcit> wrote in
news:pwet.20050530155258@florizarre.tichou.org:
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
ben non... le protocole icmp est _totalement_ non filtré sur cette
interface en input, output, et forward de eth0 vers eth0.
dans le doute j'ai même essayé en désactivant totalement le firewall
(policy à ACCEPT) avec le même résultat :-/
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
ben non... le protocole icmp est _totalement_ non filtré sur cette
interface en input, output, et forward de eth0 vers eth0.
dans le doute j'ai même essayé en désactivant totalement le firewall (policy à ACCEPT) avec le même résultat :-/
-- Rico
TiChou
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
ben non... le protocole icmp est _totalement_ non filtré sur cette
interface en input, output, et forward de eth0 vers eth0.
dans le doute j'ai même essayé en désactivant totalement le firewall (policy à ACCEPT) avec le même résultat :-/
N'y aurait-il pas du NAT ou du MASQUERADE ?
De plus, je viens de remarquer deux choses dans la sortie de votre tcpdump. D'abord les intervalles entre chaque icmp echo sont de 1 seconde et ensuite de 1.5 secondes. Lors de ce test, la machine 172.18.100.13 répondait-elle ? Le routeur 192.168.1.250 était-il joignable ? Enfin, le plus étrange c'est que pour chaque icmp echo on ne voit trace que d'un seul paquet alors qu'on devrait voir deux paquets, le paquet entrant sur eth0 venant de 192.168.1.20 et ensuite le même paquet sortant sur eth0 renvoyé par le routeur à destination du routeur 192.168.1.250. Pourrait-on croire alors que ce dernier paquet ne soit jamais sorti ? Ou bien qu'il soit sorti sur une autre interface ? Dans ces cas soit l'IP forwarding n'est pas autorisé sur l'interface eth0, soit il existe une route résiduelle dans le cache de la table de routage (ip ro flush cache) ou soit alors le paquet a été naté.
-- TiChou
Dans le message <news:Xns96675C20CDD1Eericbelhommefreefr@212.27.42.70>,
*Eric Belhomme* tapota sur f.c.o.l.configuration :
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
ben non... le protocole icmp est _totalement_ non filtré sur cette
interface en input, output, et forward de eth0 vers eth0.
dans le doute j'ai même essayé en désactivant totalement le firewall
(policy à ACCEPT) avec le même résultat :-/
N'y aurait-il pas du NAT ou du MASQUERADE ?
De plus, je viens de remarquer deux choses dans la sortie de votre tcpdump.
D'abord les intervalles entre chaque icmp echo sont de 1 seconde et ensuite
de 1.5 secondes. Lors de ce test, la machine 172.18.100.13 répondait-elle ?
Le routeur 192.168.1.250 était-il joignable ?
Enfin, le plus étrange c'est que pour chaque icmp echo on ne voit trace que
d'un seul paquet alors qu'on devrait voir deux paquets, le paquet entrant
sur eth0 venant de 192.168.1.20 et ensuite le même paquet sortant sur eth0
renvoyé par le routeur à destination du routeur 192.168.1.250. Pourrait-on
croire alors que ce dernier paquet ne soit jamais sorti ? Ou bien qu'il soit
sorti sur une autre interface ? Dans ces cas soit l'IP forwarding n'est pas
autorisé sur l'interface eth0, soit il existe une route résiduelle dans le
cache de la table de routage (ip ro flush cache) ou soit alors le paquet a
été naté.
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
Les icmp redirect ne seraient-il pas filtrés par le firewall ?
ben non... le protocole icmp est _totalement_ non filtré sur cette
interface en input, output, et forward de eth0 vers eth0.
dans le doute j'ai même essayé en désactivant totalement le firewall (policy à ACCEPT) avec le même résultat :-/
N'y aurait-il pas du NAT ou du MASQUERADE ?
De plus, je viens de remarquer deux choses dans la sortie de votre tcpdump. D'abord les intervalles entre chaque icmp echo sont de 1 seconde et ensuite de 1.5 secondes. Lors de ce test, la machine 172.18.100.13 répondait-elle ? Le routeur 192.168.1.250 était-il joignable ? Enfin, le plus étrange c'est que pour chaque icmp echo on ne voit trace que d'un seul paquet alors qu'on devrait voir deux paquets, le paquet entrant sur eth0 venant de 192.168.1.20 et ensuite le même paquet sortant sur eth0 renvoyé par le routeur à destination du routeur 192.168.1.250. Pourrait-on croire alors que ce dernier paquet ne soit jamais sorti ? Ou bien qu'il soit sorti sur une autre interface ? Dans ces cas soit l'IP forwarding n'est pas autorisé sur l'interface eth0, soit il existe une route résiduelle dans le cache de la table de routage (ip ro flush cache) ou soit alors le paquet a été naté.
