J'ai un serveur web double pattes en DMZ publique.
les deux pattes sont chacune chez un fournisseur différent avec des
passerelles différentes.
Mon soucis, c'est que je n'arrive à le faire marcher correctement que
sur une patte. Depuis l'internet, la machine n'est accessible que sur la
patte qui a la route par défaut, et si je mets deux routes par défaut,
c'est la dernière créée qui est utilisée.
Y a une soluce, à ce genre de problème?
--
rantamplan
le chien le plus con
de tout le cyberespace
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
Patrick MATHEVON
:: J'ai un serveur web double pattes en DMZ publique. :: les deux pattes sont chacune chez un fournisseur différent avec des :: passerelles différentes. :: Mon soucis, c'est que je n'arrive à le faire marcher correctement que :: sur une patte. Depuis l'internet, la machine n'est accessible que :: sur la patte qui a la route par défaut, et si je mets deux routes :: par défaut, c'est la dernière créée qui est utilisée. :: :: Y a une soluce, à ce genre de problème?
Il s'agit d'etre logique : une passerelle par défaut, ca sert à aller sur un réseau quand on ne connait pas explicitement la route. Donc, une route par défaut, elle est unique. Donc, UNE SEULE passerelle par défaut. La solution : mettre un protocole de routage ou plutot un couple de protocole de routage (OSPF + BGP par exemple..)
Patrick
:: J'ai un serveur web double pattes en DMZ publique.
:: les deux pattes sont chacune chez un fournisseur différent avec des
:: passerelles différentes.
:: Mon soucis, c'est que je n'arrive à le faire marcher correctement que
:: sur une patte. Depuis l'internet, la machine n'est accessible que
:: sur la patte qui a la route par défaut, et si je mets deux routes
:: par défaut, c'est la dernière créée qui est utilisée.
::
:: Y a une soluce, à ce genre de problème?
Il s'agit d'etre logique : une passerelle par défaut, ca sert à aller sur un
réseau quand on ne connait pas explicitement la route. Donc, une route par
défaut, elle est unique. Donc, UNE SEULE passerelle par défaut. La solution
: mettre un protocole de routage ou plutot un couple de protocole de routage
(OSPF + BGP par exemple..)
:: J'ai un serveur web double pattes en DMZ publique. :: les deux pattes sont chacune chez un fournisseur différent avec des :: passerelles différentes. :: Mon soucis, c'est que je n'arrive à le faire marcher correctement que :: sur une patte. Depuis l'internet, la machine n'est accessible que :: sur la patte qui a la route par défaut, et si je mets deux routes :: par défaut, c'est la dernière créée qui est utilisée. :: :: Y a une soluce, à ce genre de problème?
Il s'agit d'etre logique : une passerelle par défaut, ca sert à aller sur un réseau quand on ne connait pas explicitement la route. Donc, une route par défaut, elle est unique. Donc, UNE SEULE passerelle par défaut. La solution : mettre un protocole de routage ou plutot un couple de protocole de routage (OSPF + BGP par exemple..)
Patrick
rantamplan
Patrick MATHEVON disait...
Il s'agit d'etre logique : une passerelle par défaut, ca sert à aller sur un réseau quand on ne connait pas explicitement la route. Donc, une route par défaut, elle est unique. Donc, UNE SEULE passerelle par défaut. La solution : mettre un protocole de routage ou plutot un couple de protocole de routage (OSPF + BGP par exemple..)
Il n'y a pas de moyen simple pour que les paquets repartent simplement par l'interface d'où est arrive la requète initiale, quoi.
-- rantamplan le chien le plus con de tout le cyberespace
Patrick MATHEVON disait...
Il s'agit d'etre logique : une passerelle par défaut, ca sert à aller sur un
réseau quand on ne connait pas explicitement la route. Donc, une route par
défaut, elle est unique. Donc, UNE SEULE passerelle par défaut. La solution
: mettre un protocole de routage ou plutot un couple de protocole de routage
(OSPF + BGP par exemple..)
Il n'y a pas de moyen simple pour que les paquets repartent simplement
par l'interface d'où est arrive la requète initiale, quoi.
--
rantamplan
le chien le plus con
de tout le cyberespace
Il s'agit d'etre logique : une passerelle par défaut, ca sert à aller sur un réseau quand on ne connait pas explicitement la route. Donc, une route par défaut, elle est unique. Donc, UNE SEULE passerelle par défaut. La solution : mettre un protocole de routage ou plutot un couple de protocole de routage (OSPF + BGP par exemple..)
Il n'y a pas de moyen simple pour que les paquets repartent simplement par l'interface d'où est arrive la requète initiale, quoi.
-- rantamplan le chien le plus con de tout le cyberespace
Cedric Blancher
Dans sa prose, rantamplan nous ecrivait :
Il n'y a pas de moyen simple pour que les paquets repartent simplement par l'interface d'où est arrive la requète initiale, quoi.
Non, à part les masquerader avant (genre le routeur juste avant). Mais du coup, tu vas perdre l'adresse IP du client original.
-- Bien reçu message via groupes discussion, je te répond avec la touche " répondre au groupe " en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+-
Dans sa prose, rantamplan nous ecrivait :
Il n'y a pas de moyen simple pour que les paquets repartent simplement par
l'interface d'où est arrive la requète initiale, quoi.
Non, à part les masquerader avant (genre le routeur juste avant). Mais du
coup, tu vas perdre l'adresse IP du client original.
--
Bien reçu message via groupes discussion, je te répond avec la touche "
répondre au groupe " en ayant sélectionné ton message. J'espère que tu le
recevra dans ta boîte de réception. Le café est en préparation.
-+- in Guide du Neuneu Usenet - Open up, open up -+-
Il n'y a pas de moyen simple pour que les paquets repartent simplement par l'interface d'où est arrive la requète initiale, quoi.
Non, à part les masquerader avant (genre le routeur juste avant). Mais du coup, tu vas perdre l'adresse IP du client original.
-- Bien reçu message via groupes discussion, je te répond avec la touche " répondre au groupe " en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+-
rantamplan
Cedric Blancher disait...
Dans sa prose, rantamplan nous ecrivait :
Il n'y a pas de moyen simple pour que les paquets repartent simplement par l'interface d'où est arrive la requète initiale, quoi. Non, à part les masquerader avant (genre le routeur juste avant). Mais du
coup, tu vas perdre l'adresse IP du client original. C'est très clair...
-- rantamplan le chien le plus con de tout le cyberespace
Cedric Blancher disait...
Dans sa prose, rantamplan nous ecrivait :
Il n'y a pas de moyen simple pour que les paquets repartent simplement par
l'interface d'où est arrive la requète initiale, quoi.
Non, à part les masquerader avant (genre le routeur juste avant). Mais du
coup, tu vas perdre l'adresse IP du client original.
C'est très clair...
--
rantamplan
le chien le plus con
de tout le cyberespace
Il n'y a pas de moyen simple pour que les paquets repartent simplement par l'interface d'où est arrive la requète initiale, quoi. Non, à part les masquerader avant (genre le routeur juste avant). Mais du
coup, tu vas perdre l'adresse IP du client original. C'est très clair...
-- rantamplan le chien le plus con de tout le cyberespace
Cedric Blancher
Dans sa prose, rantamplan nous ecrivait :
C'est très clair...
En fait si, j'ai une solution pour toi, même deux en fait, mais va falloir que ton serveur soit sous Linux...
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en exemple pour le routage avancé. Comme ton serveur répond avec en source l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit être possible sur d'autres Unix.
Sinon, deuxième solution, sous Linux exclusivement cette fois, tu peux utiliser la cible CONNMARK[2] de Netfilter (pom, section extra). Elle te permet d'affecter une marque à un session complète telle que vue par le moteur de conntrack. De fait, il suffit que tu affectes une marque pour les paquets qui arrivent par eth0, une autre pour ceux qui arrivent par eth1. Ensuite, les paquets appartenant à la même session auront la même marque et il ne te restera plus qu'à router en fonction de cette marque (là encore, cf. LARTC). Ceci dit, je n'ai pas encore eu trop le temps d'approfondir cette fonctionnalité, je ne pourrais donc pas te donner les règles qui vont avec.
-- "Alors, je crois savoir ce qui n'allait pas. J'ai désactivé l'option : Send in rich HTML by default. Et je crois que c'était ça qui foutait le bordel." -+- EF in Guide du linuxien pervers : "Bien configurer son Netscape"
Dans sa prose, rantamplan nous ecrivait :
C'est très clair...
En fait si, j'ai une solution pour toi, même deux en fait, mais va
falloir que ton serveur soit sous Linux...
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur
la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en
exemple pour le routage avancé. Comme ton serveur répond avec en source
l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit
être possible sur d'autres Unix.
Sinon, deuxième solution, sous Linux exclusivement cette fois, tu peux
utiliser la cible CONNMARK[2] de Netfilter (pom, section extra). Elle te
permet d'affecter une marque à un session complète telle que vue par le
moteur de conntrack. De fait, il suffit que tu affectes une marque pour
les paquets qui arrivent par eth0, une autre pour ceux qui arrivent par
eth1. Ensuite, les paquets appartenant à la même session auront la même
marque et il ne te restera plus qu'à router en fonction de cette marque
(là encore, cf. LARTC). Ceci dit, je n'ai pas encore eu trop le temps
d'approfondir cette fonctionnalité, je ne pourrais donc pas te donner les
règles qui vont avec.
--
"Alors, je crois savoir ce qui n'allait pas. J'ai désactivé
l'option : Send in rich HTML by default. Et je crois que c'était
ça qui foutait le bordel."
-+- EF in Guide du linuxien pervers : "Bien configurer son Netscape"
En fait si, j'ai une solution pour toi, même deux en fait, mais va falloir que ton serveur soit sous Linux...
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en exemple pour le routage avancé. Comme ton serveur répond avec en source l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit être possible sur d'autres Unix.
Sinon, deuxième solution, sous Linux exclusivement cette fois, tu peux utiliser la cible CONNMARK[2] de Netfilter (pom, section extra). Elle te permet d'affecter une marque à un session complète telle que vue par le moteur de conntrack. De fait, il suffit que tu affectes une marque pour les paquets qui arrivent par eth0, une autre pour ceux qui arrivent par eth1. Ensuite, les paquets appartenant à la même session auront la même marque et il ne te restera plus qu'à router en fonction de cette marque (là encore, cf. LARTC). Ceci dit, je n'ai pas encore eu trop le temps d'approfondir cette fonctionnalité, je ne pourrais donc pas te donner les règles qui vont avec.
-- "Alors, je crois savoir ce qui n'allait pas. J'ai désactivé l'option : Send in rich HTML by default. Et je crois que c'était ça qui foutait le bordel." -+- EF in Guide du linuxien pervers : "Bien configurer son Netscape"
rantamplan
Cedric Blancher disait...
Dans sa prose, rantamplan nous ecrivait :
C'est très clair...
En fait si, j'ai une solution pour toi, même deux en fait, mais va falloir que ton serveur soit sous Linux... oui, c'est déjà un petit barebone en debian.
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en exemple pour le routage avancé. Comme ton serveur répond avec en source l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit être possible sur d'autres Unix. Je suis dessus. Je vais lire avec attention.
Ce serait bien d'avoir un loadbalancing simple sur ce serveur, vu qu'on a deux deux sorties 1024 vers deux fournisseurs différents.
-- rantamplan le chien le plus con de tout le cyberespace
Cedric Blancher disait...
Dans sa prose, rantamplan nous ecrivait :
C'est très clair...
En fait si, j'ai une solution pour toi, même deux en fait, mais va
falloir que ton serveur soit sous Linux...
oui, c'est déjà un petit barebone en debian.
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur
la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en
exemple pour le routage avancé. Comme ton serveur répond avec en source
l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit
être possible sur d'autres Unix.
Je suis dessus. Je vais lire avec attention.
Ce serait bien d'avoir un loadbalancing simple sur ce serveur, vu qu'on
a deux deux sorties 1024 vers deux fournisseurs différents.
--
rantamplan
le chien le plus con
de tout le cyberespace
En fait si, j'ai une solution pour toi, même deux en fait, mais va falloir que ton serveur soit sous Linux... oui, c'est déjà un petit barebone en debian.
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en exemple pour le routage avancé. Comme ton serveur répond avec en source l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit être possible sur d'autres Unix. Je suis dessus. Je vais lire avec attention.
Ce serait bien d'avoir un loadbalancing simple sur ce serveur, vu qu'on a deux deux sorties 1024 vers deux fournisseurs différents.
-- rantamplan le chien le plus con de tout le cyberespace
T0t0
"rantamplan" wrote in message news:
J'ai un serveur web double pattes en DMZ publique. les deux pattes sont chacune chez un fournisseur différent avec des passerelles différentes. Y a une soluce, à ce genre de problème?
Regarde du coté de iproute2, il me semble que tu peux faire ce genre de choses. <http://www.freenix.fr/unix/linux/HOWTO/Advanced-routing-Howto.html> (Arf, l'URL marche plus chez moi, mais on sait jamais...)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"rantamplan" <rantamplan@seldon.dyndns.org> wrote in message
news:MPG.19e4b253ab4934859897a1@news.free.fr
J'ai un serveur web double pattes en DMZ publique.
les deux pattes sont chacune chez un fournisseur différent avec des
passerelles différentes.
Y a une soluce, à ce genre de problème?
Regarde du coté de iproute2, il me semble que tu peux faire ce genre de
choses.
<http://www.freenix.fr/unix/linux/HOWTO/Advanced-routing-Howto.html>
(Arf, l'URL marche plus chez moi, mais on sait jamais...)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
J'ai un serveur web double pattes en DMZ publique. les deux pattes sont chacune chez un fournisseur différent avec des passerelles différentes. Y a une soluce, à ce genre de problème?
Regarde du coté de iproute2, il me semble que tu peux faire ce genre de choses. <http://www.freenix.fr/unix/linux/HOWTO/Advanced-routing-Howto.html> (Arf, l'URL marche plus chez moi, mais on sait jamais...)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
rantamplan
Cedric Blancher disait...
Dans sa prose, rantamplan nous ecrivait :
C'est très clair...
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en exemple pour le routage avancé. Comme ton serveur répond avec en source l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit être possible sur d'autres Unix.
Ca marche! apt-get source iproute cd iproute... debuild cd .. dpkg -i *.deb création des deux tables T1 et T2 dans rt_tables, puis
un petit script: # cat /etc/scripts/iproute #! /bin/bash
#declaration des variables #IF0 est l'interface oleane #IF1 est une interface utilisable, mais débranchee #pour connecter le routeur directement au reseau local #IF2 est l'interface alphalink
#mise en place des tables de routages T1 et T1 ip route add $P0_NET dev $IF0 src $IP0 table T1 ip route add default via $P0 table T1 ip route add $P2_NET dev $IF2 src $IP2 table T2 ip route add default via $P2 table T2
#on fait en sorte que les paquets arrivés par l'interface 0 #repartent par l'interface 0 ip route add $P0_NET dev $IF0 src $IP0 ip route add $P2_NET dev $IF2 src $IP2
#puis on déclare une route par défaut en préférence, #ici c'est l'interface oleane ip route add default via $P0
#execution des tables de routage, pour diriger les paquets #s'ils proviennent d'une source externe, vers l'interface #d'ou ils sont venus ip rule add from $IP0 table T1 ip rule add from $IP2 table T2
#un echo pour voir ip route
j'ai descendu les 3 interfaces avec ifconfig eth0 down, puis up. Pour flusher les tables de routage (y a mieux, mais c'était plus rapide que de batailler sur le man) puis, j'ai executé le script, et ça roule.
Merci Cedric, merci Linux
-- rantamplan le chien le plus con de tout le cyberespace
Cedric Blancher disait...
Dans sa prose, rantamplan nous ecrivait :
C'est très clair...
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur
la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en
exemple pour le routage avancé. Comme ton serveur répond avec en source
l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit
être possible sur d'autres Unix.
Ca marche!
apt-get source iproute
cd iproute...
debuild
cd ..
dpkg -i *.deb
création des deux tables T1 et T2 dans rt_tables, puis
un petit script:
# cat /etc/scripts/iproute
#! /bin/bash
#declaration des variables
#IF0 est l'interface oleane
#IF1 est une interface utilisable, mais débranchee
#pour connecter le routeur directement au reseau local
#IF2 est l'interface alphalink
#mise en place des tables de routages T1 et T1
ip route add $P0_NET dev $IF0 src $IP0 table T1
ip route add default via $P0 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
#on fait en sorte que les paquets arrivés par l'interface 0
#repartent par l'interface 0
ip route add $P0_NET dev $IF0 src $IP0
ip route add $P2_NET dev $IF2 src $IP2
#puis on déclare une route par défaut en préférence,
#ici c'est l'interface oleane
ip route add default via $P0
#execution des tables de routage, pour diriger les paquets
#s'ils proviennent d'une source externe, vers l'interface
#d'ou ils sont venus
ip rule add from $IP0 table T1
ip rule add from $IP2 table T2
#un echo pour voir
ip route
j'ai descendu les 3 interfaces avec ifconfig eth0 down,
puis up. Pour flusher les tables de routage (y a mieux, mais c'était
plus rapide que de batailler sur le man)
puis, j'ai executé le script, et ça roule.
Merci Cedric, merci Linux
--
rantamplan
le chien le plus con
de tout le cyberespace
Si tes deux pattes ont des IPs différentes, tu peux faire du routage sur la source du paquet. Va voir le LARTC[1], c'est expliqué dedans en exemple pour le routage avancé. Comme ton serveur répond avec en source l'IP qui a servi à l'interroger, tu peux t'en sortir comme ça. Ça doit être possible sur d'autres Unix.
Ca marche! apt-get source iproute cd iproute... debuild cd .. dpkg -i *.deb création des deux tables T1 et T2 dans rt_tables, puis
un petit script: # cat /etc/scripts/iproute #! /bin/bash
#declaration des variables #IF0 est l'interface oleane #IF1 est une interface utilisable, mais débranchee #pour connecter le routeur directement au reseau local #IF2 est l'interface alphalink
#mise en place des tables de routages T1 et T1 ip route add $P0_NET dev $IF0 src $IP0 table T1 ip route add default via $P0 table T1 ip route add $P2_NET dev $IF2 src $IP2 table T2 ip route add default via $P2 table T2
#on fait en sorte que les paquets arrivés par l'interface 0 #repartent par l'interface 0 ip route add $P0_NET dev $IF0 src $IP0 ip route add $P2_NET dev $IF2 src $IP2
#puis on déclare une route par défaut en préférence, #ici c'est l'interface oleane ip route add default via $P0
#execution des tables de routage, pour diriger les paquets #s'ils proviennent d'une source externe, vers l'interface #d'ou ils sont venus ip rule add from $IP0 table T1 ip rule add from $IP2 table T2
#un echo pour voir ip route
j'ai descendu les 3 interfaces avec ifconfig eth0 down, puis up. Pour flusher les tables de routage (y a mieux, mais c'était plus rapide que de batailler sur le man) puis, j'ai executé le script, et ça roule.
Merci Cedric, merci Linux
-- rantamplan le chien le plus con de tout le cyberespace
Cedric Blancher
Dans sa prose, T0t0 nous ecrivait :
Regarde du coté de iproute2, il me semble que tu peux faire ce genre de choses. <http://www.freenix.fr/unix/linux/HOWTO/Advanced-routing-Howto.html> (Arf, l'URL marche plus chez moi, mais on sait jamais...)
STFW ;))))
http://lartc.org/
LARTC comme Linux Avanced Routing and Traffic Control, et non pas comme Luser Attitude Reajustment Tool, just in Case...
-- Newsgroups: fr.comp.mail je suis à la recherche d'un shema électronique d'un émetteur G.P.S (Global position system) ou à defaut une adrs Email -+- N in Guide du Neuneu Usenet - Sans son GNU, on est perdu -+-
Dans sa prose, T0t0 nous ecrivait :
Regarde du coté de iproute2, il me semble que tu peux faire ce genre de
choses.
<http://www.freenix.fr/unix/linux/HOWTO/Advanced-routing-Howto.html> (Arf,
l'URL marche plus chez moi, mais on sait jamais...)
STFW ;))))
http://lartc.org/
LARTC comme Linux Avanced Routing and Traffic Control, et non pas comme
Luser Attitude Reajustment Tool, just in Case...
--
Newsgroups: fr.comp.mail
je suis à la recherche d'un shema électronique d'un émetteur G.P.S
(Global position system) ou à defaut une adrs Email
-+- N in Guide du Neuneu Usenet - Sans son GNU, on est perdu -+-
Regarde du coté de iproute2, il me semble que tu peux faire ce genre de choses. <http://www.freenix.fr/unix/linux/HOWTO/Advanced-routing-Howto.html> (Arf, l'URL marche plus chez moi, mais on sait jamais...)
STFW ;))))
http://lartc.org/
LARTC comme Linux Avanced Routing and Traffic Control, et non pas comme Luser Attitude Reajustment Tool, just in Case...
-- Newsgroups: fr.comp.mail je suis à la recherche d'un shema électronique d'un émetteur G.P.S (Global position system) ou à defaut une adrs Email -+- N in Guide du Neuneu Usenet - Sans son GNU, on est perdu -+-
