[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