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 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
