.png)
我有一个基于 Ubuntu 16.04 的 Docker 容器，它运行 ntpd 4.2.8 服务。容器实例化后，我发布了端口 123/udp。
从 LAN 上的主机或其他计算机，我可以用来ntpq -p <container_host>获取对等点列表和同步状态。但使用collectd监控它或运行ntpdc -c kerninfo <container_host>失败/超时。这让我很困惑！
我已经在容器内测试了它，有一些合理的restrict陈述，也没有任何合理的陈述。但在这两种情况下我都超时了。在容器中运行 tcpdump（将其提升到特权容器后）显示 UDP 数据包已到达，但没有任何响应。当然，使用 tcpdump 在使用正在运行的 ntpq 时我会看到请求和响应。
如果我使用相同的 ntp.conf 文件直接在主机上运行 ntpd 服务器，则ntpdc -c kerninfo <container_host>主机和我授权的 LAN 上的其他计算机上的 ntpd 和collectd 都会成功！但是，主机仍在运行旧版本的 Ubuntu (14.04)，该版本附带 ntp 4.2.6。
所以唯一的区别是 Docker 网络（据我所知是 NAT）和 ntp 版本（4.2.6 与 4.2.8）。但 ntp.org 文档并未提及任何有关 NAT 或 4.2.8 更新的内容。那么我的命令超时是否只是因为客户端与服务器位于不同的子网（由于 NAT）？或者 4.2.8 中发生了一些变化？
注意：我的容器映像基于运行 ntpd 的 ubuntu:16.04[电子邮件受保护]（来自 Ubuntu 官方存储库）。主机运行Ubuntu 14.04，运行4.2.6p5。
PS：即使所有的restrict语句都正确，Collectd提交的命令相当于ntpdc -c kerninfo <container_host>ntpd在容器中运行时超时。
更新：我忘了提及，我还在容器内运行了 ntpd，并-ddd可以选择获取更详细的输出。记录的唯一相关数据是：
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
更新2：找到解决方案后，我更改了问题，希望其他遇到同一问题的人在搜索时可以更好地找到问题/答案。我还纠正了一个错误，我以为主机运行的是 Ubuntu 16.04，但实际上它仍在运行 14.04。
答案1
我解决了我的问题。该错误是由于 ntp 4.2.8 弃用（并默认禁用）该工具ntpdc及其所使用的通信模式（又名 mode7）所致。
从ntp 4.2.8及更高版本开始，ntpq应使用该工具代替ntpdc。它现在支持与 ntpdc 相同的命令。这样我就可以ntpq -c kerninfo <container_host>成功运行了。该ntpq命令使用不同的模式（也称为 mode6）进行通信。
在 ntp 4.2.8 中，仍然可以重新启用模式7，以支持与尚未迁移的工具的兼容性。必须在 中添加以下行/etc/ntp.conf：
enable mode7
然而，人们应该非常小心这一限制。看来，启用 mode7 并让 ntpd 服务器过于开放，可用于进行 DDoS 放大攻击。我目前在 Ubuntu 上使用 IPv4 和 IPv6 的默认限制，即 -我认为- 阻止使用此模式：
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
由于collectd仅支持mode7（请参阅问题 #932），我决定在容器内的配置中重新启用此模式。只要 ntp 支持重新启用此模式，此更改应该可以解决 Collectd 无法在 Ubuntu 16.04（或任何使用 ntp 4.2.8+ 的发行版）上监视 ntpd 的问题。
注意：为了让人们在遇到此问题时更好地找到解决方案，我将编辑该问题，以减少有关 NAT 的误导，我认为这最初是根本原因。