Connection refusée avec check_nt

[kharfud]

Bonjour,
Cela fait trois jours que je passe mon temps à écumer les forums pour trouver la réponse à mon problème. En désespoir de cause, je me tourne vers la communauté.

J'ai une passerelle Linux (Mandriva2007.0 kernel 2.6.17-13) depuis laquelle je veut monitorer un serveur Windows 2003 avec check_nt.
Sur le serveur Windows, j'ai installé NC_Net et bien fait attention que la config soit lockée en checks actifs. Le service tourne. Pas de service NSClient. Port de communication : 1248
Sur la passerelle Linux j'ai compilé le check_nt comme il faut.
Il n'existe aucun parefeu sur le serveur Windows, et celui de la passerelle ne bloque absolument pas la communication avec le serveur.

Voici ce que j'obtient (avec ou sans -s):
[root@parefeu plugins]# ./check_nt -H 192.168.0.253 -p 1248 -v CPULOAD -l 5,80,90
Connexion refusée
could not fetch information from server

Quelqu'un aurait une idée?

PS: j'ai auparavant testé NSClient++ mais je me suis heurté au meme probleme. Ne trouvant aucune solution au probleme je me suis tourné vers NC_Net. La conclusion partielle serait que le probleme vient de check_nt, non ?

[kharfud]

Petite précision : le SP2 de windows 2003 est installé sur le serveur. Est-ce que mes blocages pourraient venir d'une quelconque stratégie de sécurité microsoft intégrée au SP2 ???

[kharfud]

Bon. Dans la série je réponds moi-meme a mes questions, je viens de tester check_nt et NC_net sur le réseau d'un autre de mes clients, avec exactement la meme configuration logicielle (Mandriva 2007.0 et WIndows 2003). Check_nt me remonte ce que je lui demande, pas de souci... J'ai donc un probleme d'une autre nature sur le premier réseau (ou par ailleurs j'ai déjà un souci bizarre d'un autre genre entre serveur Windows et passerelle Linux....).

[KOOL]

Par défaut NC_net utilise le mot de passe "None" essais de rajouter l'option "-s None" à ta commande de check. Tu peux modifier le mot de passe dans le fichier startup.cfg sur le serveur supervisé. Toujours dans le fhichier startup.cfg tu as l'option suivante "active_ip_accept_list" qui doit etre à false sinon tu peux ajouter les adresse ip du serveur de supervision dans le fichier prévu à cette effet.

[kharfud]

Merci pour les infos KOOL, mais je savais déjà tout ca^^
De plus, tout marche bien sur un réseau et pas sur l'autre, avec la meme configuration, mais l'un des deux est vraisemblablement infecté par un Gremlin, vu les autres soucis que j'y rencontr, je ne vois que ca... Et finalement j'ai trouvé ce qui coinçait : mon serveur à monitorer avait changé d'adresse IP... j'aurais pu chercher longtemps !
Donc tout va bien, en fin de compte.

Merci a tous pour votre contribution.

Dossier clos.