GROS GROS problème réseau

Dans le message <news:d7inb7$qbp$1@apollon.grec.isp.9tel.net>,
*Jean-Philippe* tapota sur f.c.o.l.configuration et a.f.c.o.l.configuration
:

Bonjour,

Bonsoir,

Je suis assez em...dé depuis quelque (trop de?) temps déjà avec une
machine qui n'arrive pas à joindre le net ni être accessible du net (c'est
un serveur web).

Mes machines qu'on appellera de la manière suivante en cette période
Starwars:
- ioda = un serveur web derrière une passerelle/parefeu
- obiwan = la passerelle/parefeu
Ces machines sont de même métal: debian 2.4.27-2-686

Equipement:
- DNS et parefeu (via iptables) sur obiwan
- Apache2 + Mysql sur ioda

Voilà en gros le comportement que j'observe et que je n'arrive pas à
résoudre. Il est assez homogène mais je n'arrive pas à trouver la
solution. Pour mes tests, j'ai utilisé ethereal, host, ping, les LOG
d'iptables et lynx et pour tous ces essais, j'ai ouvert le parefeu juste
pour l'occasion (policy ACCEPT partout et 2 seules règles: un MASQUERADE
en postrouting vers ppp0 et un DNAT en prerouting vers ioda sur la table
nat):

- en contactant ioda du web, la machine reçoit les SYN et renvoie les
SYN/ACK;

À quoi le voyez-vous précisément ?

obiwan ne voit que l'aller, pas le retour

Même question.

- ioda résoud bien les hosts par le DNS sur obiwan mais n'arrive pas à
accéder au web par une commande lynx sur google par exemple,

lynx étant un logiciel bien conçu, il devrait alors vous dire la raison pour
laquelle il ne peut joindre Google. Quelle est-elle ?

- impossible d'installer quoi que ce soit par apt-get, évidemment

Même remarque, même question.

- je peux pinger toute adresse LAN sans problème mais pinger une IP google
à partir de ioda me renvoie ça par exemple:
PING 216.239.59.104 (216.239.59.104) 56(84) bytes of data.
From ?.?.?.? icmp_seq=1 Destination Host Unreachable
From ?.?.?.? icmp_seq=2 Destination Host Unreachable
From ?.?.?.? icmp_seq=3 Destination Host Unreachable

Et un traceroute vers cette même adresse ?

- obiwan, lui, ne renvoie rien (sûrement un "-p icmp -j DROP" à l'autre
bout):

Non, plutôt un DROP à votre niveau.

PING 216.239.59.104 (216.239.59.104) 56(84) bytes of data.
--- 216.239.59.104 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7016ms

$ ping -c1 216.239.59.104
PING 216.239.59.104 (216.239.59.104) 56(84) bytes of data.
64 bytes from 216.239.59.104: icmp_seq=1 ttl#8 time`.8 ms

--- 216.239.59.104 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 60.805/60.805/60.805/0.000 ms

- 2 autres machines (mdk) sur ce LAN accèdent sans aucun problème au
web...

Pour moi, le problème vient de ioda (serveur web) et non pas de obiwan
(passerelle/parefeu), me trompé-je?

À mon avis il y a à revoir la configuration réseau sur ces deux machines.

Quelqu'un a-t-il déjà eu ce genre de problème?

Non, pas chez moi. :-P

Une idée pour résoudre ce sac de noeuds?

Ça manque de précisions et d'informations.

Quelles sont les tables de routages sur les deux machines ? Quelles sont les
règles iptables définies sur les deux machines ?

Merci

De rien.

--
TiChou

Jean-Philippe wrote:

Bonjour,

Bonjour,

Je suis assez em...dé depuis quelque (trop de?) temps déjà avec une
machine qui n'arrive pas à joindre le net ni être accessible du net
(c'est un serveur web).

Mes machines qu'on appellera de la manière suivante en cette période
Starwars:
- ioda = un serveur web derrière une passerelle/parefeu
- obiwan = la passerelle/parefeu
Ces machines sont de même métal: debian 2.4.27-2-686

Equipement:
- DNS et parefeu (via iptables) sur obiwan
- Apache2 + Mysql sur ioda

Voilà en gros le comportement que j'observe et que je n'arrive pas à
résoudre. Il est assez homogène mais je n'arrive pas à trouver la
solution. Pour mes tests, j'ai utilisé ethereal, host, ping, les LOG
d'iptables et lynx et pour tous ces essais, j'ai ouvert le parefeu juste
pour l'occasion (policy ACCEPT partout et 2 seules règles: un MASQUERADE
en postrouting vers ppp0 et un DNAT en prerouting vers ioda sur la table
nat):

- en contactant ioda du web, la machine reçoit les SYN et renvoie les
SYN/ACK; obiwan ne voit que l'aller, pas le retour

- ioda contacte bien obiwan par ARP et la résolution MAC fonctionne (vu
par ethereal)

- ioda résoud bien les hosts par le DNS sur obiwan mais n'arrive pas à
accéder au web par une commande lynx sur google par exemple, aucune
trace par ethereal de cette tentative de connexion

