Je dois mettre en place une passerelle internet pour ma boite. On
dispose de 2 acces adsl (avec deux ip fixe, chez 2 fournisseurs
differents). Le but de la passerelle : pare-feu, nat, dhcp et cache
dns.
J'aimerais bien mettre un OpenBSD sur cette machine (OpenBSD 3.9) mais
est il possible de la configurer avec les 2 acces en load-balancing ?
Je ne cherche pas en mettre en place des queues envoyant tel ou tel
trafic sur une liaison donn=E9e. Juste a faire en sorte d'avoir le
meilleur d=E9bit possible (ie profiter au maximum des deux adsl).
Et si l'une d'elle tombe, ca serait bien aussi que tout reste
transparent.
Avez vous deja teste, des retours d'experiences, des idees, des liens
???
Je dois mettre en place une passerelle internet pour ma boite. On dispose de 2 acces adsl (avec deux ip fixe, chez 2 fournisseurs differents). Le but de la passerelle : pare-feu, nat, dhcp et cache dns. J'aimerais bien mettre un OpenBSD sur cette machine (OpenBSD 3.9) mais est il possible de la configurer avec les 2 acces en load-balancing ? Je ne cherche pas en mettre en place des queues envoyant tel ou tel trafic sur une liaison donnée. Juste a faire en sorte d'avoir le meilleur débit possible (ie profiter au maximum des deux adsl). Et si l'une d'elle tombe, ca serait bien aussi que tout reste transparent. Avez vous deja teste, des retours d'experiences, des idees, des liens ???
Merci
Bon, je me réponds a moi meme :) D'apres la faq : http://www.openbsd.com/faq/pf/fr/pools.html#outgoing , il existe cette possibilité. Qqn aurait'il deja testé ? Et ca ne précise pas ce qui se passe en cas de panne sur une des liaisons... Merci
Salut,
Je dois mettre en place une passerelle internet pour ma boite. On
dispose de 2 acces adsl (avec deux ip fixe, chez 2 fournisseurs
differents). Le but de la passerelle : pare-feu, nat, dhcp et cache
dns.
J'aimerais bien mettre un OpenBSD sur cette machine (OpenBSD 3.9) mais
est il possible de la configurer avec les 2 acces en load-balancing ?
Je ne cherche pas en mettre en place des queues envoyant tel ou tel
trafic sur une liaison donnée. Juste a faire en sorte d'avoir le
meilleur débit possible (ie profiter au maximum des deux adsl).
Et si l'une d'elle tombe, ca serait bien aussi que tout reste
transparent.
Avez vous deja teste, des retours d'experiences, des idees, des liens
???
Merci
Bon, je me réponds a moi meme :)
D'apres la faq : http://www.openbsd.com/faq/pf/fr/pools.html#outgoing ,
il existe cette possibilité.
Qqn aurait'il deja testé ? Et ca ne précise pas ce qui se passe en
cas de panne sur une des liaisons...
Merci
Je dois mettre en place une passerelle internet pour ma boite. On dispose de 2 acces adsl (avec deux ip fixe, chez 2 fournisseurs differents). Le but de la passerelle : pare-feu, nat, dhcp et cache dns. J'aimerais bien mettre un OpenBSD sur cette machine (OpenBSD 3.9) mais est il possible de la configurer avec les 2 acces en load-balancing ? Je ne cherche pas en mettre en place des queues envoyant tel ou tel trafic sur une liaison donnée. Juste a faire en sorte d'avoir le meilleur débit possible (ie profiter au maximum des deux adsl). Et si l'une d'elle tombe, ca serait bien aussi que tout reste transparent. Avez vous deja teste, des retours d'experiences, des idees, des liens ???
Merci
Bon, je me réponds a moi meme :) D'apres la faq : http://www.openbsd.com/faq/pf/fr/pools.html#outgoing , il existe cette possibilité. Qqn aurait'il deja testé ? Et ca ne précise pas ce qui se passe en cas de panne sur une des liaisons... Merci
manu
Pierre wrote:
Bon, je me réponds a moi meme :) D'apres la faq : http://www.openbsd.com/faq/pf/fr/pools.html#outgoing , il existe cette possibilité. Qqn aurait'il deja testé ? Et ca ne précise pas ce qui se passe en cas de panne sur une des liaisons...
Ben la solution "propre" mais lourde pour ce genre de situations, c'est de faire du routage via BGP, mais il faut que les FAI proposent cette prestation.
Il y a des solutions moins lourde, mais à ma connaissance, aucune ne permettra d'utiliser la connexion la meilleure pour atteindre une destination donnée. -- Emmanue Dreyfus
Pierre <TuxPierre@gmail.com> wrote:
Bon, je me réponds a moi meme :)
D'apres la faq : http://www.openbsd.com/faq/pf/fr/pools.html#outgoing ,
il existe cette possibilité.
Qqn aurait'il deja testé ? Et ca ne précise pas ce qui se passe en
cas de panne sur une des liaisons...
Ben la solution "propre" mais lourde pour ce genre de situations, c'est
de faire du routage via BGP, mais il faut que les FAI proposent cette
prestation.
Il y a des solutions moins lourde, mais à ma connaissance, aucune ne
permettra d'utiliser la connexion la meilleure pour atteindre une
destination donnée.
--
Emmanue Dreyfus
manu@netbsd.org
Bon, je me réponds a moi meme :) D'apres la faq : http://www.openbsd.com/faq/pf/fr/pools.html#outgoing , il existe cette possibilité. Qqn aurait'il deja testé ? Et ca ne précise pas ce qui se passe en cas de panne sur une des liaisons...
Ben la solution "propre" mais lourde pour ce genre de situations, c'est de faire du routage via BGP, mais il faut que les FAI proposent cette prestation.
Il y a des solutions moins lourde, mais à ma connaissance, aucune ne permettra d'utiliser la connexion la meilleure pour atteindre une destination donnée. -- Emmanue Dreyfus
bsdouille
tu as deja de la chance moi je voulais faire la meme chose mais avec deux modems cable (meme fai) mais impossible du a des conflit de reponses d'adresse mac !
bsdouille
tu as deja de la chance moi je voulais faire la meme chose mais avec
deux modems cable (meme fai)
mais impossible du a des conflit de reponses d'adresse mac !
tu as deja de la chance moi je voulais faire la meme chose mais avec deux modems cable (meme fai) mais impossible du a des conflit de reponses d'adresse mac !
bsdouille
Stephane Catteau
n'était pas loin de dire :
tu as deja de la chance moi je voulais faire la meme chose mais avec deux modems cable (meme fai) mais impossible du a des conflit de reponses d'adresse mac !
Ca reste possible quand même, je le sais j'ai deux FAI derrière le FreeBSD qui me sert de passerelle, mais il ne faut pas trop compter sur le load-balancing pour ça. Par contre en jouant avec les routes c'est tout à fait possible. Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
bsdouille@numericable.fr n'était pas loin de dire :
tu as deja de la chance moi je voulais faire la meme chose mais avec
deux modems cable (meme fai)
mais impossible du a des conflit de reponses d'adresse mac !
Ca reste possible quand même, je le sais j'ai deux FAI derrière le
FreeBSD qui me sert de passerelle, mais il ne faut pas trop compter sur
le load-balancing pour ça. Par contre en jouant avec les routes c'est
tout à fait possible.
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui
s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est
le PC du p'tit, on passe par l'interface de plus bas débit".
tu as deja de la chance moi je voulais faire la meme chose mais avec deux modems cable (meme fai) mais impossible du a des conflit de reponses d'adresse mac !
Ca reste possible quand même, je le sais j'ai deux FAI derrière le FreeBSD qui me sert de passerelle, mais il ne faut pas trop compter sur le load-balancing pour ça. Par contre en jouant avec les routes c'est tout à fait possible. Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
Eric Masson
Stephane Catteau writes:
'Lut,
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va bien, ça devrait faire ce que tu veux.
Éric
-- Cela m'a même déjà valu quelques discussions animés avec mes paires -+- FC in <http://www.le-gnu.net> : Tête à tête ou tête à queue ? -+-
Stephane Catteau <steph.nospam@sc4x.net> writes:
'Lut,
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui
s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est
le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va
bien, ça devrait faire ce que tu veux.
Éric
--
Cela m'a même déjà valu quelques discussions animés avec mes paires
-+- FC in <http://www.le-gnu.net> : Tête à tête ou tête à queue ? -+-
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va bien, ça devrait faire ce que tu veux.
Éric
-- Cela m'a même déjà valu quelques discussions animés avec mes paires -+- FC in <http://www.le-gnu.net> : Tête à tête ou tête à queue ? -+-
Stephane Catteau
Eric Masson devait dire quelque chose comme ceci :
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va bien, ça devrait faire ce que tu veux.
Effectivement, à première vue ça devrait le faire, merci.
Eric Masson devait dire quelque chose comme ceci :
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui
s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est
le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va
bien, ça devrait faire ce que tu veux.
Effectivement, à première vue ça devrait le faire, merci.
Eric Masson devait dire quelque chose comme ceci :
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va bien, ça devrait faire ce que tu veux.
Effectivement, à première vue ça devrait le faire, merci.
Pierre
Eric Masson devait dire quelque chose comme ceci :
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va bien, ça devrait faire ce que tu veux.
Effectivement, à première vue ça devrait le faire, merci.
Merci a tous pour vos réponses. Cependant j'aurais encore quelques infos a vous demander. Mes deux acces seront chez des fournisseurs differents : un en degroupage total et l'autre en non degroupe. La connexion en degroupage total se fera via une FreeBox, donc une simple config en dhcp suffira. Par contre, l'autre se fera via un modem, donc connexion pppoe. Est ce que cela pose un problème ? Je pensais notamment au lancement de pf (il me semble avoir vu qu'il fallait attendre que la connexion se fasse avant de le lancer) Autre contrainte : certains flux (pptp notamment) devront transiter seulement via une des interfaces (le serveur pptp etant héberge chez un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen d'assigner des flux à une interface ?
Merci
Eric Masson devait dire quelque chose comme ceci :
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui
s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est
le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va
bien, ça devrait faire ce que tu veux.
Effectivement, à première vue ça devrait le faire, merci.
Merci a tous pour vos réponses. Cependant j'aurais encore quelques
infos a vous demander. Mes deux acces seront chez des fournisseurs
differents : un en degroupage total et l'autre en non degroupe. La
connexion en degroupage total se fera via une FreeBox, donc une simple
config en dhcp suffira. Par contre, l'autre se fera via un modem, donc
connexion pppoe.
Est ce que cela pose un problème ? Je pensais notamment au lancement
de pf (il me semble avoir vu qu'il fallait attendre que la connexion se
fasse avant de le lancer)
Autre contrainte : certains flux (pptp notamment) devront transiter
seulement via une des interfaces (le serveur pptp etant héberge chez
un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen
d'assigner des flux à une interface ?
Eric Masson devait dire quelque chose comme ceci :
Le seul truc que je n'ai pas trouver, c'est la même chose mais qui s'appuyerait sur l'adresse d'origine. Quelque chose du genre "si c'est le PC du p'tit, on passe par l'interface de plus bas débit".
Jette un oeil du coté de route-to (pf), associé au keep-state qui va bien, ça devrait faire ce que tu veux.
Effectivement, à première vue ça devrait le faire, merci.
Merci a tous pour vos réponses. Cependant j'aurais encore quelques infos a vous demander. Mes deux acces seront chez des fournisseurs differents : un en degroupage total et l'autre en non degroupe. La connexion en degroupage total se fera via une FreeBox, donc une simple config en dhcp suffira. Par contre, l'autre se fera via un modem, donc connexion pppoe. Est ce que cela pose un problème ? Je pensais notamment au lancement de pf (il me semble avoir vu qu'il fallait attendre que la connexion se fasse avant de le lancer) Autre contrainte : certains flux (pptp notamment) devront transiter seulement via une des interfaces (le serveur pptp etant héberge chez un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen d'assigner des flux à une interface ?
Merci
Eric Masson
"Pierre" writes:
'Lut,
Est ce que cela pose un problème ? Je pensais notamment au lancement de pf (il me semble avoir vu qu'il fallait attendre que la connexion se fasse avant de le lancer)
Iirc, il est préférable que les interfaces existent avant de lancer pf (enfin, ça a peut-être été revu depuis), par contre, il n'est pas nécessaire que des adresses leur aient été attribuées.
Autre contrainte : certains flux (pptp notamment) devront transiter seulement via une des interfaces (le serveur pptp etant héberge chez un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen d'assigner des flux à une interface ?
Toujours via le route-to, le plus simple est de lire le pf user's guide disponible en ligne sur le site d'Open : http://openbsd.org/faq/pf/index.html http://openbsd.org/faq/pf/fr/index.html
-- BC> Merci à tous de me ploooonnKER !!!! que j'ai plus à vous supporter! VR> Du coup, je l'ai déplonké, pour voir. Tiens, moi il est passé de -1000 à -100... -+- ED in GNU : La constante de plonk en solde à -100 -+-
"Pierre" <TuxPierre@gmail.com> writes:
'Lut,
Est ce que cela pose un problème ? Je pensais notamment au lancement
de pf (il me semble avoir vu qu'il fallait attendre que la connexion se
fasse avant de le lancer)
Iirc, il est préférable que les interfaces existent avant de lancer pf
(enfin, ça a peut-être été revu depuis), par contre, il n'est pas
nécessaire que des adresses leur aient été attribuées.
Autre contrainte : certains flux (pptp notamment) devront transiter
seulement via une des interfaces (le serveur pptp etant héberge chez
un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen
d'assigner des flux à une interface ?
Toujours via le route-to, le plus simple est de lire le pf user's guide
disponible en ligne sur le site d'Open :
http://openbsd.org/faq/pf/index.html
http://openbsd.org/faq/pf/fr/index.html
--
BC> Merci à tous de me ploooonnKER !!!! que j'ai plus à vous supporter!
VR> Du coup, je l'ai déplonké, pour voir.
Tiens, moi il est passé de -1000 à -100...
-+- ED in GNU : La constante de plonk en solde à -100 -+-
Est ce que cela pose un problème ? Je pensais notamment au lancement de pf (il me semble avoir vu qu'il fallait attendre que la connexion se fasse avant de le lancer)
Iirc, il est préférable que les interfaces existent avant de lancer pf (enfin, ça a peut-être été revu depuis), par contre, il n'est pas nécessaire que des adresses leur aient été attribuées.
Autre contrainte : certains flux (pptp notamment) devront transiter seulement via une des interfaces (le serveur pptp etant héberge chez un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen d'assigner des flux à une interface ?
Toujours via le route-to, le plus simple est de lire le pf user's guide disponible en ligne sur le site d'Open : http://openbsd.org/faq/pf/index.html http://openbsd.org/faq/pf/fr/index.html
-- BC> Merci à tous de me ploooonnKER !!!! que j'ai plus à vous supporter! VR> Du coup, je l'ai déplonké, pour voir. Tiens, moi il est passé de -1000 à -100... -+- ED in GNU : La constante de plonk en solde à -100 -+-
Stephane Catteau
Pierre n'était pas loin de dire :
Merci a tous pour vos réponses. Cependant j'aurais encore quelques infos a vous demander. Mes deux acces seront chez des fournisseurs differents : un en degroupage total et l'autre en non degroupe. La connexion en degroupage total se fera via une FreeBox, donc une simple config en dhcp suffira. Par contre, l'autre se fera via un modem, donc connexion pppoe.
Je tourne avec une FreeBox et une connexion Wanadoo en parallèle derrière ma passerelle depuis plus ou moins un an et ce sans réels problèmes. J'ai un peu tatonné au début, mais rien d'insurmontable. Bon, c'est du FreeBSD mais je ne vois pas pourquoi cela ne fonctionnerait pas tout aussi bien avec OpenBSD.
Est ce que cela pose un problème ? Je pensais notamment au lancement de pf (il me semble avoir vu qu'il fallait attendre que la connexion se fasse avant de le lancer)
C'est le point le plus [beep] en fait. Déjà pour la connexion PPPoE il faut que tu la référence en utilisant le nom de l'interface (tun0), de façon à ne pas avoir à changer les règles. PF récupère tout seul l'adresse IP associée, mais apparament il ne le fait qu'au chargement des règles. Du coup j'ai créé deux versions, une avec les deux interfaces et l'autre avec seulement l'interface correspondant à la FreeBox. Et j'utilise ppp.linkup et ppp.linkdown pour gérer la transition : ppp.linkup !bg pfctl -f /etc/pf.conf !bg /root/bin/resetroute.sh
Le script resetroute.sh se contente de définir les routes que je veux en fonction des interfaces, et le script freeroute.sh purge la table de routage et place la route par défaut sur la FreeBox. Je pourrais le faire directement dans les deux scripts, mais je trouve que c'est plus souple comme ça.
Au bout du compte, le fonctionnement est le suivant : 1) PPPoE se connecte 2) Le fichier ppp.linkup est appelé a) Les règles standard de pf sont chargées b) La table de routage standard est définie 3) La connexion coupe 4) Le fichier ppp.linkdown est appelé a) Les règles de pf sont changées pour que tout passe par la FreeBox b) La table de routage est changée de la même façon 5) PPPoE se reconnecte 6) on boucle en 2.
De cette façon, non seulement tu recharges les règles de pf pour qu'elles utilisent la nouvelle adresse IP de la connexion via PPPoE, mais surtout, si PPPoE n'arrive pas à se reconnecter tu ne te retrouves pas coincé avec pf qui bloque parce qu'il ne trouve pas d'interface tun0. Au final, avec Wanadoo pendant plus ou moins une minute par jour tout passe par la FreeBox, c'est le seul défaut que j'arrive à trouver.
Autre contrainte : certains flux (pptp notamment) devront transiter seulement via une des interfaces (le serveur pptp etant héberge chez un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen d'assigner des flux à une interface ?
Des flux je ne sais pas, mais des routes oui.
Merci
De rien.
Pierre n'était pas loin de dire :
Merci a tous pour vos réponses. Cependant j'aurais encore quelques
infos a vous demander. Mes deux acces seront chez des fournisseurs
differents : un en degroupage total et l'autre en non degroupe. La
connexion en degroupage total se fera via une FreeBox, donc une simple
config en dhcp suffira. Par contre, l'autre se fera via un modem, donc
connexion pppoe.
Je tourne avec une FreeBox et une connexion Wanadoo en parallèle
derrière ma passerelle depuis plus ou moins un an et ce sans réels
problèmes. J'ai un peu tatonné au début, mais rien d'insurmontable.
Bon, c'est du FreeBSD mais je ne vois pas pourquoi cela ne
fonctionnerait pas tout aussi bien avec OpenBSD.
Est ce que cela pose un problème ? Je pensais notamment au lancement
de pf (il me semble avoir vu qu'il fallait attendre que la connexion se
fasse avant de le lancer)
C'est le point le plus [beep] en fait. Déjà pour la connexion PPPoE il
faut que tu la référence en utilisant le nom de l'interface (tun0), de
façon à ne pas avoir à changer les règles. PF récupère tout seul
l'adresse IP associée, mais apparament il ne le fait qu'au chargement
des règles.
Du coup j'ai créé deux versions, une avec les deux interfaces et
l'autre avec seulement l'interface correspondant à la FreeBox. Et
j'utilise ppp.linkup et ppp.linkdown pour gérer la transition :
ppp.linkup
!bg pfctl -f /etc/pf.conf
!bg /root/bin/resetroute.sh
Le script resetroute.sh se contente de définir les routes que je veux
en fonction des interfaces, et le script freeroute.sh purge la table de
routage et place la route par défaut sur la FreeBox. Je pourrais le
faire directement dans les deux scripts, mais je trouve que c'est plus
souple comme ça.
Au bout du compte, le fonctionnement est le suivant :
1) PPPoE se connecte
2) Le fichier ppp.linkup est appelé
a) Les règles standard de pf sont chargées
b) La table de routage standard est définie
3) La connexion coupe
4) Le fichier ppp.linkdown est appelé
a) Les règles de pf sont changées pour que tout passe par la FreeBox
b) La table de routage est changée de la même façon
5) PPPoE se reconnecte
6) on boucle en 2.
De cette façon, non seulement tu recharges les règles de pf pour
qu'elles utilisent la nouvelle adresse IP de la connexion via PPPoE,
mais surtout, si PPPoE n'arrive pas à se reconnecter tu ne te retrouves
pas coincé avec pf qui bloque parce qu'il ne trouve pas d'interface
tun0.
Au final, avec Wanadoo pendant plus ou moins une minute par jour tout
passe par la FreeBox, c'est le seul défaut que j'arrive à trouver.
Autre contrainte : certains flux (pptp notamment) devront transiter
seulement via une des interfaces (le serveur pptp etant héberge chez
un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen
d'assigner des flux à une interface ?
Merci a tous pour vos réponses. Cependant j'aurais encore quelques infos a vous demander. Mes deux acces seront chez des fournisseurs differents : un en degroupage total et l'autre en non degroupe. La connexion en degroupage total se fera via une FreeBox, donc une simple config en dhcp suffira. Par contre, l'autre se fera via un modem, donc connexion pppoe.
Je tourne avec une FreeBox et une connexion Wanadoo en parallèle derrière ma passerelle depuis plus ou moins un an et ce sans réels problèmes. J'ai un peu tatonné au début, mais rien d'insurmontable. Bon, c'est du FreeBSD mais je ne vois pas pourquoi cela ne fonctionnerait pas tout aussi bien avec OpenBSD.
Est ce que cela pose un problème ? Je pensais notamment au lancement de pf (il me semble avoir vu qu'il fallait attendre que la connexion se fasse avant de le lancer)
C'est le point le plus [beep] en fait. Déjà pour la connexion PPPoE il faut que tu la référence en utilisant le nom de l'interface (tun0), de façon à ne pas avoir à changer les règles. PF récupère tout seul l'adresse IP associée, mais apparament il ne le fait qu'au chargement des règles. Du coup j'ai créé deux versions, une avec les deux interfaces et l'autre avec seulement l'interface correspondant à la FreeBox. Et j'utilise ppp.linkup et ppp.linkdown pour gérer la transition : ppp.linkup !bg pfctl -f /etc/pf.conf !bg /root/bin/resetroute.sh
Le script resetroute.sh se contente de définir les routes que je veux en fonction des interfaces, et le script freeroute.sh purge la table de routage et place la route par défaut sur la FreeBox. Je pourrais le faire directement dans les deux scripts, mais je trouve que c'est plus souple comme ça.
Au bout du compte, le fonctionnement est le suivant : 1) PPPoE se connecte 2) Le fichier ppp.linkup est appelé a) Les règles standard de pf sont chargées b) La table de routage standard est définie 3) La connexion coupe 4) Le fichier ppp.linkdown est appelé a) Les règles de pf sont changées pour que tout passe par la FreeBox b) La table de routage est changée de la même façon 5) PPPoE se reconnecte 6) on boucle en 2.
De cette façon, non seulement tu recharges les règles de pf pour qu'elles utilisent la nouvelle adresse IP de la connexion via PPPoE, mais surtout, si PPPoE n'arrive pas à se reconnecter tu ne te retrouves pas coincé avec pf qui bloque parce qu'il ne trouve pas d'interface tun0. Au final, avec Wanadoo pendant plus ou moins une minute par jour tout passe par la FreeBox, c'est le seul défaut que j'arrive à trouver.
Autre contrainte : certains flux (pptp notamment) devront transiter seulement via une des interfaces (le serveur pptp etant héberge chez un de mes FAI, autant passer par sa connexion). Y a t'il donc un moyen d'assigner des flux à une interface ?
Des flux je ne sais pas, mais des routes oui.
Merci
De rien.
espie
In article , Stephane Catteau wrote:
C'est le point le plus [beep] en fait. Déjà pour la connexion PPPoE il faut que tu la référence en utilisant le nom de l'interface (tun0), de façon à ne pas avoir à changer les règles. PF récupère tout seul l'adresse IP associée, mais apparament il ne le fait qu'au chargement des règles.
je sais pas si FreeBSD a porte une version assez recente de pf, mais sur OpenBSD:
Host name resolution and interface to address translation are done at ruleset load-time. When the address of an interface (or host name) changes (under DHCP or PPP, for instance), the ruleset must be reloaded for the change to be reflected in the kernel. Sur- rounding the interface name (and optional modifiers) in parentheses changes this behaviour. When the interface name is surrounded by parentheses, the rule is automatically updated whenever the inter- face changes its address. The ruleset does not need to be reload- ed. This is especially useful with nat.
Pour le partage des deux connexions, le trunking devrait permettre de faire des trucs rigolos, mais j'ai pas encore essaye d'agreger du pppoe et de l'ethernet...
In article <mn.bbef7d664912de79.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
C'est le point le plus [beep] en fait. Déjà pour la connexion PPPoE il
faut que tu la référence en utilisant le nom de l'interface (tun0), de
façon à ne pas avoir à changer les règles. PF récupère tout seul
l'adresse IP associée, mais apparament il ne le fait qu'au chargement
des règles.
je sais pas si FreeBSD a porte une version assez recente de pf, mais sur
OpenBSD:
Host name resolution and interface to address translation are done
at ruleset load-time. When the address of an interface (or host
name) changes (under DHCP or PPP, for instance), the ruleset must
be reloaded for the change to be reflected in the kernel. Sur-
rounding the interface name (and optional modifiers) in parentheses
changes this behaviour. When the interface name is surrounded by
parentheses, the rule is automatically updated whenever the inter-
face changes its address. The ruleset does not need to be reload-
ed. This is especially useful with nat.
Pour le partage des deux connexions, le trunking devrait permettre de
faire des trucs rigolos, mais j'ai pas encore essaye d'agreger du
pppoe et de l'ethernet...
C'est le point le plus [beep] en fait. Déjà pour la connexion PPPoE il faut que tu la référence en utilisant le nom de l'interface (tun0), de façon à ne pas avoir à changer les règles. PF récupère tout seul l'adresse IP associée, mais apparament il ne le fait qu'au chargement des règles.
je sais pas si FreeBSD a porte une version assez recente de pf, mais sur OpenBSD:
Host name resolution and interface to address translation are done at ruleset load-time. When the address of an interface (or host name) changes (under DHCP or PPP, for instance), the ruleset must be reloaded for the change to be reflected in the kernel. Sur- rounding the interface name (and optional modifiers) in parentheses changes this behaviour. When the interface name is surrounded by parentheses, the rule is automatically updated whenever the inter- face changes its address. The ruleset does not need to be reload- ed. This is especially useful with nat.
Pour le partage des deux connexions, le trunking devrait permettre de faire des trucs rigolos, mais j'ai pas encore essaye d'agreger du pppoe et de l'ethernet...
