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...
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...
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...
mbernard01 écrivait dans fr.comp.reseaux.ip :
- Site A : virtualhost sur l'interface eth0
- Site B : virtualhost sur l'interface eth1
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.
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
mbernard01 écrivait dans fr.comp.reseaux.ip :
- Site A : virtualhost sur l'interface eth0
- Site B : virtualhost sur l'interface eth1
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.
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
mbernard01 écrivait dans fr.comp.reseaux.ip :
- Site A : virtualhost sur l'interface eth0
- Site B : virtualhost sur l'interface eth1
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.
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
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.
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.
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.
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
On est bien d'accord (mais je ne suis pas sûr que l'OP nous
suive...).
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
On est bien d'accord (mais je ne suis pas sûr que l'OP nous
suive...).
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
On est bien d'accord (mais je ne suis pas sûr que l'OP nous
suive...).
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 !
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 !
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 !
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.
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.
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,
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.
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.
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.
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
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
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