Tiempo de espera de socket después de 10 segundos

Resuelto
Ben' Mensajes publicados 1081 Estado Miembro -  
mamiemando Mensajes publicados 33228 Fecha de registro   Estado Moderador Última intervención   -
¡Hola!

Vengo a solicitar su experiencia para resolver un problema relacionado con la supervisión de una de mis máquinas. De hecho, mi servidor me responde: CHECK_Socket timeout after 10 seconds. Para decirlo claramente, no es nada atractivo. Debo mencionar que esto sucedió cuando reinicié el servidor, que es una VM bajo HyperV.

A continuación, mis registros y la configuración de Nagios en mi cliente:

El famoso 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


Para mostrarles mi versión de 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 


Para mostrarles los permisos aplicados a los archivos de configuración de Nagios:
root# ls -lr /etc/nagios/
total 100 -rw-r--r-- 1 nagios nagios 420 3 ago 09:00 nrpe_local.cfg drwxr-xr-x 2 nagios nagios 4096 13 ene 2014 nrpe.d -rw-r--r-- 1 nagios nagios 87268 3 ago 10:39 nrpe.cfg.save -rw-r--r-- 1 nagios nagios 660 8 ago 13:54 nrpe.cfg


Y aquí mi mayor interrogante, se trata de datos de red, pero francamente nunca había tenido que lidiar con un syslog así:
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


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


Luego el puerto:
root# netstat -an | grep 5666
tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN tcp6 0 0 :::5666 :::* LISTEN


Y eso es todo :) Estoy atrapado en este syslog sin realmente entenderlo...
Espero no haberles desalentado.

¡Gracias de antemano!

3 respuestas

mamiemando Mensajes publicados 33228 Fecha de registro   Estado Moderador Última intervención   7 940
 
Hola,

Explicación de tu problema

/etc/nagios/nrpe.cfg :

allowed_hosts=127.0.0.1,IP-Nagios


No sé desde dónde te estás conectando, pero ya esta IP da a entender que tu cliente debe estar en la misma máquina que el servidor para que este último le permita conectarse.

/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


Esta línea es escrita por tu firewall (
ufw
) y señala que un paquete, que llegó a través de eth0, emitido por IP_Nagios, con destino a IP_ServeurLocal, fue bloqueado (puerto de origen 43704, puerto de destino 5666, etc...)
https://doc.ubuntu-fr.org/ufw

Si esta línea corresponde a una conexión hecha por tu cliente, entonces:

1) el problema no proviene de la procedencia del cliente (cf lo que decía sobre nrpe.cfg)

2) el firewall está bloqueando el paquete emitido por tu cliente. Como el paquete fue bloqueado por el firewall antes de que llegara al servidor, el servidor no responde nada porque cree que no tiene nada que hacer. Así que el cliente espera pacientemente 10s una respuesta del servidor, y por desesperación, abandona con el mensaje de error
CHECK_Socket timeout after 10 seconds
.

En conclusión, el problema proviene de tu firewall, para el cual debes agregar una regla que permita que este tipo de paquetes circulen.

Para resolver tu problema

Si el cliente está en la misma máquina que el servidor, sería más prudente que se comunique a través de
127.0.0.1
, ya que de esta forma no se enfrentará a las mismas reglas en tu firewall. Es mejor que abrir el firewall y permitir potencialmente que cualquiera acceda al servidor nagios.

Si el cliente y el servidor no están en la misma máquina, sería bueno permitir solo la IP del cliente para realizar tal acceso (suponiendo que esta IP sea fija o esté en un rango de IPs fijas) para limitar los riesgos de intrusiones.

Buena suerte
1
mamiemando Mensajes publicados 33228 Fecha de registro   Estado Moderador Última intervención   7 940
 
Gracias por tu respuesta :-)

Aunque no entiendo la presencia de ufw en esta máquina...

Oh, no hay nada complicado, es solo que en Ubuntu, una serie de paquetes/herramientas están preinstalados porque los mantenedores de Ubuntu los consideran útiles para el público en general y
ufw
es uno de ellos. En Debian, por ejemplo, solo estaría instalado iptables.

¡Buena continuación!
1
Ben' Mensajes publicados 1081 Estado Miembro 142
 
"considerados útiles para el común de los mortales por los mantenedores de ubuntu"
¡Me encanta!
0
mamiemando Mensajes publicados 33228 Fecha de registro   Estado Moderador Última intervención   7 940
 
Ben :-) Hay que reconocer que la sintaxis de ufw es un poco más intuitiva que la de iptables ;-)
0
Ben' Mensajes publicados 1081 Estado Miembro 142
 
Hola,

¡Antes que nada, gracias por esta respuesta! ¡Bien merece algunos UP por su precisión!

El servidor Nagios está a distancia, se trata de un servidor aparte. Es verdad que puede ser innecesario invocar la IP localhost en el allowed_host, solo me permite probar los comandos localmente (generalmente). Así que lo he eliminado para dejar solo la IP del servidor Nagios.

La resolución del problema:

root# ufw allow 5666/tcp

Es dejar pasar los datos que transitan por el puerto 5666 (dedicado en los servicios al NRPE).

¡Y todo funciona!

¡Gracias de nuevo!
Hemos reparado el problema, y he aprendido algo.
Aunque no entiendo la presencia de ufw en esta máquina...
0