Je viens solliciter vos expertises afin de répondre à mon problème lié à la supervision d'une de mes bécanes. En effet, mon serveur me répond: CHECK_Socket timeout after 10 seconds. Autant dire que c'est pas sexy. Il faut savoir que c'est arrivé lorsque j'ai redémarrer le serveur qui est une VM sous HyperV
Ci-dessous mes logs et ma configuration Nagios sur mon client:
Le célèbre NRPE.conf: root# cat /etc/nagios/nrpe.cfg
Linux g*.*.* 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Pour vous montrer les droits appliquer sur les fichiers de conf Nagios: root# ls -lr /etc/nagios/
total 100
-rw-r--r-- 1 nagios nagios 420 août 3 09:00 nrpe_local.cfg
drwxr-xr-x 2 nagios nagios 4096 janv. 13 2014 nrpe.d
-rw-r--r-- 1 nagios nagios 87268 août 3 10:39 nrpe.cfg.save
-rw-r--r-- 1 nagios nagios 660 août 8 13:54 nrpe.cfg
Et là ma plus grosse interrogation, il s'agit bien de données réseaux, mais très franchement je n'ai jamais eu à faire à un syslog pareil: root# tail -f /var/log/syslog
Je ne sais pas d'où tu te connectes, mais déjà, cette IP laisse penser que ton client doit être sur la même machine que le serveur pour que le serveur le laisse s'y connecter.
) et signal qu'un paquet, arrivant par eth0, émise par IP_Nagios, à destination de IP_ServeurLocal a été bloqué (port source 43704, port destination 5666 etc...)
https://doc.ubuntu-fr.org/ufw
Si cette ligne correspond à une connexion faite par ton client, alors :
1) le problème ne vient pas de la provenance du client (cf ce que je disais sur nrpe.cfg)
2) le pare-feu bloque le paquet émis par ton client. DComme le paquet a été bloqué par le pare-feu avant que celui-ci n'atteigne le serveur, le serveur ne répond rien car il croit qu'il n'a rien à faire. Du coup, le client attend patiemment 10s une réponse du serveur, et de désespoir, abandonne avec le message d'erreur
CHECK_Socket timeout after 10 seconds
.
En conclusion, le problème vient de ton pare-feu, pour lequel tu dois ajouter une règle qui autorise ce genre de paquet à circuler.
Pour résoudre ton problème
Si le client est sur la même machine que le serveur, il serait plus avisé qu'il le contacte via
127.0.0.1
, car il ne sera alors pas confrontés aux mêmes règles dans ton pare-feu. C'est mieux que d'ouvrir le pare-feu et permettre potentiellement à quiconque d'accéder au serveur nagios.
Si le client et le serveur ne sont pas sur la même machine, il serait bon de n'autoriser que l'IP du client a faire un tel accès (en admettant que cette IP soit fixe ou dans une plage d'IP fixe) afin de limiter les risques d'intrusions.
Même si je ne comprends pas la présence de ufw sur cette machine...
Oh rien de bien compliqué, c'est juste que sous ubuntu, un certain nombre de paquets/outils sont pré-installés car jugés utiles pour le commun des mortels par les mainteneurs d'ubuntu et
ufw
en fait partie. Sous debian seul iptables serait installé par exemple.
Tout d'abord merci pour cette réponse! Elle mérite bien quelques UP pour sa précision.
Le serveur Nagios est distant, là il s'agit bien d'un serveur à part. Il est vrais qu'il peut être inutile d'invoquer sur le allowed_host l'IP localhost, ça me permet juste de tester les commandes en local (généralement). Je l'ai donc supprimé pour ne laisser que l'IP du serveur Nagios.
La résolution du problème:
root# ufw allow 5666/tcp
Soit laisser passer les data qui transite par le port 5666 (Dédié dans les services au NRPE).
Et tout fonctionne!
Merci encore!
On a réparer le problème, et j'ai appris quelque chose.
Même si je ne comprends pas la présence de ufw sur cette machine...
