Fonctionnement du routage au niveau du noyau

Le 13632ième jour après Epoch,
François de Beauregard écrivait:

Bonsoir,


j'aimerais connaître comment modifier le routage au
niveau du noyau dans un cas bien précis:

j'ai un SEUL ordinateur muni de deux cartes réseaux
(chacune a sa propre ligne d'interruption).
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

C'est pas forcément la meilleure idée, ça :) ... Si tu veux "jouer"
avec le routage, essaye avec 2 PC, tu pourras explorer tous les cas
possibles.

Je les relie par un RJ45.
Je souhaite envoyer un paquet d'une interface a une
autre.

Ça, ça va être chaud. Même si ils ne sont pas dans le m ême CIDR tu vas
avoir du mal à faire passer du trafic sur le câble :)

Pour palier à cela, j'utilise la commande suivante:
route add 192.168.1.1 dev eth2
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.
Malheureusement, une capture avec tcpdump me prouve
une fois encore que le paquet n'est pas réellement
émis (couche physique)

Tu as bien compris, mais en fait comme l'IP que tu pingues est "dans"
la machine, ben il va pas réveiller qui que ce soit d'autre que
loopback ;)

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.

man ip

pour faire du routage un peu plus pointu.

Si quelqu'un a une piste, par avance merci beaucoup!

Eh bien disons que dans ton cas, ça va être assez dur. Tu peux fo rcer
ping à utiliser une interface particulière (man ping / -I ), mais je
ne suis pas sûr que cela marche correctement pour toi.

Bonjour,

Pour faire des tests de cette nature et utiliser l'interface physique,
il faut sortir de la machine. Pour cela, il faut une machine externe
(éventuellement avec 2 carte réseau pour faire joujou).

Maintenant, quel résultat souhaite tu atteindre ?

Si tu veux aller plus loin dans le routage sous linux, lis de LARTC
HOWTO - routage avancé - http://lartc.org/howto/

Bonne journée.
:)

Le 29/04/07, François TOURDE<fra-duf-no-spam@tourde.org> a écrit :

Le 13632ième jour après Epoch,
François de Beauregard écrivait:

> Bonsoir,
>
>
> j'aimerais connaître comment modifier le routage au
> niveau du noyau dans un cas bien précis:
>
> j'ai un SEUL ordinateur muni de deux cartes réseaux
> (chacune a sa propre ligne d'interruption).
> 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

C'est pas forcément la meilleure idée, ça :) ... Si tu veux "jouer"
avec le routage, essaye avec 2 PC, tu pourras explorer tous les cas
possibles.

> Je les relie par un RJ45.
> Je souhaite envoyer un paquet d'une interface a une
> autre.

Ça, ça va être chaud. Même si ils ne sont pas dans le même CIDR tu vas
avoir du mal à faire passer du trafic sur le câble :)

> Pour palier à cela, j'utilise la commande suivante:
> route add 192.168.1.1 dev eth2
> 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.
> Malheureusement, une capture avec tcpdump me prouve
> une fois encore que le paquet n'est pas réellement
> émis (couche physique)

Tu as bien compris, mais en fait comme l'IP que tu pingues est "dans"
la machine, ben il va pas réveiller qui que ce soit d'autre que
loopback ;)

> 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.

man ip

pour faire du routage un peu plus pointu.

> Si quelqu'un a une piste, par avance merci beaucoup!

Eh bien disons que dans ton cas, ça va être assez dur. Tu peux forcer
ping à utiliser une interface particulière (man ping / -I ), mais je
ne suis pas sûr que cela marche correctement pour toi.

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 ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tout d'abord merci beaucoup pour ces explications sur le routage au
niveau du kernel. Comme l'OP, ce sujet m'interresse, et j'avais déjà
essayé sans succès de réaliser la même manipulation que lui (raison
donnée plus bas).

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 ?
J'ai trouvé diverses docs en ligne, j'ai parcouru divers livres
(le plus précis et complet à mon avis étant "Understanding Linux network
internals" chez O'Reilly, mais il n'est pas parfais et pas toujours
très clair), mais sans jamais trouver quelquechose de vraiment
satisfaisant...

Comme certain pensent apparement que c'est idiot de vouloir relier
directement deux interfaces réseaux, 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). 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.

-[ Sun, Apr 29, 2007 at 12:19:49PM +0200, Pascal Hambourg ]----

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.

Y a t-il une raison à celà, à part simplifier la vie des administrateurs
réseau fainéants ?

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).

N'est-ce pas plus simple d'effacer cette règle que de masquerader les
interfaces ? Y a t-il des contre-indications ?

$ ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

Chez moi (debian sarge) la table "local" s'appelle apparement table "255".

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



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-[ Mon, Apr 30, 2007 at 12:52:31PM +0200, Pascal Hambourg ]----

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.

>>$ 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...) ?

% ip route list table local
broadcast 192.168.1.0 dev eth1 proto kernel scope link src 192.168.1.68
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.168.1.68 dev eth1 proto kernel scope host src 192.168.1.68
broadcast 192.168.1.255 dev eth1 proto kernel scope link src 192.168.1.68
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

% sudo ip route del 192.168.1.68 dev eth1 table local
% ip route list table local
broadcast 192.168.1.0 dev eth1 proto kernel scope link src 192.168.1.68
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.1.255 dev eth1 proto kernel scope link src 192.168.1.68
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

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.
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 émmit, 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.

Tu as modifié une règle ou une route ?

Une route. Je m'y perd.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-[ Mon, Apr 30, 2007 at 05:09:50PM +0200, Pascal Hambourg ]----

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 ?

Oui et une partie du traffic de test est déjà constitué de traces
pcap rejouées sur une interface. Mais ça ne vaut pas un
vrai dialogue IP. A ce sujet, CPAN est une vrai mine d'or :
plein de protocoles sont implémentés en Perl, il n'y a plus qu'à
écrire 3 lignes de perl pour avoir un client ou un serveur d'un
protocole exotique :-)

A propos, je viens de tester ta méthode avec le masquerading, et
ça marche très bien. Un peu compliqué (j'ai du faire un grand schéma
avec les interfaces et toutes les IP impliquées pour m'y retrouver),
mais ça me sera très utile pour automatiser les tests. Merci beaucoup !

Quant aux explications du bien fondé des procédures de routage,
je n'ai pas d'opinion. On y verra plus clair lorsque les anciens
outils (route, ifconfig) disparaitront complètement (ou ne seront plus
que des scripts shells) au profit d'iproute.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Apr 30, 2007 at 05:09:50PM +0200, Pascal Hambourg wrote :

Salut,

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),

Ceci m'amène à me poser la question suivante: dans le cas où une
personne dispose de deux connections internet, les paquets "réponses" repassent
ils toujours par la même interface que les paquets "requetes"
correspondants ?

Oumar

--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le 13633ième jour après Epoch,
Oumar Niane écrivait:

Ceci m'amène à me poser la question suivante: dans le cas oà ¹ une
personne dispose de deux connections internet, les paquets "réponses " repassent
ils toujours par la même interface que les paquets "requetes"
correspondants ?

Si tu as iprouting, oui, ça se nomme le "source routing" il me
semble. J'avais à l'époque une "dual freebox", sur la même g amme IP,
et j'ai dû upgrader mon vieux kernel et installer iproute2 pour que
cela marche bien.

Sinon, les "réponses" sortent par l'interface prioritaire (ie celle
qui a la plus "basse" ip ou celle de la route par défaut).