Re: Fonctionnement du routage au niveau du noyau
cedric cellier a écrit :
Pourquoi pas plutôt deux machines virtuelles pour simuler l'émetteur et
le récepteur, en laissant le pont dans la machine hôte ?
Parceque c'est plus facile de vérifier ce qu'on a reçu en fonction de ce
qu'on a envoyé si c'est la même machine qui envoit et qui reçoit.
Certes. As-tu envisagé l'utilisation d'un générateur de paquets
arbitraires et d'un programme de capture de trafic afin de
court-circuiter la pile IP et ses limitations ?
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 [...]
Quelle règle ? Tu parles de *règle* de routage (ip rule...) ou de
*route* (ip route...) ?
[...]
% sudo ip route del 192.168.1.68 dev eth1 table local
D'accord, tu parles bien d'une route dans la table "local".
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.
C'est génant, en effet.
Mais c'est cohérent.
Ce qui me gène aussi, c'est que cette table de "routage" soit consultée
pour vérifier l'adresse source d'un paquet émis, et qu'elle soit
consultée lorsqu'on reçoit un paquet ; alors qu'a priori ça devrait être
l'adresse de l'interface l'information pertinante dans ce cas. Je trouve
ce design suspect.
Je peux le comprendre. On a d'un côté la configuration IP des interfaces
qui est sans effet opérationnel direct sur les décisions de routage (au
sens large), et de l'autre côté des routes locales et broadcast cachées
qui elles influent directement sur les décisions de routage. Bien sûr
ces routes cachées découlent automatiquement de la configuration IP des
interfaces, sauf intervention manuelle avec "ip route". A propos
d'intervention manuelle, il est amusant de remarquer que si on crée une
route locale vers une adresse IP à la main, cette adresse fonctionnera
quasiment comme si elle avait été configurée sur une interface : on peut
créer des sockets, émettre et recevoir du trafic avec cette adresse.
Alors, pourquoi ce détour par des routes locales et broadcast cachées
plutôt qu'utiliser directement la configuration IP des interfaces ? Je
ne prétends répondre à la place des concepteurs de la pile IP de Linux,
mais voici mes réponses.
Le premier avantage est la rationalisation du processus de routage, qui
consiste essentiellement à répondre aux questions suivantes (aussi bien
en entrée qu'en sortie) :
- le paquet m'est-il destiné ou est-il destiné à une autre machine ?
- s'il est destiné à une autre machine quelle est l'interface de sortie
et éventuellement la passerelle à utiliser ?
- si le paquet est émis par un processus local qui n'a pas fixé
d'adresse source, laquelle choisir ?
Avec ce système, lorsqu'un paquet est reçu ou doit être émis, il suffit
de consulter les règles et tables de routage. Pas besoin de regarder
ailleurs pour savoir si la destination est locale, si la source est
valide, quelle adresse source par défaut choisir, etc. Toutes ces
informations sont dans les routes. Une application intéressante est le
cas particulier de la plage d'adresses 127.0.0.0/8 réservée au loopback.
Comment indiquer au système que cette plage est locale, alors que seule
l'adresse 127.0.0.1 est configurée sur l'interface lo, le reste étant vu
comme un sous-réseau ? La création dans la table de routage principale
d'une route directe vers 127.0.0.0/8 passant par l'interface lo est sans
effet (c'est d'ailleurs pour cela que cette route, qui n'a rien à faire
dans la table principale, n'existe pas dans Debian, contrairement à
d'autres distributions). Par contre la création d'une route locale dans
la table de routage locale résoud le problème sans avoir besoin de
traiter cette plage d'adresses ni l'interface de loopback de façon
spécifique.
Le second avantage est la souplesse. Comme on l'a vu, on peut ainsi
ajouter des adresses locales ou broadcast sans qu'elles soient forcément
liées à des adresses ou des sous-réseaux liés à des interfaces.
Quant au placement des routes locales et broadcast dans une table
spéciale, j'y vois encore deux justifications. Une est de "cacher" ces
routes qui ne sont pas censées être manipulées directement et dont
l'affichage pourrait nuire à la lisibilité de la table de routage
principale (cf. la table de routage d'un Windows par exemple). Certes,
on pourrait se contenter de ne pas les afficher. L'autre justification
est liée au routage avancé avec tables multiples, qui consiste à router
les paquets selon d'autres tables de routage que la table principale. Le
placement des routes locales et broadcast dans une table de priorité
maximum permet de ne pas avoir à s'en préoccuper, car ainsi elles ne
peuvent pas être perturbées par des règles de routage avancé. Le revers
de la médaille, c'est quand justement on veut altérer le routage d'une
destination locale. Mais c'est une situation relativement rare.
Reply to: