Collectd no puede monitorear ntpd 4.2.8 (Ubuntu 16.04)

Question

Tengo un contenedor Docker basado en Ubuntu 16.04 que ejecuta el servicio ntpd 4.2.8. Al crear una instancia del contenedor, publiqué el puerto 123/udp.

Desde el host u otra computadora en la LAN, puedo usarlo ntpq -p <container_host>para obtener la lista de pares y el estado de sincronización. Pero monitorearlo usando Collectd o ejecutando ntpdc -c kerninfo <container_host>fallas/tiempos de espera. ¡Y esto me está desconcertando!

Lo probé dentro del contenedor con algunas restrictdeclaraciones razonables y también sin ninguna. Pero en ambos casos se me agota el tiempo de espera. Al ejecutar tcpdump en el contenedor (después de elevarlo a contenedor privilegiado) se muestra que llega el paquete UDP, pero no se responde nada. Por supuesto, al usar tcpdump veo tanto la solicitud como la respuesta cuando uso ntpq, que está funcionando.

Si ejecuto el servidor ntpd en el host directamente, usando el mismo archivo ntp.conf, ntpdc -c kerninfo <container_host>tanto el servidor como el recopilado funcionan correctamente desde el host y otras computadoras en la LAN que autoricé. Sin embargo, el host todavía ejecuta una versión anterior de Ubuntu (14.04) que se envía con ntp 4.2.6.

Entonces, las únicas diferencias son la red Docker (NAT, según tengo entendido) y la versión ntp (4.2.6 frente a 4.2.8). Pero la documentación de ntp.org no menciona nada realmente sobre NAT ni sobre las actualizaciones 4.2.8. Entonces, ¿el tiempo de espera de mi comando se agota solo porque el cliente está en una subred diferente a la del servidor (debido a NAT)? ¿O como algo cambió en 4.2.8?

Nota: la imagen de mi contenedor está basada en ubuntu:16.04 que ejecuta ntpd[correo electrónico protegido](de los repositorios oficiales de Ubuntu). El host ejecuta Ubuntu 14.04 que ejecuta 4.2.6p5.

PD: Collectd envía un comando equivalente al ntpdc -c kerninfo <container_host>tiempo de espera cuando ntpd se ejecuta en el contenedor, incluso si todas las declaraciones de restricción son correctas.

Actualizar: Olvidé mencionar que también ejecuté ntpd dentro del contenedor con la -dddopción de obtener una salida más detallada. Los únicos datos relevantes que se registraron son:

read_network_packet: fd=19 length 192 from 192.168.1.3
receive: at 26 172.17.0.2<-192.168.1.3 flags 19 restrict 000

Actualización2: Después de descubrir la solución, cambié la pregunta con la esperanza de que otras personas que se toparan con el mismo problema puedan encontrar mejor la pregunta/respuesta al buscarla. También corregí un error: pensé que el host estaba ejecutando Ubuntu 16.04 pero en realidad todavía estaba ejecutando 14.04.

Answer 1

Resolví mi problema. El error se debe a que ntp 4.2.8 desaproba (y deshabilita de forma predeterminada) la herramienta ntpdcy el modo de comunicación que estaba usando (también conocido como modo7).

A partir de ntp 4.2.8 y versiones más recientes, la herramienta ntpqse utilizará en lugar de ntpdc. Ahora admite los mismos comandos que ntpdc. Entonces puedo ejecutar ntpq -c kerninfo <container_host>con éxito. El ntpqcomando utiliza un modo diferente (también conocido como modo6) para la comunicación.

Con ntp 4.2.8, todavía es posible volver a habilitar mode7 para admitir la compatibilidad con herramientas que aún no se han migrado. Se debe agregar la siguiente línea en /etc/ntp.conf:

enable mode7

Sin embargo, hay que tener mucho cuidado con la restricción. Parece que habilitar mode7 y dejar el servidor ntpd demasiado abierto podría usarse para realizar ataques de amplificación DDoS. Actualmente estoy usando la restricción predeterminada tanto para IPv4 como para IPv6 en Ubuntu, que:Creo- bloquea el uso de este modo:

restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

Como se recoge, solo admite mode7 (consultenúmero 932), decidí volver a habilitar este modo en mi configuración dentro del contenedor. Siempre que ntp admita volver a habilitar este modo, este cambio debería solucionar el problema de que Collectd no puede monitorear ntpd en Ubuntu 16.04 (o cualquier distribución que use ntp 4.2.8+).

Nota: para que las personas puedan encontrar mejor una solución si encuentran este problema, editaré la pregunta para que sea menos engañosa con respecto a NAT, que inicialmente pensé que era la causa principal.