Sujet Précédent Sujet Suivant

Socket timeout after 10 seconds

Résolu/Fermé
Messages postés
877
Date d'inscription
samedi 26 septembre 2009
Statut
Membre
Dernière intervention
4 août 2017
 -
Messages postés
30564
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
25 janvier 2022
 -
Bonjour!

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 
log_facility=@log_facility@

pid_file=/var/run/nrpe.pid

server_port=5666

nrpe_user=@nrpe_user@

nrpe_group=@nrpe_group@

allowed_hosts=127.0.0.1,IP-Nagios

dont_blame_nrpe=1

debug=0

command_timeout=60

connection_timeout=300

command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 80 -c 90 /dev/
command[check_procs]=/usr/lib/nagios/plugins/check_procs
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 80 -c 90
command[check_swap]=/usr/lib/nagios/plugins/check_swap -w 90% -c 80%
command[check_mem]=/usr/lib/nagios/plugins/check_memuse.sh -w 80 -c 95



Pour vous donnez ma version Linux:
root# uname -a 
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 
Aug 8 14:10:54 g***-** kernel: [3914.834891] [UFW BLOCK] IN=eth0 OUT= MAC=******************************** SRC=IP_Nagios DST=IP_ServeurLocal LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=29974 DF PROTO=TCP SPT=43704 DPT=5666 WINDOW=5840 RED=0x00 SYN URGP=0


Le daemon:
root# ps -aux | grep nrpe 
****** 34511  0.0  0.0  23332  1104 ?        Ss   août03   0:10 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d


Puis le port:
root# netstat -an | grep 5666 
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN
tcp6       0      0 :::5666                 :::*                    LISTEN


Et bien voilà :) Je suis coincé sur ce syslog sans vraiment le comprendre..
J'espère ne pas vous avoir découragé.

Merci d'avance!
A voir également:

3 réponses

Réponse 1 / 3
Messages postés
30564
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
25 janvier 2022
 7 274
Bonjour,

Explication de ton problème

/etc/nagios/nrpe.cfg : 

allowed_hosts=127.0.0.1,IP-Nagios


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.

/var/log/syslog 

Aug 8 14:10:54 g***-** kernel: [3914.834891] [UFW BLOCK] IN=eth0 OUT=  MAC=******************************** SRC=IP_Nagios DST=IP_ServeurLocal LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=29974 DF PROTO=TCP SPT=43704 DPT=5666 WINDOW=5840 RED=0x00 SYN URGP=0


Cette ligne est écrite par ton pare-feu (
ufw
) 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.

Bonne chance
Réponse 2 / 3
Messages postés
30564
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
25 janvier 2022
 7 274
Merci pour ton retour :-)

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.

Bonne continuation !
Messages postés
877
Date d'inscription
samedi 26 septembre 2009
Statut
Membre
Dernière intervention
4 août 2017
 140
"jugés utiles pour le commun des mortels par les mainteneurs d'ubuntu"
J'adore!
Messages postés
30564
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
25 janvier 2022
 7 274
Ben :-) Il faut bien faut bien reconnaître que la syntaxe d'ufw est un peu plus intuitive que celle d'iptables ;-)
Réponse 3 / 3
Messages postés
877
Date d'inscription
samedi 26 septembre 2009
Statut
Membre
Dernière intervention
4 août 2017
 140
Bonjour,

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...
Posez votre question