routeur Internet avec de multiples passerelles, et collision d'IP
6 réponses
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 -+-
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
Eric Belhomme
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) -+-
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) -+-
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
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 ?
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 ?
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 jeu, 24 fév 2011 at 17:18 GMT, Eric Belhomme <rico-{nntp}@ricozome.net> a écrit :
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 ?
(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 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 -+-
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 -+-
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 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 -+-
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 -+-
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 -+-
