Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Fonctionnement du routage au niveau du noyau

Fonctionnement du routage au niveau du noyau

20 réponses
Avatar
François de Beauregard
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

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

Si je fais un ping 192.168.1.1, cela revient a
"s'autopinger" l'interface eth1: le paquet ne fait que
descendre a moitie la pile et la remonte.

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

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

D'apres
http://kernelnewbies.org/Documents/LinuxIPNetworking,
il semble toutefois possible de modifier ce routage,
chapitre 7.2.3. Examining a Packet in IP et notamment:
ip_route_input() - net/ipv4/route.c (1366)
calls rt_hash_code() to get index for routing table
loops through routing table (starting at hash) to
find match for packet
if it finds match:
updates stats for route (time and usage)
sets packet destination to routing table entry
returns success
else
checks for multicasting addresses
returns result of ip_route_input_slow() (attempted
routing)
Maintenant en regardant les sources, je ne comprends
pas grand chose aux tables de routage, et surtout
comment interagir dessus pour avoir le résultat
escompte !

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


Bonne soiree.

Debianement,



François de Beauregard



___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com


--
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
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Pascal Hambourg
cedric cellier a écrit :

A propos, je viens de tester ta méthode avec le masquerading, et
ça marche très bien.



Y a intérêt. J'avais vérifié.
Un bémol toutefois, la méthode a les faiblesses inhérentes au NAT : ça
ne marche pas avec certains protocoles "réfractaires" non pris en charge
par un helper dédié.

Un peu compliqué (j'ai du faire un grand schéma
avec les interfaces et toutes les IP impliquées pour m'y retrouver),



Ben ouais, pareil pour moi. Il faut que je visualise.

mais ça me sera très utile pour automatiser les tests. Merci beaucoup !



De rien. Les trucs tordus avec du routage et du NAT, c'est mon dada. ;-)


--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
Pascal Hambourg
François TOURDE a écrit :
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 ?





Ça dépend s'il s'agit de requêtes entrantes et donc de réponses
sortantes ou bien de requêtes sortantes et de réponses entrantes.

Dans le premier cas, les réponses sortantes sont routées selon les
règles de routage de la machine, comme toujours. Et sans règles
explicites de routage avancé, rien ne force le routage à être
symétrique. Chaque paquet est routé individuellement. Donc s'il n'y a
que du routage simple avec une route par défaut via une des interfaces,
tous les paquets sortants passent par elle. Et s'il y a deux routes par
défaut, ça ne change rien parce qu'une seule est active de toute façon.
Ne comptez pas sur le routage pour décider tout seul quelle route par
défaut serait la plus appropriée ! En revanche le routage avancé peut
servir à router un paquet en fonction de son adresse source ou d'autres
de ses caractéristiques (protocole, port source ou destination, TOS...),
éventuellement en conjonction avec la cible MARK d'iptables. Router une
réponse par l'interface par laquelle la requête est arrivée n'est pas
trivial : il ne suffit pas forcément de router en fonction de l'adresse
source, car dans l'absolu la requête peut arriver par une interface mais
être destinée à l'adresse configurée sur une autre interface. Une
solution consiste à utiliser le suivi de connexion d'iptables avec le
couple CONNMARK/connmark.

Dans le second cas, les réponses qui reviennent sont routées par
l'extérieur en fonction de leur adresse destination, et donc arrivent
généralement sur l'interface qui a cette adresse. Ce qui ne veut pas
dire qu'elles repassent par la même interface que les requêtes, car ces
dernières ont très bien pu être émises par l'autre interface, si le lien
amont (en clair : le FAI) le permet. ;-)

Si tu as iprouting, oui, ça se nomme le "source routing" il me
semble.



Je suppose que tu veux parler de "politique de routage basée sur
l'adresse source" (source based routing policy). A ne pas confondre avec
le "routage source" (source routing), qui n'a rien à voir et qui est une
option du protocole IP permettant à l'émetteur d'un paquet de spécifier
dans celui-ci des instructions de routage destinées aux routeurs qui
seront chargés de router le paquet. Cette option est ignorée par la
majorité des routeurs d'internet, notamment pour éviter les abus.


--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
fra-duf-no-spam
Le 13634ième jour après Epoch,
Pascal Hambourg écrivait:

François TOURDE a écrit :

Si tu as iprouting, oui, ça se nomme le "source routing" il me
semble.



Je suppose que tu veux parler de "politique de routage basée sur
l'adresse source" (source based routing policy). A ne pas confondre
avec le "routage source" (source routing), qui n'a rien à voir et qui
est une option du protocole IP permettant à l'émetteur d'un paq uet de
spécifier dans celui-ci des instructions de routage destinées a ux
routeurs qui seront chargés de router le paquet. Cette option est
ignorée par la majorité des routeurs d'internet, notamment pour éviter
les abus.



J'avoue que je ne me suis jamais vraiment penché sur le problème,
autrement qu'en installant iproute2 :)

Je ne sais pas vraiment comment ça marche (et ce n'est pas mon souci
pour le moment ^^), mais j'ai observé que quand j'ai eu la double
liaison FAI, les réponses aux PING ne marchaient correctement que
quand je les recevais par l'interface définie par défaut dans ma table
de routage barbare :)

Mes soucis se sont résolus après l'utilisation de l'iprouting,
permettant (je ne sais pas comment) de répondre à un paquet au tr avers
de l'interface ayant reçu la requête.

C'est pour cela que j'ai utilisé l'expression "source routing", et je
m'en excuse si elle a pû prêter à confusion ou erreur. Je su is
d'ailleurs preneur d'explications sur ce mécanisme ...
Avatar
Pascal Hambourg
François TOURDE a écrit :

Je ne sais pas vraiment comment ça marche (et ce n'est pas mon souci
pour le moment ^^), mais j'ai observé que quand j'ai eu la double
liaison FAI, les réponses aux PING ne marchaient correctement que
quand je les recevais par l'interface définie par défaut dans ma table
de routage barbare :)



Quand tu recevais quoi par l'interface de la route par défaut ? Les
pings ou les réponses au ping ?

Un problème courant avec le routage avancé ou lorsqu'on a plusieurs
liens vers internet est la validation d'adresse source des paquets reçus
par vérification du chemin inverse, contrôlée pour chaque interface par
le paramètre du noyau /proc/sys/net/ipv4/conf/<interface>/rp_filter.
Dans Debian, une option du fichier /etc/network/options, maintenant
déclaré obsolète, permet d'activer ce réglage au démarrage. Lorsque ce
paramètre est activé pour une interface, le noyau jette un paquet
entrant par une interface avec une adresse source donnée s'il n'aurait
pas routé un paquet vers cette adresse via la même interface. L'ennui,
c'est que cette vérification ne prend pas en compte le routage avancé.
Cela peut expliquer que les paquets entrants n'étaient acceptés que
lorsqu'ils arrivaient par l'interface de la route par défaut.

Un autre problème potentiel lorsqu'on a plusieurs liens est le filtrage
d'adresse source des paquets sortants qui peut être effectué par les
opérateurs des liens (les FAI). Ta machine a deux liens avec deux
adresses IP, et en théorie rien n'interdit d'émettre des paquets sur un
lien avec l'adresse IP de l'autre. Mais en pratique il arrive que les
FAI bloquent ces paquets pour éviter les attaques avec usurpation
d'adresse IP source (IP spoofing). Ce filtrage du FAI a le même effet
que rp_filter, mais en sortie cette fois. Le routage avancé permet de
forcer le routage par le lien correspondant à l'adresse source.

Mes soucis se sont résolus après l'utilisation de l'iprouting,
permettant (je ne sais pas comment) de répondre à un paquet au travers
de l'interface ayant reçu la requête.



Je soupçonne que cela permettait plutôt d'envoyer un paquet par
l'interface en fonction de son adresse source, ce qui est légèrement
différent dans l'absolu. C'est beaucoup plus facile que de router la
réponse par l'interface ayant reçu la requête.

C'est pour cela que j'ai utilisé l'expression "source routing", et je
m'en excuse si elle a pû prêter à confusion ou erreur.



Bah, c'est une confusion courante parce que d'une part presque personne
ne connaît l'existence de l'option "source routing" du protocole IP
étant donné sa faible utilisation, et d'autre part "source based routing
policy" ça fait vachement long pour des feignasses d'unixiens habitués
aux sigles à 3 ou 4 lettres et aux commandes à 2 lettres. ;-) Alors on a
facilement la tentation d'abréger en "source routing", sans savoir que
ça désigne déjà autre chose.

Je suis d'ailleurs preneur d'explications sur ce mécanisme ...



Quel mécanisme ? L'option "source routing" du protocole IP ou le routage
avancé basé sur l'adresse source de 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
with a subject of "unsubscribe". Trouble? Contact
Avatar
fra-duf-no-spam
Le 13634ième jour après Epoch,
Pascal Hambourg écrivait:

François TOURDE a écrit :

Je ne sais pas vraiment comment ça marche (et ce n'est pas mon souci
pour le moment ^^), mais j'ai observé que quand j'ai eu la double
liaison FAI, les réponses aux PING ne marchaient correctement que
quand je les recevais par l'interface définie par défaut dans ma table
de routage barbare :)



Quand tu recevais quoi par l'interface de la route par défaut ? Les
pings ou les réponses au ping ?



Pardon, c'est encore confus :) ... En fait, quand mon serveur (dual
FAI) recevait un PING, il répondait systématiquement par l'interf ace
par défaut (A). Du coup, depuis l'extérieur, quand on PINGais mon serveur
sur son adresse A ça marchait, mais sur son adresse B les réponses
venaient de A donc n'étaient pas prises en compte.

[...]
Cela peut
expliquer que les paquets entrants n'étaient acceptés que lorsq u'ils
arrivaient par l'interface de la route par défaut.



Non non, les paquets arrivaient (tcpdump), mais les réponses étai ent
mal émises il me semble.


Je suis d'ailleurs preneur d'explications sur ce mécanisme ...



Quel mécanisme ? L'option "source routing" du protocole IP ou le
routage avancé basé sur l'adresse source de Linux ?



Eh bien... Les deux? :) ... En fait, ce que je ne comprends pas, c'est
pourquoi et surtout comment les ECHO REPLY étaient bien routées p ar
l'interface qui avait reçu l'ECHO REQUEST.

Mais bon, c'est pas si important pour moi, je n'ai plus qu'une seule
liaison ;)
Avatar
Pascal Hambourg
François TOURDE a écrit :

Pardon, c'est encore confus :) ... En fait, quand mon serveur (dual
FAI) recevait un PING, il répondait systématiquement par l'interface
par défaut (A).



Comportement normal par défaut en l'absence de routage avancé.

Du coup, depuis l'extérieur, quand on PINGais mon serveur
sur son adresse A ça marchait, mais sur son adresse B les réponses
venaient de A donc n'étaient pas prises en compte.



Tu veux dire que les réponses venaient de l'interface A (normal) ou de
l'adresse A (surprenant) ?
Et qu'entends-tu par "pas prises en compte" ?
J'y pense... le serveur était-il connecté directement aux deux liens
internet avec des adresses publiques sur ses interfaces ou bien par
l'intermédiaire de routeurs avec NAT ?

Je suis d'ailleurs preneur d'explications sur ce mécanisme ...



Quel mécanisme ? L'option "source routing" du protocole IP ou le
routage avancé basé sur l'adresse source de Linux ?



Eh bien... Les deux? :)



Pour l'option de source routing d'IP, désolé mais il va falloir trouver
quelqu'un d'autre car je n'en sais pas plus que ce que j'ai déjà écrit.

En fait, ce que je ne comprends pas, c'est
pourquoi et surtout comment les ECHO REPLY étaient bien routées par
l'interface qui avait reçu l'ECHO REQUEST.



Si on suppose que les paquets arrivent par l'interface correspondant à
l'adresse de destination, le principe consiste à créer des règles de
routage (ip rule add) qui aiguillent vers des tables de routage
spécifiques en fonction de l'adresse IP source du paquet à router. Dans
ces tables, on crée une route par défaut (ip route add) qui passe par
l'interface souhaitée.

Exemple avec ppp02.0.2.100 et ppp12.0.2.200 :

ip rule add from 192.0.2.100 lookup 100
ip route add default dev ppp0 table 100
ip rule add from 192.0.2.200 lookup 200
ip route add default dev ppp1 table 200

Ainsi un paquet émis avec l'adresse source 192.0.2.100 est routé par
l'interface ppp0 et un paquet émis avec l'adresse source 192.0.2.200 est
routé par l'interface ppp1.


--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
fra-duf-no-spam
Le 13634ième jour après Epoch,
Pascal Hambourg écrivait:

François TOURDE a écrit :

Pardon, c'est encore confus :) ... En fait, quand mon serveur (dual
FAI) recevait un PING, il répondait systématiquement par l'int erface
par défaut (A).



Comportement normal par défaut en l'absence de routage avancé.



Oui oui, ça je savais :)

Du coup, depuis l'extérieur, quand on PINGais mon serveur
sur son adresse A ça marchait, mais sur son adresse B les répo nses
venaient de A donc n'étaient pas prises en compte.



Tu veux dire que les réponses venaient de l'interface A (normal) ou de
l'adresse A (surprenant) ?



Euh.... Je me souviens plus... Trop vieux comme tests. Il me semble
que ça venait de l'adresse B (normal), mais sortant par l'interface A,
donc rejeté par le kernel ou le FAI, je sais plus.

Et qu'entends-tu par "pas prises en compte" ?



voir réponse précédente.

J'y pense... le serveur était-il connecté directement aux deux liens
internet avec des adresses publiques sur ses interfaces ou bien par
l'intermédiaire de routeurs avec NAT ?



En direct, les IP sur les interfaces.

En fait, ce que je ne comprends pas, c'est
pourquoi et surtout comment les ECHO REPLY étaient bien routée s par
l'interface qui avait reçu l'ECHO REQUEST.



Si on suppose que les paquets arrivent par l'interface correspondant à  
l'adresse de destination, le principe consiste à créer des rà ¨gles de
routage (ip rule add) qui aiguillent vers des tables de routage
spécifiques en fonction de l'adresse IP source du paquet à
router. Dans ces tables, on crée une route par défaut (ip route add)
qui passe par l'interface souhaitée.

Exemple avec ppp02.0.2.100 et ppp12.0.2.200 :

ip rule add from 192.0.2.100 lookup 100
ip route add default dev ppp0 table 100
ip rule add from 192.0.2.200 lookup 200
ip route add default dev ppp1 table 200

Ainsi un paquet émis avec l'adresse source 192.0.2.100 est routà © par
l'interface ppp0 et un paquet émis avec l'adresse source 192.0.2.200
est routé par l'interface ppp1.



Tu veux parler de routes dynamiques? On reçoit sur l'IF A un paquet
venant de IP1, donc une route vers IP1 est créée via IF A ?

Mais alors que se passe-t-il si on reçoit de IP1 un paquet sur IF A
puis sur IF B ?
Avatar
mouss
cedric cellier wrote:
[snip]

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




pour comprendre le fonctionnement du stack, le meilleur booquin est
"TCP/IP Illustrated" Volume 2 (Par Wright et Stevens). le stack décrit
est celui de BSD (de l'époque), mais comme ce stack est à l'origine des
nombreuses implémentations, ça peut aider de le comprendre. cela dit, il
faut comprendre le C. sinon, faut regarder le volume 1.
[snip]

-[ 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 ?




il faut se rappeler qu'en principe, un paquet est envoyé à une IP, pas à
une interface. lorsque le système reçoit un paquet il cherche à voir
s'il doit le passer à un process ou s'il doit le forwarder à un autre
système. et cette décision est faite en vérifiant si l'IP appartient au
système.

Dans ton cas, il y a physiquement 2 chemins pour atteindre une IP: un
chemin simple, interne au système, et un chemin alambiqué, qui consiste
à envoyer le paquet sur le réseau et attendre qu'il soit reçu de l'autre
coté du système. pourquoi voudrais-tu que le système utilise ce dernier
chemin?

Il ne faut pas oublier qu'un process de la machine peut envoyer des
paquets à une IP de la machine (par exemple si on bind un named ou un
postfix ou un apache à une IP, ...). et la, il est hors de question que
le paquet sorte de la machine!



--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
mouss
Pascal Hambourg wrote:
François TOURDE a écrit :

Pardon, c'est encore confus :) ... En fait, quand mon serveur (dual
FAI) recevait un PING, il répondait systématiquement par l'interface
par défaut (A).



Comportement normal par défaut en l'absence de routage avancé.

Du coup, depuis l'extérieur, quand on PINGais mon serveur
sur son adresse A ça marchait, mais sur son adresse B les réponses
venaient de A donc n'étaient pas prises en compte.



Tu veux dire que les réponses venaient de l'interface A (normal) ou de
l'adresse A (surprenant) ?
Et qu'entends-tu par "pas prises en compte" ?



il a peut-etre fait des tests avec un client windows. celui-ci est
capricieux...
J'y pense... le serveur était-il connecté directement aux deux liens
internet avec des adresses publiques sur ses interfaces ou bien par
l'intermédiaire de routeurs avec NAT ?

Je suis d'ailleurs preneur d'explications sur ce mécanisme ...



Quel mécanisme ? L'option "source routing" du protocole IP ou le
routage avancé basé sur l'adresse source de Linux ?



Eh bien... Les deux? :)



Pour l'option de source routing d'IP, désolé mais il va falloir
trouver quelqu'un d'autre car je n'en sais pas plus que ce que j'ai
déjà écrit.



dans un packet IP, on peut mettre une liste de "hops" que le paquet
devrait suivre jusqu'à sa destination. il y a deux modes: un mode strict
(SSR pour strict source route) et un mode faible (LSR pour lose source
route). dans le mode strict, on ne peut pas passer le paquet à une
machine qui n'est pas dans la liste (sauf la destination). autrement
dit, la liste définit le chemin exact du paquet. alors que le mode
"lose" donne des étapes.

Cela introduit malheureusement des problèmes de sécurité: un attaquant
ferait passer un paquet par une machine à laquelle il n'a pas le droit.
le but peut-etre d'échaper à des règles de firewall (la machine
destination accepte tous les paquets venant d'une interface), de se
connecter sur la machine intermédiaire (si on sait qu'elle "absorbe" les
paquets), d'attaquer cette machine (attaque du stack ip d'une machine
windows par exemple), ou de récupérer des informations en analysant le
flux (ralentissements, traces, ... ou simplement en recuperant les
erreurs icmp à des paquets dont le TTL est choisi pour s'arreter à la
dite machine).



En fait, ce que je ne comprends pas, c'est
pourquoi et surtout comment les ECHO REPLY étaient bien routées par
l'interface qui avait reçu l'ECHO REQUEST.



Si on suppose que les paquets arrivent par l'interface correspondant à
l'adresse de destination, le principe consiste à créer des règles de
routage (ip rule add) qui aiguillent vers des tables de routage
spécifiques en fonction de l'adresse IP source du paquet à router.
Dans ces tables, on crée une route par défaut (ip route add) qui passe
par l'interface souhaitée.

Exemple avec ppp02.0.2.100 et ppp12.0.2.200 :

ip rule add from 192.0.2.100 lookup 100
ip route add default dev ppp0 table 100
ip rule add from 192.0.2.200 lookup 200
ip route add default dev ppp1 table 200

Ainsi un paquet émis avec l'adresse source 192.0.2.100 est routé par
l'interface ppp0 et un paquet émis avec l'adresse source 192.0.2.200
est routé par l'interface ppp1.






--
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
with a subject of "unsubscribe". Trouble? Contact
Avatar
fra-duf-no-spam
Le 13634ième jour après Epoch,
écrivait:

Pascal Hambourg wrote:
François TOURDE a écrit :

Pardon, c'est encore confus :) ... En fait, quand mon serveur (dual
FAI) recevait un PING, il répondait systématiquement par l'in terface
par défaut (A).



Comportement normal par défaut en l'absence de routage avancé.

Du coup, depuis l'extérieur, quand on PINGais mon serveur
sur son adresse A ça marchait, mais sur son adresse B les rép onses
venaient de A donc n'étaient pas prises en compte.



Tu veux dire que les réponses venaient de l'interface A (normal) ou
de l'adresse A (surprenant) ?
Et qu'entends-tu par "pas prises en compte" ?



il a peut-etre fait des tests avec un client windows. celui-ci est
capricieux...



Jamais de la vie voyons! Pas de Windows chez moi ;)
1 2