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 ppp0=192.0.2.100 et ppp1=192.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 200Ainsi 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.