Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pb configuration serveur web linux avec 2 réseaux et 2 passerelles

8 réponses
Avatar
mbernard01
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)

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.

8 réponses

Avatar
JKB
Le 26-11-2009, ? propos de
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.
Avatar
Pascal Hambourg
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.

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.
Avatar
JKB
Le 26-11-2009, ? propos de
Re: Pb configuration serveur web linux avec 2 réseaux et 2 passerelles,
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.

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 ?



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...).

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.
Avatar
Pascal Hambourg
JKB a écrit :

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 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 !
Avatar
JKB
Le 26-11-2009, ? propos de
Re: Pb configuration serveur web linux avec 2 réseaux et 2 passerelles,
Pascal Hambourg ?crivait dans fr.comp.reseaux.ip :
JKB a écrit :

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 requête sur
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.

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.
Avatar
mbernard01
JKB a écrit le 26/11/2009 à 16h57 :
Le 26-11-2009, ? propos de
Re: Pb configuration serveur web linux avec 2 réseaux et 2 passerelles,
Pascal Hambourg ?crivait dans fr.comp.reseaux.ip :
JKB a écrit :

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
requête sur
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.

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.


Bonjour et merci à tous pour vos réponses.

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.
Avatar
mbernard01
mbernard01 a écrit le 26/11/2009 à 11h58 :
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)

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.


Re-bonjour à tous,

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)
Avatar
Pascal Hambourg
mbernard01 a écrit :

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


[...]
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.