Re: Fonctionnement du routage au niveau du noyau
Salut,
François de Beauregard a écrit :
j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:
Pas besoin de préciser "au niveau du noyau", le routage est toujours
effectué dans le noyau.
j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
Sa propre IRQ ? Aucune importance.
Chacune des deux cartes réseaux appartient au même
réseau.
Par exemple:
eth1 192.168.1.1 255.255.255.0
eth2 192.168.1.2 255.255.255.0
Mauvaise idée en général. La table de routage se retrouve avec deux
routes contradictoires (même destination mais interface différente).
Je les relie par un RJ45.
Encore une mauvaise idée.
Je souhaite envoyer un paquet d'une interface a une
autre.
Je te vois venir, mais tu ne peux pas. Ça ne marche pas comme ça.
Si je fais un ping 192.168.1.1, cela revient a
"s'autopinger" l'interface eth1
Non, ça revient à pinguer l'interface de loopback, lo. Tu peux le
vérifier en observant que ce sont les compteurs de paquets émis et reçus
de l'interface lo qui s'incrémentent. Ou bien en désactivant ou en
bloquant le trafic sur lo et en constantant que le ping ne passe plus.
Règle : dans Linux, le trafic émis localement à destination de n'importe
quelle adrese 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.
Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
Ça ne marchera pas.
Cela précise au noyau, aussi loin que je comprenne,
d'envoyer tous les paquets, dont la destination est
192.168.1.1, en utilisant l'interface eth2.
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
Les routes qui commencent par le type "local" indiquent que la
destination est locale. Il y en a une pour chaque adresse de la machine.
Les routes de type broadcast indiquent que la destination est un
broadcast. Les destinations broadcast sont dans cette table parce que
d'une certaine façon elles sont aussi locales : le trafic émis à
destination d'une adresse broadcast est aussi rebouclé en local, et le
trafic reçu à destination d'une adresse broadcast est considéré comme
destiné à la machine.
Note : l'interface mentionnée dans les routes locales n'indique pas
l'interface de sortie mais juste à quelle interface est liée une
destination, notamment afin de la désactiver ou de la supprimer en même
temps que cette interface.
Le fait que la table de routage "local" soit prioritaire est dû aux
règles de routage, qu'on peut afficher avec la commande suivante :
$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
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. La table "main",
qui est la table normale dans laquelle on met les routes externes et
qu'on manipule avec la commande "route", a une priorité moins haute (32766).
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)
Il est émis sur l'interface de loopback, conformément aux règles et
tables de routage. "tcpdump -i lo" le montrera.
Supprimer aussi les routes crées automatiquement lors
du démarrage des interfaces
(192.168.1.0 0.0.0.0 255.255.255.0 U
0 0 0 eth1 par ex) ne change rien.
Bien sûr que non. Ces routes ne concernent pas les destinations locales.
Je pense que le noyau se rend compte que la route la
plus courte est d'utiliser eth2 pour émettre ce
paquet(l'ip de destination est celle de l'interface).
Le noyau ne se rend compte de rien. Il suit bêtement les règles de
routage et routes qu'il a.
Si tu veux envoyer du trafic sur une interface physique, il ne faut pas
que la destination soit locale. Même le routage avancé (utilisation de
règles et de tables de routage supplémentaires) ne peut rien contre ça,
à cause de la priorité de la table "local".
Quel est le but ultime de la manoeuvre ?
Reply to: