ping qui rit, ping qui pleure... sous win32, ok sous linux!

par **informatique.vdg** » 07 Déc 2005 11:02

bonjour,

j'ai installé ipcop 1.4.10 sur ancien serveur p3 bi-proc 512Mo RAM
j'ai aussi ajouté squidguard et quelques binaires sympas come cutter, iftop, etc.

j'ai 3 machines connectées dessus à titre de test (on a déjà un firewall iptables basique bidouillé à partir d'une red hat 8). dans ces 3 machines il y a 1 winXP, 1 win98se et 1 ubuntu GNU/Linux.

mon souci est le suivant:
autant la machine sous ubuntu ne rencontre aucun problème, autant les machines windows semblent 'perdre' la connexion à ipcop : ping 192.168.3.1 <1ms tout le temps, puis... destination injoingnable X minutes. et puis ça repart, ping <1ms.
si je me logue sur ipcop et que je ping le client windose qui a perdu la connexion, ça marche et le client récupère la connexion illico.

bon toutes les machines sont sonnectées sur un ELS100 qui est en 192.168.2.x (plage ip connectée à l'ancien firewall), mais ça ne devrait pas poser de souci?

résumé de la config :
routeur du FAI : 192.168.1.1
interface verte ancien firewall 192.168.2.1
interface verte ipcop : 192.168.3.1

un coup de pouce SVP, je ne comprends pas pourquoi ça réagit comme ça!
et pis ça serait un peu barbare de faire un script qui va pinger tous les clients à intervalle régulier... il doit bien y avoir une solution propre, non?

par **Franck78** » 07 Déc 2005 18:01

Salut,
Une solution (propre ou non) règle un besoin particulier. Hors il y très longtemps que l'on a tout ce qu'il faut pour la couche réseau. Les outils de diag par exemple.
Alors le truc qui ping puis s'arrète 'tout seul' doit forcément être lié à un défaut quelquepars.

Plan précis, adresse IP et masques réseau, serveur DHCP ,....

on attend !

Avec des captures TCPDUMP aussi....

Bye

par **informatique.vdg** » 08 Déc 2005 13:00

bjour,

pourrais-tu préciser les infos qui t'intéressent?
ça fait à peu près 1 an que je suis sous linux mais je suis carrément noob au niveau admin réseau sous linux ;-)

---> internet
|
|
---------------
modem
---------------
|
---------------
routeur fai (il y a plusieurs ports: 1 pour ancien fw, 1 pour nouveau fw, 1 qui sert à zapper le firewall)
---------------
| - 192.168.1.1/255.255.255.0
|
| - 192.168.1.x (red)
---------------
vieux fw
---------------
| - 192.168.2.1/255.255.255.0 (green)
|
| - 192.168.2.xx
---------------
switch els 100
---------------
|
tous les clients - 192.168.2.x, adressage fixe

le nouveau fw est au même niveau que l'ancien, la différence est au niveau de l'adressage:
red nouveau : 192.168.1.x/255.255.255.0
green nouveau : 192.168.3.1/255.255.255.0
il est également relié sur l'ELS100. je compte tester avec les 3 clients 'test' connectés sur un élément actif en 192.168.3.x/255.255.255.0

on prévoit de passer en DHCP une fois que la mise en service du firewall ipcop sera 'validée'

à noter qu'il y a aussi quelques postes qui ont été configurés (par erreur ou suite à un ordre) en 192.168.1.1. bref on a quelques privilégiés qui zappent le firewall - cette anomalie disparaîtra dès que ipcop sera mis en prod.

comment je fais la capture tcpdump de sorte qu'elle te soit utile? sur quelle machine? (ipcop?) quelle interface? (green?) une option particulière dans la ligne de commande?

Ce qui m'intrigue c'est le pourquoi du comment du fonctionnement sans le moindre problème sous linux, alors que les bécanes en windows ont un fonctionnement bien plus hasardeux.

par **informatique.vdg** » 14 Fév 2006 14:02

alors tcpdump ça donne un output assez énorme, je vois pas trop comment l'exploiter. que chercher? des pistes?

sinon j'ai ajouté une vieille carte réseau isa 3com et reconfiguré ipcop pour que cette carte soit l'interface red (en lieu et place de l'interface intégrée qu'ipcop n'identifiait pas de la même façon quand je faisais "identifier/rechercher" plusieurs fois de suite)
bref avec la carte isa c'est mieux parce que je n'ai plus de paquets perdus, mais le pb de déconnexion perdure.
à part quelques collisions sur red, je ne vois pas le pb.

root@ipcop:~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:4B:59:91:54
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:171525 errors:0 dropped:0 overruns:0 frame:0
TX packets:32340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17655779 (16.8 MB) TX bytes:25191617 (24.0 MB)
Interrupt:18 Base address:0x2040

eth1 Link encap:Ethernet HWaddr 00:0A:5E:23:8E:E3
inet addr:192.168.1.43 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:87106 errors:0 dropped:0 overruns:0 frame:0
TX packets:33941 errors:0 dropped:0 overruns:0 carrier:0
collisions:435 txqueuelen:1000
RX bytes:35200594 (33.5 MB) TX bytes:5360127 (5.1 MB)
Interrupt:20

eth1 est reliée au routeur d'oléane(192.168.1.1), directement. (il y a 4 ports au $%#&! du routeur oléane)
192.168.1.0/255.255.255.0 est utilisé par de rares machines.
192.168.2.0/255.255.255.0 est l'environnement de prod 'normal', on passe par notre vieux fw en red hat.
192.168.3.0/255.255.255.0 l'environnement de test

toutes les machines sont en adressage fixe.

donc les symptomes c'est :
- tout ok, quelque soit l'OS.
- au bout d'un temps aléatoire, perte de connexion des clients (ne ping plus ipcop)
- quelques minutes sans intervention -> ça repart (parfois ça ne repart pas sans rebooter le client).

j'ai eu le pb avec un client linux aussi, mais 1 ou 2 fois seulement. généralement le client linux garde la connexion quand les clients windows ne touchent plus rien.
parfois un ping depuis ipcop sur le client récalcitrant règle le pb, des fois non.

plus fort, je peux avoir un client windows hors jeu mais un autre qui peut encore sortir sur le net dans le même temps (à reproduire pour confirmer que ce n'étati pas le hasard ou des circonstances à la con).

enfin bref je me demande si je vais pas laisser tomber ipcop, j'ai dans l'idée que c'est pas demain qu'il sera en prod et les critiques sur ce choix commencent à fuser :-/

par **informatique.vdg** » 14 Fév 2006 16:34

j'ai fait tourner arpwatch sur mon client linux et ya p'tet un souci pô prévu :

Message 793:
From arpwatch@x
Subject: flip flop eth1
Date: Tue, 14 Feb 2006 12:39:38 +0100 (CET)

hostname: <unknown>
ip address: 192.168.3.1
interface: eth1
ethernet address: 0:a:5e:23:8e:e3
ethernet vendor: 3com Corporation
old ethernet address: 0:10:4b:59:91:54
old ethernet vendor: 3com Corporation [3Com 3C905-TX PCI]
timestamp: Tuesday, February 14, 2006 12:39:33 +0100
previous timestamp: Tuesday, February 14, 2006 12:39:33 +0100
delta: 0 seconds

&
Message 794:
From arpwatch@x
Subject: flip flop eth1
Date: Tue, 14 Feb 2006 13:20:41 +0100 (CET)

hostname: <unknown>
ip address: 192.168.3.1
interface: eth1
ethernet address: 0:10:4b:59:91:54
ethernet vendor: 3com Corporation [3Com 3C905-TX PCI]
old ethernet address: 0:a:5e:23:8e:e3
old ethernet vendor: 3com Corporation
timestamp: Tuesday, February 14, 2006 13:20:41 +0100
previous timestamp: Tuesday, February 14, 2006 12:39:33 +0100
delta: 41 minutes

donc 'flip flop' entre les 2 cartes réseau d'ipcop? kesako?
à y regarder de plus près j'ai le même genre de messages concernant l'ancien firewall (interface 192.168.2.1 donc), mais sans les interruptions de service.

la config IP du client linux :
eth1 Lien encap:Ethernet HWaddr 00:14:22:0A:DB:CE
inet adr:192.168.3.100 Bcast:192.168.3.255 Masque:255.255.255.0
adr inet6: fe80::214:22ff:fe0a:dbce/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:276603 errors:0 dropped:0 overruns:0 frame:0
TX packets:65227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:82415963 (78.5 MiB) TX bytes:7491667 (7.1 MiB)
Adresse de base:0xdcc0 Mémoire:dfbe0000-dfc00000

eth1:1 Lien encap:Ethernet HWaddr 00:14:22:0A:DB:CE
inet adr:192.168.2.44 Bcast:192.168.2.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Adresse de base:0xdcc0 Mémoire:dfbe0000-dfc00000

la 2ème c'est un alias pour pouvoir toucher le réseau 'prod' en même temps.

par **informatique.vdg** » 14 Fév 2006 16:42

flip flop
The ethernet address has changed from the most recently seen address to the second most recently seen address. (If either the old or new ethernet address is a DECnet address and it is less than 24 hours, the email version of the report is suppressed.)

bref je ne suis pas avancé.

par **Franck78** » 21 Fév 2006 12:22

Hello,

Tu t'es mis sur la piste tout seul. Dès ton troisième post on aurait pu t'aiguiller !

donc les symptomes c'est :
- tout ok, quelque soit l'OS.
- au bout d'un temps aléatoire, perte de connexion des clients (ne ping plus ipcop)
- quelques minutes sans intervention -> ça repart (parfois ça ne repart pas sans rebooter le client).

Trouves simplement quelles machines possèdent ces cartes réseaux. Elles ont la même IP toutes les deux.

Code: Tout sélectionner: old ethernet address: 0:a:5e:23:8e:e3 old ethernet address: 0:10:4b:59:91:54 ip address: 192.168.3.1

par **informatique.vdg** » 23 Fév 2006 10:40

Trouves simplement quelles machines possèdent ces cartes réseaux. Elles ont la même IP toutes les deux.
Code:
old ethernet address: 0:a:5e:23:8e:e3
old ethernet address: 0:10:4b:59:91:54
ip address: 192.168.3.1

Merci pour ta réponse Franck mais c'est bien là le pb : ces cartes sont les interfaces red et green d'ipcop... donc c'est pas possible qu'elles aient la même ip! :-/

par **Franck78** » 23 Fév 2006 20:42

C'est deux cartes sur le même machine IPCop? Soit bourrin, change la machine ou les cartes réseaux. Tu es certain qu'elles ne sont pas branchées sur le même switch?

J'ai relu le début du topic, c'est pas vraiment clair. Supprimes le FW en paralèlle. Par ailleurs je ne vois pas comment zapper un FW en utilisant une 'mauvaise IP' si le FW est correctement placé dans le réseau.

En résumé, tu te compliques la vie et tu dois avoir une grosse erreur de cablage/adressage IP !!!

par **MoiCVincent** » 07 Mars 2006 17:24

par **informatique.vdg** » 31 Mars 2006 05:20

hello,
réponse tardive.

oui l'architecture est pourrie, [auto censure].
je laisse la place à d'autres et vais goûter à d'autres méthodes de travail, ailleurs.

merci pour vos réponses, c'était sympa de bidouiller ipcop ; à un de ces jours peut-être :-)

Fred.

ping qui rit, ping qui pleure... sous win32, ok sous linux!

ping qui rit, ping qui pleure... sous win32, ok sous linux!

arpwatch

flip flop

Qui est en ligne ?