[gull] IP routing
Daniel Cordey
dc at mjt.ch
Tue Jun 22 21:34:01 CEST 2004
On Tuesday 22 June 2004 21:05, Florian Salamin wrote:
> Kernel IP routing table
> Destination Gateway...
> 194.209.241.0 mjtlnx3.mjt.ch...
> 192.168.1.0 192.168.1.70 255.255.255.0 UG 0 0 0
> eth0
> 194.88.9.0 194.88.9.27...
> 192.6.1.0 mjtlnx3.hesse.m...
> link-local *...
> loopback *...
> default cisco.mjt.ch...
>
> Donc il va tenter d'atteindre la machine dont l'IP est 192.168.9.27 *via*
> eth0. Or, si j'ai bien compris, la machine B a précisément l'adress
> 192.168.9.27 qui est rattachée à son interface eth0.
Plutot que d'avoir :
192.168.1.0 * 255.255.255.0 UG 0 0 0 eth0
J'ai :
192.168.1.0 192.168.1.70 255.255.255.0 UG 0 0 0 eth0
La premiere regle de routage est celle mise pasr defaut pat 'ifconfig'. On peu
tres bien ajouter des regles. Je ne fais que preciser que le gateway est uen
adresse. Il est vrai que cela va engendrer un nouvel examen da la table de
routage. Orm en faisant ceci, j'essayais de traiter un ping issu de B comme
ceux issus des autres systemes. Je pensais qu'alors les pings de B seraient
aussi bloques. Ce n'est pas le cas... j'en deduis donc qu'il s'agit bien d'un
probleme de forwarding et non de routage ou de firewall cache.
Mais la machine B a l'adresse 192.168.1.70.
Si je recois de C (disons 194.88.9.10) un ping pour 192.168.10, je recevrai la
requete a l'adresse 194.88.9.27. Le paquet sera examine et la table de
routage permettra de determiner que cela concerne le reseau 192.168.0
(masque). Ce qui implique un envoi au gateway 192.168.1.70... nouvel examen
du paquet qui doit determiner que celui-ci doit partir par l'interface eth0.
tcpdump me laisse suspecter que le paquet arrive bien sur eth0, mais il n'en
rapart pas.
Tout compte fait, que j'utilise la premiere notation (ifconfig) ou la
definition explicite de l'interface comme gateway... le resultat est le meme.
> De ce fait, le paquet
> revient sur la machine B, recherche une règle de routage pour atteindre C
> etc... et effectue ainsi une boucle qui l'empêche de sortir via eth0 et
> d'atteindre C.
Non, on devrait meme pouvoir utiliser des alias IP d'un interface comme
gateway.
Ce qui me chicane, c'est le fait de n'avoir quasi aucun outil d'investigation.
Tout ce passe dans le kernel et la seule possibilite qui me reste (il me
semble, mais bon...) est de loguer le POSTROUTING sur cette carte. Je l'ai
fait aec le PREROUTING et je vois bien arriver les paquets. Mais si les
paquets disparaissent entre-deux, j'en suis pour ma pomme :-(
Daniel
More information about the gull
mailing list