routeur Internet avec de multiples passerelles, et collision d'IP

Le
Eric Belhomme
Bonjour,

Soit un routeur sous Linux, connecté à de multiples FAIs. Disons pour
simplifier une liaison pro (SDSL) pour le backbone IT, et une liaison ADSL
grand public (Free.fr) pour le confort des utilisateurs pour le surf.

La FreeBox est en mode bridge ethernet, j'ai donc sur mon routeur les
interfaces idoines configurées avec des IP publiques.
Je passe les détails de policy-routing pour aiguiller les flux. Il s'agit
simplement de marquer les paquets, et de rajouter des règles iproute pour
utiliser différentes tables de routage

Problème : ce routeur fait par ailleurs office de passerelle VPN (via la
liaison SDSL), or, un de mes utilisateurs a la mauvaise idée d'habiter
très près de son lieu de travail et d'être chez Free, et il semble qu'il
soit connecté sur le même DSLAM que ma FB.
Ce ne serait pas grave, sauf que FB pousse via DHCP un masque réseau
en /24, du coup l'IP publique de mon utilisateur se trouve sur le même
réseau que moi !

J'ai donc une connexion qui entre via le FAI pro, mais qui, du fait de la
table de routage, tente de sortir via Free, bref, ça ne marche pas

Quelle est selon vous la solution la plus propre pour résoudre ce
problème ?

Merci,

--
Rico
Moi, les films de cul, j'aime bien me les faire dans une grande salle.
-+- Dominique Farrugia -+-
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Eric Belhomme
Le #23154491
Le Thu, 24 Feb 2011 17:18:19 +0000, Eric Belhomme a écrit :

Quelle est selon vous la solution la plus propre pour résoudre ce
problème ?



Je me réponds à moi-même : faute de mieux, j'ai retiré la route de lien
local dans la table "main". C'est un peu violent, mais comme ça les
processus locaux n'en tiennent pas compte !

--
Rico
On ne voit bien qu'avec le coeur. L'essentiel est invisible pour les
yeux.
-+- Antoine de Saint-Exupéry (1900-1944) -+-
Pascal Hambourg
Le #23154631
Salut,

Eric Belhomme a écrit :

Soit un routeur sous Linux, connecté à de multiples FAIs. Disons pour
simplifier une liaison pro (SDSL) pour le backbone IT, et une liaison ADSL
grand public (Free.fr) pour le confort des utilisateurs pour le surf.

La FreeBox est en mode bridge ethernet,



Pas exactement, mais peu importe.

j'ai donc sur mon routeur les
interfaces idoines configurées avec des IP publiques.
Je passe les détails de policy-routing pour aiguiller les flux. Il s'agit
simplement de marquer les paquets, et de rajouter des règles iproute pour
utiliser différentes tables de routage...

Problème : ce routeur fait par ailleurs office de passerelle VPN (via la
liaison SDSL), or, un de mes utilisateurs a la mauvaise idée d'habiter
très près de son lieu de travail et d'être chez Free, et il semble qu'il
soit connecté sur le même DSLAM que ma FB.
Ce ne serait pas grave, sauf que FB pousse via DHCP un masque réseau
en /24, du coup l'IP publique de mon utilisateur se trouve sur le même
réseau que moi !

J'ai donc une connexion qui entre via le FAI pro, mais qui, du fait de la
table de routage, tente de sortir via Free, bref, ça ne marche pas...

Quelle est selon vous la solution la plus propre pour résoudre ce
problème ?



En tenir compte dans la politique de routage, non ? Je ne comprends pas
trop le problème en fait.

Je me réponds à moi-même : faute de mieux, j'ai retiré la route de lien
local dans la table "main".



La route de lien local ? La route directe vers le /24 du DSLAM, tu veux
dire ?
Dominique ROUSSEAU
Le #23155261
Le jeu, 24 fév 2011 at 17:18 GMT, Eric Belhomme
J'ai donc une connexion qui entre via le FAI pro, mais qui, du fait de la
table de routage, tente de sortir via Free, bref, ça ne marche pas...

Quelle est selon vous la solution la plus propre pour résoudre ce
problème ?



echo 0 > /proc/sys/net/ipv4/conf/<interface>/rp_filter

(sauf si tu veux vraiment pas, non non, que ça sorte via la freebox)
Pascal Hambourg
Le #23155251
Dominique ROUSSEAU a écrit :

echo 0 > /proc/sys/net/ipv4/conf/<interface>/rp_filter

(sauf si tu veux vraiment pas, non non, que ça sorte via la freebox)



rp_filter empêche d'entrer, pas de sortir.
Eric Belhomme
Le #23156591
Le Thu, 24 Feb 2011 19:33:37 +0100, Pascal Hambourg a écrit :

En tenir compte dans la politique de routage, non ? Je ne comprends pas
trop le problème en fait.



le probleme, c'est que le paquet est à destination d'un processus local,
donc j'ai beau tagger mon paquet, je n'ai aucun moyen de le faire passer
par une table de routage autre que la table "main" avant que la décision
de routage ne soit prise (ni après d'ailleurs), ce qui me force à
supprimer la route de lien local de la table main pour l'interface reliée
à la FB.

Dans mon cas particilier, ça ne gène pas outre mesure, mais dans
l'absolu, ça pourrait : genre je veux vérifier que la passerelle de Free
est bien là, je pourrai pas la pinger, puisque je n'ai plus de route pour
y aller dans la table main

--
Rico
L'argent ne fait pas le bonheur... de celui qui m'en a prêté !
-+- Pierre Perret -+-
Eric Belhomme
Le #23163241
Le Fri, 25 Feb 2011 16:48:02 +0100, Pascal Hambourg a écrit :

Plutôt la table "local" si c'est un paquet entrant à destination d'un
processus local. Cette table étant prioritaire, le routage des
destinations locales et broadcast ne peut effectivement être altéré par
le marquage de paquet.




Je ne savais pas que la table local etait prioritaire, merci pour cette
info !

Mais je comprends de moins en moins. Ceci concerne les paquets entrants,
or dans le premier article il était plutôt question de paquets sortants
routés vers la "mauvaise" interface.

C'est quel type de VPN ?



Je vais tacher d'être plus clair :

Soit un serveur OpenVPN en écoute sur mes interfaces (toutes, car les
connexions VPN peuvent *aussi* venir des réseaux protégés)

Depuis Internet, la connexion se fait via la liaison SDSL pro. On parle
donc de paquets entrants à destination d'un processus local.


Si par "route de lien local" tu veux dire la route directe vers le
sous-réseau Freebox (ce n'est pas la même chose, pour moi "lien local"
désigne la plage 169.254.0.0/16 en IPv4 et fe80::/10 en IPv6), alors



oui, c'est ce que je voulais dire, merci de m'avoir repris

effectivement la supprimer rend l'adresse du DSLAM injoignable via la
Freebox. Ce qui est (faussement) paradoxal puisque c'est cette adresse
qui sert de passerelle pour les communications sortant par la Freebox.
Mais en fait cela devrait être simple à réparer : il devrait suffire de
remplacer la route directe de sous-réseau a.b.c.0/24 par une route
directe d'hôte a.b.c.254/32.



Merde ! comment j'ai fait pour ne pas y penser tout seul ? C'est sans
doute effectivement la solution la plus propre ! Merci :)

--
Rico
Femme tentée et femme vaincue, c'est un tout.
-+- Marivaux -+-
Publicité
Poster une réponse
Anonyme