- impossible d'installer quoi que ce soit par apt-get, évidemment

- je peux pinger toute adresse LAN sans problème mais pinger une IP
google à partir de ioda me renvoie ça par exemple:
PING 216.239.59.104 (216.239.59.104) 56(84) bytes of data.
From ?.?.?.? icmp_seq=1 Destination Host Unreachable
From ?.?.?.? icmp_seq=2 Destination Host Unreachable
From ?.?.?.? icmp_seq=3 Destination Host Unreachable

- obiwan, lui, ne renvoie rien (sûrement un "-p icmp -j DROP" à l'autre
bout):
PING 216.239.59.104 (216.239.59.104) 56(84) bytes of data.
--- 216.239.59.104 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7016ms

- 2 autres machines (mdk) sur ce LAN accèdent sans aucun problème au
web...

Pour moi, le problème vient de ioda (serveur web) et non pas de obiwan
(passerelle/parefeu), me trompé-je?
Quelqu'un a-t-il déjà eu ce genre de problème?
Une idée pour résoudre ce sac de noeuds?

Dans l'hypothèse ou les firewall sont désactivés:
comment est la route par défaut sur le serveur http ioda?

Merci
Pas de quoi.

--
Eric

Eric Dorino wrote:

Dans l'hypothèse ou les firewall sont désactivés:
comment est la route par défaut sur le serveur http ioda?

Les routes par défaut sont:
pour obiwan:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
9-207-118-80 * 255.255.255.255 UH 0 0 0 ppp0
localnet obiwan. 255.255.255.0 UG 0 0 0 eth0
bewan 10.0.0.20 255.255.255.0 UG 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 9-207-118-80 0.0.0.0 UG 0 0 0 ppp0

9-207-118-80 est la résolution de mon IP sur le web

pour ioda:
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 eth0
default ioda. 0.0.0.0 UG 0 0 0 eth0

Je réponds dans le même temps à TiChou:

Les paquets SYN et SYN/ACK ont été visibles par un LOG d'iptables avec
--log-tcp-options sur ioda (pas moyen d'installer quoi que ce soit
d'autre). Il n'y a que des LOG dans les tables du "pare-feu" de ioda,
tout le reste est en policy ACCEPT.

obiwan voit l'aller vers ioda mais pas le retour à l'aide d'ethereal qui
va scanner ma carte réseau eth0 (celle du LAN) en mode promiscuous, ce
que je pense devoir être un moyen de voir avant le pare-feu, non?

Lynx renvoie ceci:

Recherche www.google.fr
Connexion HTTP à www.google.fr
Alerte! : Impossible d'établir une connexion à l'hôte distant
lynx : accès impossible au fichier de départ http://www.google.fr/

traceroute sur google donne ça:
traceroute to 216.239.59.104 (216.239.59.104), 30 hops max, 38 byte packets
1 ioda (192.168.xxx.xx) 2998.578 ms !H 2998.172 ms !H 2999.348 ms !H

Il ne peut pas y avoir de DROP à mon niveau puisque le parefeu est
complètement ouvert à ce moment là:

/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P OUTPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport www -j DNAT
--to-destination 192.168.xxx.xx:80
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Les options de ioda (/etc/network/options) sont les suivantes:
ip_forward=no
spoofprotect=no
syncookies=no

Si j'ai bien tout compris, il semblerait qu'il n'y ait pas besoin de
ip_forward puisque rien n'a besoin d'être forwardé de cette machine et
que les règles iptables de LOG sont posées sur INPUT et OUTPUT et que je
vois parfaitement le trafic entrant et sortant.

Merci encore de vous pencher sur mon cas...

Dans le message <news:d7iscu$9c1$1@aphrodite.grec.isp.9tel.net>,
*Jean-Philippe* tapota sur f.c.o.l.configuration :

Les routes par défaut sont:
pour obiwan:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
9-207-118-80 * 255.255.255.255 UH 0 0 0 ppp0
localnet obiwan. 255.255.255.0 UG 0 0 0 eth0
bewan 10.0.0.20 255.255.255.0 UG 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 9-207-118-80 0.0.0.0 UG 0 0 0 ppp0

9-207-118-80 est la résolution de mon IP sur le web

La prochaine fois, lancez la commande route avec l'option '-n'.

pour ioda:
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 eth0
default ioda. 0.0.0.0 UG 0 0 0 eth0

ioda a pour passerelle sa propre adresse IP ? ça ne risque pas d'aller très
loin dans ce cas. ;-)
ioda doit avoir comme passerelle l'adresse de obiwan.

obiwan voit l'aller vers ioda mais pas le retour à l'aide d'ethereal qui
va scanner ma carte réseau eth0 (celle du LAN) en mode promiscuous, ce que
je pense devoir être un moyen de voir avant le pare-feu, non?

Oui.

Merci encore de vous pencher sur mon cas...

De rien.

--
TiChou

Bonjour

TiChou wrote:

Dans le message <news:d7iscu$9c1$1@aphrodite.grec.isp.9tel.net>,
*Jean-Philippe* tapota sur f.c.o.l.configuration :

Les routes par défaut sont:
pour obiwan:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
9-207-118-80 * 255.255.255.255 UH 0 0 0 ppp0
localnet obiwan. 255.255.255.0 UG 0 0 0 eth0
bewan 10.0.0.20 255.255.255.0 UG 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 9-207-118-80 0.0.0.0 UG 0 0 0 ppp0

9-207-118-80 est la résolution de mon IP sur le web

La prochaine fois, lancez la commande route avec l'option '-n'.

pour ioda:
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 eth0
default ioda. 0.0.0.0 UG 0 0 0 eth0

ioda a pour passerelle sa propre adresse IP ? ça ne risque pas d'aller
très loin dans ce cas. ;-)
ioda doit avoir comme passerelle l'adresse de obiwan.

Pas mieux.
Accessoirement, il n'y a pas de loopback(lo), ce qui n'est pas forcément une
erreur en soi.

obiwan voit l'aller vers ioda mais pas le retour à l'aide d'ethereal qui
va scanner ma carte réseau eth0 (celle du LAN) en mode promiscuous, ce
que je pense devoir être un moyen de voir avant le pare-feu, non?

Oui.

Merci encore de vous pencher sur mon cas...

De rien.

Ca doit aller mieux, maintenant.

--
Eric

Bonjour,

Je suis assez em...dé depuis quelque (trop de?) temps déjà avec une
machine qui n'arrive pas à joindre le net ni être accessible du net
(c'est un serveur web).

Mes machines qu'on appellera de la manière suivante en cette période
Starwars:
- ioda = un serveur web derrière une passerelle/parefeu
- obiwan = la passerelle/parefeu
Ces machines sont de même métal: debian 2.4.27-2-686

Equipement:
- DNS et parefeu (via iptables) sur obiwan
- Apache2 + Mysql sur ioda

Voilà en gros le comportement que j'observe et que je n'arrive pas à
résoudre. Il est assez homogène mais je n'arrive pas à trouver la
solution. Pour mes tests, j'ai utilisé ethereal, host, ping, les LOG
d'iptables et lynx et pour tous ces essais, j'ai ouvert le parefeu juste
pour l'occasion (policy ACCEPT partout et 2 seules règles: un MASQUERADE
en postrouting vers ppp0 et un DNAT en prerouting vers ioda sur la table
nat):

- en contactant ioda du web, la machine reçoit les SYN et renvoie les
SYN/ACK; obiwan ne voit que l'aller, pas le retour

- ioda contacte bien obiwan par ARP et la résolution MAC fonctionne (vu
par ethereal)

- ioda résoud bien les hosts par le DNS sur obiwan mais n'arrive pas à
accéder au web par une commande lynx sur google par exemple, aucune
trace par ethereal de cette tentative de connexion

- impossible d'installer quoi que ce soit par apt-get, évidemment

- je peux pinger toute adresse LAN sans problème mais pinger une IP
google à partir de ioda me renvoie ça par exemple:
PING 216.239.59.104 (216.239.59.104) 56(84) bytes of data.
From ?.?.?.? icmp_seq=1 Destination Host Unreachable
From ?.?.?.? icmp_seq=2 Destination Host Unreachable
From ?.?.?.? icmp_seq=3 Destination Host Unreachable

- obiwan, lui, ne renvoie rien (sûrement un "-p icmp -j DROP" à l'autre
bout):
PING 216.239.59.104 (216.239.59.104) 56(84) bytes of data.
--- 216.239.59.104 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7016ms

- 2 autres machines (mdk) sur ce LAN accèdent sans aucun problème au web...

Pour moi, le problème vient de ioda (serveur web) et non pas de obiwan
(passerelle/parefeu), me trompé-je?
Quelqu'un a-t-il déjà eu ce genre de problème?
Une idée pour résoudre ce sac de noeuds?

Merci

Fais nous un dump de tes tables de routage car il est clair que le pbm
vient en partie de la !

@ ++


--
Faire reagir les cons, c ce ki demande le + d'intelligence!

Eric Dorino wrote:

Bonjour

*Jean-Philippe* tapota sur f.c.o.l.configuration :

Les routes par défaut sont:
pour obiwan:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
9-207-118-80 * 255.255.255.255 UH 0 0 0 ppp0
localnet obiwan. 255.255.255.0 UG 0 0 0 eth0
bewan 10.0.0.20 255.255.255.0 UG 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 9-207-118-80 0.0.0.0 UG 0 0 0 ppp0

9-207-118-80 est la résolution de mon IP sur le web

La prochaine fois, lancez la commande route avec l'option '-n'.

pour ioda:
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 eth0
default ioda. 0.0.0.0 UG 0 0 0 eth0

ioda a pour passerelle sa propre adresse IP ? ça ne risque pas d'aller
très loin dans ce cas. ;-)
ioda doit avoir comme passerelle l'adresse de obiwan.

Pas mieux.
Accessoirement, il n'y a pas de loopback(lo), ce qui n'est pas forcément une
erreur en soi.

Ca doit aller mieux, maintenant.

Ben voui merci, j'ai honte de n'avoir pas vu ce qui crevait les yeux,
même si c'est un grand classique en info...