Re: Fonctionnement du routage au niveau du noyau
cedric cellier a écrit :
Avant tout, et puisque le sujet intéresse visiblement plusieurs
personnes, aurait tu des pointeurs ou des conseils de lecture (mis à
part le source lui même, qui est confus je trouve) sur ce sujet ?
Pas vraiment, non. Ce que je sais du routage dans Linux vient
essentiellement de mon expérience sur le tas, de discussions dans des
forums ou des listes de diffusion et bien sûr des quelques howto bien
connus (réseau, routage, routage avancé).
Comme certain pensent apparement que c'est idiot de vouloir relier
directement deux interfaces réseaux,
Ce n'est pas "idiot" dans l'absolu, mais la conception de la pile IP de
Linux n'a pas vraiment prévu ce cas.
voici la raison pour laquelle je
voulais faire ça moi aussi : J'ai un module qui analyse le traffic IP
d'un bridge (grace à un hook netfilter). Pour le tester, j'utilise
actuellement 3 machines : un emméteur, un récepteur, et le bridge
modifié entre les deux. Ce n'est pas très commode, surtout pour lancer
des tests automatiques (synchronisations des commandes à lancer entre
les trois machines).
Peut-être que ce n'est pas le plus commode, mais c'est le plus sûr pour
éviter les effets de bords. Ça rappelle l'histoire de quelqu'un qui
faisait avec une même machine à la fois du routage+NAT entre deux
interfaces et un pont filtrant (bridge-netfilter) entre deux autres
interfaces. Ce qu'il n'avait pas prévu, c'est que le suivi de connexion
voyait indifféremment les paquets traversant le routeur et le pont, ce
qui créait des effets de bord (ex : le NAT ne marchait pas sur les
paquets qui avaient auparavant traversé le pont) que la personne
interprétait comme une "porosité" entre les deux.
J'avais pensé à lancer le bridge dans qemu, et à
transmettre les paquets grace à deux interfaces réseaux virtuelles
(tun/tap). Il fallait donc que le kernel accepte d'envoyer des paquets
qui étaient destinés à son autre interface via le bridge dans qemu.
Malheuresement je n'y était pas arrivé, mais je vais réessayer en
masqueradant.
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adresse locale, ce qui inclut non seulement le bloc 127.0.0.0/8
mais aussi toutes les adresses des autres interfaces de la machine,
passe systématiquement par l'interface de loopback.
Y a t-il une raison à celà, à part simplifier la vie des administrateurs
réseau fainéants ?
Je pense que c'est une simple question de cohérence. Cohérence avec
l'idée que tout le trafic local, quel qu'il soit, doit être traité de la
même façon. Cohérence avec le modèle IP de Linux dans lequel les
adresses locales sont considérées comme appartenant à la machine plus
qu'à une interface particulière.
Oui, mais elle se heurte à la règle énoncée plus haut, qui a une
priorité supérieure. Cette règle est appliquée par une table de routage
spéciale appelée "local" qu'on peut afficher avec la commande suivante
(du paquet iproute) :
$ ip route list table local
Si on efface cette règle (ip route del ...), on peut alors apparement
(je viens de tester) envoyer sur une interface physique des paquets à
destination de l'interface (à condition de les envoyer depuis une
interface qui à une autre IP source, sinon l'adresse source sera égale à
l'adresse destination et apparement c'est invalide).
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
N'est-ce pas plus simple d'effacer cette règle que de masquerader les
interfaces ? Y a t-il des contre-indications ?
Si on supprime une route locale, la destination n'est plus considérée
comme locale. C'est valable en sortie mais aussi en entrée : la machine
ne peut plus émettre depuis cette adresse ni recevoir sur cette adresse.
Donc certes on peut émettre vers cette destination via une interface non
loopback, mais on ne peut plus recevoir. Opérationnellement, cela
revient plus ou moins à supprimer l'adresse de l'interface sur laquelle
elle avait été configurée. Ce qui est invalide n'est pas que l'adresse
source soit égale à l'adresse destination mais que l'adresse source ne
soit pas locale.
Chez moi (debian sarge) la table "local" s'appelle apparement table "255".
C'est son numéro, sous lequel le noyau la connaît. Celui de la table
"main" est 254. La correspondance entre les noms et les numéros des
tables de routage figure normalement dans le fichier
/etc/iproute2/rt_tables. Celui de ma Sarge, que je n'ai pas modifié,
contient ceci :
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
La première règle indique que la table "local" a la priorité la plus
haute (0). On ne peut ni la modifier ni la supprimer.
Tiens, justement (cf plus haut) j'ai réussi à la modifier...
kernel : 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux
Tu as modifié une règle ou une route ?
J'ai déjà essayé de modifier la règle de routage de priorité 0 avec
plusieurs versions de noyau, sans succès.
Reply to: