Pb configuration serveur web linux avec 2 réseaux et 2 passerelles
mbernard01
Je vais tenter de vous expliquer mon probl�me :
j'ai actuellement un serveur web sous ubuntu qui comporte 2 interfaces r�seaux
:
- eth0 -> IP: 192.168.92.3/24 gw 192.168.92.254
- eth1 -> IP: 192.168.93.4/24 gw 192.168.93.254
Les 2 r�seaux sont distincts car il s'agit de services diff�rents. Ce serveur
h�berge 2 sites web (c'est l� ou ca se corse) via Apache.
- Site A : virtualhost sur l'interface eth0
- Site B : virtualhost sur l'interface eth1
Les passerelles de chacun de ces r�seaux sont des routeurs VPN Firewall Netgear
Prosafe avec ligne ADSL et IP fixe.
Niveau registrar, chaque site pointe sur l'IP fixe de la ligne ADSL.
C�t� serveur, voici le r�sultat de netstat -r :
192.168.93.0 * 255.255.255.0 U 0 0 0 eth1
192.168.92.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.93.254 0.0.0.0 UG 0 0 0 eth1
default 192.168.92.254 0.0.0.0 UG 0 0 0 eth0
(je ne suis pas du tout s�r que ceci est correct)
Mes VirtualHosts Apache sont configur�s correctement, j'ai bien mis
Listen 192.168.92.3:80
Listen 192.168.93.4:80
+ les directives qui vont bien.
Maintenant mon probl�me :
de mani�re al�atoire, le site A fonctionne (cad. HTTP/1.x 200 OK) et le site B
ne fonctionne pas ("D�lai d'attente d�pass�", dixit Firefox) et inversement : le
site A ne fonctionne plus et le site B fonctionne.
Quelqu'un a-t-il d�j� rencontr� un probl�me similaire, sachant que je ne m'y
connais pas beaucoup en r�seau, je suis d�veloppeur � la base...
Merci d'avance pour vos r�ponses.
JKB
Pb configuration serveur web linux avec 2 réseaux et 2 passerelles,
mbernard01 ?crivait dans fr.comp.reseaux.ip :
> Bonjour,
Bonjour,
> Je vais tenter de vous expliquer mon problème :
> j'ai actuellement un serveur web sous ubuntu qui comporte 2 interfaces réseaux
>:
> - eth0 -> IP: 192.168.92.3/24 gw 192.168.92.254
> - eth1 -> IP: 192.168.93.4/24 gw 192.168.93.254
>
> Les 2 réseaux sont distincts car il s'agit de services différents. Ce serveur
> héberge 2 sites web (c'est là ou ca se corse) via Apache.
> - Site A : virtualhost sur l'interface eth0
> - Site B : virtualhost sur l'interface eth1
>
> Les passerelles de chacun de ces réseaux sont des routeurs VPN Firewall Netgear
> Prosafe avec ligne ADSL et IP fixe.
> Niveau registrar, chaque site pointe sur l'IP fixe de la ligne ADSL.
>
> Côté serveur, voici le résultat de netstat -r :
> 192.168.93.0 * 255.255.255.0 U 0 0 0 eth1
> 192.168.92.0 * 255.255.255.0 U 0 0 0 eth0
> default 192.168.93.254 0.0.0.0 UG 0 0 0 eth1
> default 192.168.92.254 0.0.0.0 UG 0 0 0 eth0
>
> (je ne suis pas du tout sûr que ceci est correct)
Je ne suis pas sûr non plus que deux routes par défaut soient
recommandées. Le routage vers les routes par défaut sera folklorique
pour ne pas dire aléatoire. Il ne fait qu'une seule route par
défault, vers l'interface principale.
Pour configurer correctement ce genre de chose, il faut passer par
iproute2 et iptables en configurant la route par défaut sur eth0, en
marquant les paquets qui doivent sortir par eth1 et en les routant
de force sur eth1. Il y a des tas de tutoriels sur le net qui
parlent de ce genre de sport.
> Mes VirtualHosts Apache sont configurés correctement, j'ai bien mis
> Listen 192.168.92.3:80
> Listen 192.168.93.4:80
> + les directives qui vont bien.
>
> Maintenant mon problème :
> de manière aléatoire, le site A fonctionne (cad. HTTP/1.x 200 OK) et le site B
> ne fonctionne pas ("Délai d'attente dépassé", dixit Firefox) et inversement : le
> site A ne fonctionne plus et le site B fonctionne.
Ben oui, une requête sur eth0 va recevoir un paquet en provenance de
eth1 donc les connexions TCP ne vont pas, mais alors paas du tout,
aimer. Idem pour l'autre configuration.
> Quelqu'un a-t-il déjà rencontré un problème similaire, sachant que je ne m'y
> connais pas beaucoup en réseau, je suis développeur à la base...
Oui. Mais il faut bien intégrer les fonctions réseau et la
configuration. Je ne veux pas être désagréable, ce n'est pas le but,
mais ce genre de configuration est assez spéciale et vu ta
connaissance du réseau, il vaut mieux trouver une personne qui a
déjà fait ce genre de chose par devers toi. Commencer à toucher
iproute2 sans avoir un minimum de connaissances réseau ou un minimum
de connaissance des mécanismes iptables, c'est un coup à ne plus
avoir rien qui fonctionne...
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Pascal Hambourg
JKB a ï¿œcrit :
> mbernard01 ï¿œcrivait dans fr.comp.reseaux.ip :
>>
>> - Site A : virtualhost sur l'interface eth0
>> - Site B : virtualhost sur l'interface eth1
Correction : sur /l'adresse/ de l'interface.
>> Cￜtￜ serveur, voici le rￜsultat de netstat -r :
>> 192.168.93.0 * 255.255.255.0 U 0 0 0 eth1
>> 192.168.92.0 * 255.255.255.0 U 0 0 0 eth0
>> default 192.168.93.254 0.0.0.0 UG 0 0 0 eth1
>> default 192.168.92.254 0.0.0.0 UG 0 0 0 eth0
>>
>> (je ne suis pas du tout sï¿œr que ceci est correct)
>
> Je ne suis pas sï¿œr non plus que deux routes par dï¿œfaut soient
> recommandï¿œes. Le routage vers les routes par dï¿œfaut sera folklorique
> pour ne pas dire alï¿œatoire. Il ne fait qu'une seule route par
> dï¿œfault, vers l'interface principale.
Ce n'est pas que ï¿œa ne marche pas, mais en gï¿œnï¿œral ï¿œa ne se comporte pas
comme on pense si on n'a pas une idï¿œe claire de ce qu'est une route par
dï¿œfaut. S'il y en a plusieurs, le systï¿œme va en choisir une par un
processus qui a probablement une logique mais qui peut appararaï¿œtre
comme alï¿œatoire pour un observateur. Si les deux routes sont valables
(vis-ￜ-vis de la destination, de l'adresse source, du chemin ￜ
emprunter...), alors pas de problï¿œme. Sinon, on va dire qu'on a une
chance sur deux que le systï¿œme choisisse la mauvaise.
> Pour configurer correctement ce genre de chose, il faut passer par
> iproute2 et iptables en configurant la route par dï¿œfaut sur eth0, en
> marquant les paquets qui doivent sortir par eth1 et en les routant
> de force sur eth1. Il y a des tas de tutoriels sur le net qui
> parlent de ce genre de sport.
Plus simple dans ce cas de figure qui permet d'ï¿œviter le marquage par
iptables : crￜer des rￜgles de routage avancￜ basￜes sur l'adresse
source. Exemple basique :
ip rule add from 192.168.93.4 table 93
ip route add default via 192.168.93.254 table 93
etc.
>> de maniï¿œre alï¿œatoire, le site A fonctionne (cad. HTTP/1.x 200 OK) et le site B
>> ne fonctionne pas ("Dￜlai d'attente dￜpassￜ", dixit Firefox) et inversement : le
>> site A ne fonctionne plus et le site B fonctionne.
>
> Ben oui, une requï¿œte sur eth0 va recevoir un paquet en provenance de
> eth1
Gni ? Tu veux dire que la rￜponse ￜ une requￜte reￜue par eth0 va ￜtre
ï¿œmise par eth1 ?
Dans un internet "idￜal" (sans NAT, ni firewall ￜ ￜtat, ni vￜrification
d'adresse source... en gros l'internet originel) ï¿œa ne poserait pas de
problï¿œme. Si la requï¿œte est reï¿œue par eth0 alors que la route par dï¿œfaut
active passe via eth1, alors la rï¿œponse passera par eth1, la belle
affaire. Aprï¿œs tout le routage asymï¿œtrique est une caractï¿œristique
courante d'internet et des rï¿œseaux IP.
Mais dans l'internet rï¿œel, il y a plusieurs choses qui peuvent faire que
ï¿œa ne marche pas :
- Le serveur peut faire de la validation d'adresse source en vï¿œrifiant
que l'adresse source d'un paquet reï¿œu par une interface X est bien
joignable par cette mï¿œme interface en se basant sur les routes actives.
Pour Linux, cela se rï¿œgle avec les sysctls net.ipv4.conf.*.rp_filter.
Malheureusement il peut oublier d'appliquer les rￜgles de routage avancￜ
(si basï¿œes sur l'adresse source), ou bien ces rï¿œgle ne sont pas
appliquables (si basï¿œes sur une marque). Dans ce cas, un paquet reï¿œu de
l'extï¿œrieur par eth0 alors que la route par dï¿œfaut active est par eth1
sera jetￜ. J'ai cru lire que cela avait ￜtￜ amￜliorￜ dans une version
rï¿œcente du noyau, mais dans le doute on doit dï¿œsactiver cette option.
- Si les passerelles internet font du NAT ou du filtrage ￜ ￜtat, ces
fonctions ne supportent pas bien du tout le routage asymï¿œtrique car le
mï¿œme routeur doit voir le trafic d'une connexion TCP dans les deux sens
(ou bien les deux doivent synchroniser leurs tables d'ï¿œtat). Lorsqu'une
telle passerelle voit passer une rￜponse ￜ une requￜte qu'il n'a pas vu
passer, elle risque de jeter le paquet ou ne pas le NATer correctement.
- Le FAI d'une ou des connexions ADSL peuvent aussi faire de la
validation d'adresse source : s'il voit un paquet ï¿œmis par la connexion
1 avec l'adresse source de la connexion 2, il jette. C'est une mesure
contre l'usurpation d'adresse IP.
Pour toutes ces raisons, on est plus ou moins obligￜ de forcer un
routage symï¿œtrique.
JKB
Pascal Hambourg ?crivait dans fr.comp.reseaux.ip :
> Salut,
>
> JKB a écrit :
>> mbernard01 écrivait dans fr.comp.reseaux.ip :
>>>
>>> - Site A : virtualhost sur l'interface eth0
>>> - Site B : virtualhost sur l'interface eth1
>
> Correction : sur /l'adresse/ de l'interface.
>
>>> 192.168.93.0 * 255.255.255.0 U 0 0 0 eth1
>>> 192.168.92.0 * 255.255.255.0 U 0 0 0 eth0
>>> default 192.168.93.254 0.0.0.0 UG 0 0 0 eth1
>>> default 192.168.92.254 0.0.0.0 UG 0 0 0 eth0
>>>
>>
>> Je ne suis pas sûr non plus que deux routes par défaut soient
>> recommandées. Le routage vers les routes par défaut sera folklorique
>> pour ne pas dire aléatoire. Il ne fait qu'une seule route par
>> défault, vers l'interface principale.
>
> Ce n'est pas que ça ne marche pas, mais en général ça ne se comporte pas
> comme on pense si on n'a pas une idée claire de ce qu'est une route par
> défaut. S'il y en a plusieurs, le système va en choisir une par un
> processus qui a probablement une logique mais qui peut appararaître
> comme aléatoire pour un observateur. Si les deux routes sont valables
> (vis-à-vis de la destination, de l'adresse source, du chemin à
> emprunter...), alors pas de problème. Sinon, on va dire qu'on a une
> chance sur deux que le système choisisse la mauvaise.
>
>> Pour configurer correctement ce genre de chose, il faut passer par
>> marquant les paquets qui doivent sortir par eth1 et en les routant
>> de force sur eth1. Il y a des tas de tutoriels sur le net qui
>> parlent de ce genre de sport.
>
> iptables : créer des règles de routage avancé basées sur l'adresse
> source. Exemple basique :
>
> ip rule add from 192.168.93.4 table 93
> ip route add default via 192.168.93.254 table 93
> etc.
>
>>> ne fonctionne pas ("Délai d'attente dépassé", dixit Firefox) et inversement : le
>>> site A ne fonctionne plus et le site B fonctionne.
>>
>> eth1
>
> Gni ? Tu veux dire que la réponse à une requête reçue par eth0 va être
> émise par eth1 ?
Non, je ne veux pas, mais c'est ce qui risque d'arriver (au moins
avec Linux, et j'ai passé des journées avec tcpdump pour valider des
configurations de ce type).
> Dans un internet "idéal" (sans NAT, ni firewall à état, ni vérification
> d'adresse source... en gros l'internet originel) ça ne poserait pas de
> problème. Si la requête est reçue par eth0 alors que la route par défaut
> active passe via eth1, alors la réponse passera par eth1, la belle
> affaire. Après tout le routage asymétrique est une caractéristique
> courante d'internet et des réseaux IP.
>
> Mais dans l'internet réel, il y a plusieurs choses qui peuvent faire que
> ça ne marche pas :
>
> - Le serveur peut faire de la validation d'adresse source en vérifiant
> que l'adresse source d'un paquet reçu par une interface X est bien
> joignable par cette même interface en se basant sur les routes actives.
> Pour Linux, cela se règle avec les sysctls net.ipv4.conf.*.rp_filter.
> Malheureusement il peut oublier d'appliquer les règles de routage avancé
> (si basées sur l'adresse source), ou bien ces règle ne sont pas
> appliquables (si basées sur une marque). Dans ce cas, un paquet reçu de
> l'extérieur par eth0 alors que la route par défaut active est par eth1
> sera jeté. J'ai cru lire que cela avait été amélioré dans une version
> récente du noyau, mais dans le doute on doit désactiver cette option.
>
> - Si les passerelles internet font du NAT ou du filtrage à état, ces
> fonctions ne supportent pas bien du tout le routage asymétrique car le
> même routeur doit voir le trafic d'une connexion TCP dans les deux sens
> (ou bien les deux doivent synchroniser leurs tables d'état). Lorsqu'une
> telle passerelle voit passer une réponse à une requête qu'il n'a pas vu
> passer, elle risque de jeter le paquet ou ne pas le NATer correctement.
>
> - Le FAI d'une ou des connexions ADSL peuvent aussi faire de la
> validation d'adresse source : s'il voit un paquet émis par la connexion
> 1 avec l'adresse source de la connexion 2, il jette. C'est une mesure
> contre l'usurpation d'adresse IP.
>
> Pour toutes ces raisons, on est plus ou moins obligé de forcer un
> routage symétrique.
On est bien d'accord (mais je ne suis pas sûr que l'OP nous
suive...).
Pascal Hambourg
>>
>>> Ben oui, une requï¿œte sur eth0 va recevoir un paquet en provenance de
>>> eth1
>> Gni ? Tu veux dire que la rￜponse ￜ une requￜte reￜue par eth0 va ￜtre
>
> Non, je ne veux pas
En fait je n'ai pas compris ce que tu as voulu dire par "une requï¿œte sur
eth0 va recevoir un paquet". Une requï¿œte qui reï¿œoit un paquet ???
> On est bien d'accord (mais je ne suis pas sï¿œr que l'OP nous
> suive...).
Je sais que tu sais, on s'est croisￜ assez souvent ici sur cette
problￜmatique. Cette tentative de pￜdagogie ￜtait destinￜe ￜ l'OP, ne me
dis pas que j'ai encore ratￜ mon coup !
JKB
Re: Pb configuration serveur web linux avec 2 réseaux et 2 passerelles,
Pascal Hambourg ?crivait dans fr.comp.reseaux.ip :
>>>
>>>> Ben oui, une requête sur eth0 va recevoir un paquet en provenance de
>>>> eth1
>>> Gni ? Tu veux dire que la réponse à une requête reçue par eth0 va être
>>
>> Non, je ne veux pas
>
> eth0 va recevoir un paquet". Une requête qui reçoit un paquet ???
Oui, bon, fatigué, tout ça... L'idée que j'essayais d'écrire,
c'était qu'un paquet arrivant sur eth0 pouvait voir sa réponse émise
sur eth1, ce qui ne pose pas de problème en soit sauf pour les trucs
qui font du nat ou le paquet risque de se perdre au premier nat
rencontré, typiquement le modem... De toute façon, on était
d'accord...
>> On est bien d'accord (mais je ne suis pas sûr que l'OP nous
>> suive...).
>
> Je sais que tu sais, on s'est croisé assez souvent ici sur cette
> problématique. Cette tentative de pédagogie était destinée à l'OP, ne me
> dis pas que j'ai encore raté mon coup !
Pour quelqu'un qui a des connaissances réseau, je ne dis pas. Mais
l'OP me semble léger (je ne dénigre pas, chacun son métier) pour
suivre ce genre de problèmes de routage.
mbernard01
> Le 26-11-2009, ? propos de
> Pascal Hambourg ?crivait dans fr.comp.reseaux.ip :
>>>>
>>>>> Ben oui, une requ�te sur eth0 va recevoir un paquet en provenance de
>>>>> eth1
>>>>>
>>>> Gni ? Tu veux dire que la r�ponse � une requ�te
>>>> re�ue par eth0 va �tre
>>>> �mise par eth1 ?
>>>>
>>>
>>> Non, je ne veux pas
>>>
>>
>> En fait je n'ai pas compris ce que tu as voulu dire par "une
>> eth0 va recevoir un paquet". Une requ�te qui re�oit un
>> paquet ???
>>
>
> Oui, bon, fatigu�, tout �a... L'id�e que j'essayais
> d'�crire,
> c'�tait qu'un paquet arrivant sur eth0 pouvait voir sa r�ponse
> �mise
> sur eth1, ce qui ne pose pas de probl�me en soit sauf pour les trucs
> qui font du nat ou le paquet risque de se perdre au premier nat
> �tait
> d'accord...
>
>>> On est bien d'accord (mais je ne suis pas s�r que l'OP nous
>>> suive...).
>>>
>>
>> Je sais que tu sais, on s'est crois� assez souvent ici sur cette
>> probl�matique. Cette tentative de p�dagogie �tait
>> destin�e � l'OP, ne me
>> dis pas que j'ai encore rat� mon coup !
>>
>
> Pour quelqu'un qui a des connaissances r�seau, je ne dis pas. Mais
> l'OP me semble l�ger (je ne d�nigre pas, chacun son
> m�tier) pour
> suivre ce genre de probl�mes de routage.
>
> JKB
>
> --
> Le cerveau, c'est un v�ritable scandale �cologique. Il
> repr�sente 2% de notre
> masse corporelle, mais disperse � lui seul 25% de l'�nergie que
> nous
> consommons tous les jours.
En supposant que "l'OP" c'est moi :-) effectivement je n'ai pas les comp�tences
pour faire du routage avanc�. C'est d'ailleurs pour cette raison que j'ai post�
ici, mais j'ai l'esprit ouvert donc � l'�coute de vos remarques.
En r�alit�, je viens de d�couvrir ce probl�me (l'admin r�seau �tant parti
depuis un an environ, aujourd'hui je suis le seul de la boite � maitriser
Linux... cherchez l'erreur).
J'ai fait un tcpdump sur eth1 port 80 et pas de trace de mes paquets.
Je vais essayer vos id�es en mettant une seule route par d�faut ainsi que la
solution de Pascal, et si rien ne fonctionne je pense que je vais proposer
d'all�ger l'architecture, d'autant plus que cette configuration n'est absolument
pas indispensable, mais l� ce n'est pas moi qui aurait le dernier mot :-)
Je posterai demain les essais en suivant vos conseils.
mbernard01
J'ai d� un peu laisser tomber ce sujet pour l'instant, mais mon boss est revenu
� la charge et j'ai donc d� m'y atteler :-)
J'ai r�ussi � trouver la solution, j'en fais profiter tout le monde comme ca si
quelqu'un rencontre ce probl�me il n'aura pas trop � gal�rer :-)
J'ai confirm� avec `tcpdump -v port http` et quelques tests que les paquets
entraient sur eth0 et ressortaient sur eth1, d'o� un drop par le routeur de
eth1...
Tout d'abord, voici le tutorial qui m'a servi � r�soudre mon probl�me :
http://www.linux-france.org/prj/inetdoc/guides/Advanced-routing-Howto/lartc.rpdb.multiple-links.html
Pr�-requis : installez le paquet iproute
Etape 1 : �diter le fichier /etc/iproute2/rt_tables et ajoutez les lignes
suivantes (selon votre configuration) pour cr�er deux nouvelles tables de
routage :
250 eth0
249 eth1
Etape 2 : configuration des tables de routages nouvellement cr��es :
ip route add 192.168.92.0 dev eth0 src 192.168.92.3 table 250
ip route add default via 192.168.92.254 table 250
ip route add 192.168.93.0 dev eth0 src 192.168.93.4 table 249
ip route add default via 192.168.93.254 table 249
ip route add 192.168.92.0 dev eth0 src 192.168.92.3
ip route add 192.168.93.0 dev eth0 src 192.168.93.4
Configuration de la route par d�faut :
ip route add default via 192.168.93.4
Etape 3 : configuration des r�gles de routage
ip rule add from 192.168.92.3 table 250
ip rule add from 192.168.93.4 table 249
Et voil� ! Normalement tout fonctionne (du moins chez moi c'est le cas)
Pascal Hambourg
>
> Etape 1 : ï¿œditer le fichier /etc/iproute2/rt_tables et ajoutez les lignes
> suivantes (selon votre configuration) pour crï¿œer deux nouvelles tables de
> routage :
> 250 eth0
> 249 eth1
>
> ip route add 192.168.92.0 dev eth0 src 192.168.92.3 table 250
> Etape 3 : configuration des rï¿œgles de routage
> ip rule add from 192.168.92.3 table 250
Notes:
1) L'ï¿œdition du fichier rt_tables ne crï¿œe pas de nouvelles tables, les
256 tables prￜexistent dￜjￜ. C'est juste du "cosmￜtique" optionnel
permettant d'identifier les tables par de jolis noms explicites plutï¿œt
que par leurs numï¿œros. C'est donc dommage d'utiliser les numï¿œros de
tables dans les rï¿œgles de routage et les routes au lieu des noms dï¿œfinis
dans rt_tables. Si on identifie les tables par leur numï¿œro dans les
rï¿œgles et routes, inutile de les nommer dans rt_tables.
2) Donner ￜ des tables des noms d'interfaces pourrait prￜter ￜ
confusion. Je suggï¿œre de dï¿œfinir des noms de table ï¿œventuellement
contenant les noms des interfaces mais avec un prï¿œfixe ou suffixe pour
les reconnaï¿œtre en tant que tables. Par exemple : table_eth0.