☰

ntpd 在 0.0.0.2 上收到“连接：无效参数”

tag-icon • tag-icon ip-address ntpd
ntpd 在 0.0.0.2 上收到“连接：无效参数”

看来pool.ntp.org的回复最近发生了变化。这让我的CentosOS 6 ntp服务器不高兴。

$ host pool.ntp.org
pool.ntp.org has address 0.0.0.2
pool.ntp.org has address 83.209.8.142
pool.ntp.org has address 130.236.254.17
pool.ntp.org has address 195.178.181.98

$ /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org
can't create socket connection#

$ strace -f /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org
...
connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("130.236.254.17")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("195.178.181.98")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("0.0.0.2")}, 16) = -1 EINVAL (Invalid argument)
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6571c5b000
write(1, "can't create socket connection", 30can't create socket connection) = 30
exit_group(3)                           = ?
+++ exited with 3 +++

似乎对此有普遍的共识，正如现代 Ubuntu 所说：

$ ping 0.0.0.2
connect: Invalid argument

我认为 0.0.0.2 是一个有效的 IP？

更新

该问题确实是周期性的，并且已持续了好几天（根据我的 nagios，自 2015-12-20 以来）：

[12:40] host pool.ntp.org
pool.ntp.org has address 194.71.144.71
pool.ntp.org has address 79.136.86.176
pool.ntp.org has address 83.209.8.142
pool.ntp.org has address 178.73.198.130
[13:09] host pool.ntp.org
pool.ntp.org has address 194.71.144.71
pool.ntp.org has address 0.0.0.2
pool.ntp.org has address 178.73.198.130
pool.ntp.org has address 192.36.143.130

我猜想正在进行某种排名之争。

更新2

对于那些感兴趣的人，当从瑞典查询pool.ntp.org 的 DNS RR 时就会发生这个问题。

答案1

全部0.0.0.0/8都是保留的，因此这肯定不是 ntp 服务器的有效 IP。您可以检查IANA 注册了解更多信息。

您应该提交一些错误报告。一个反对pool.ntp.org，因为他们应该在允许 IP 地址进入池之前验证其有效性。另一个反对check_ntp_time，因为即使出现无效地址，它也不会死机。相反，它应该尝试它获得的三个有效 IP 地址。

答案2

您列出的四台服务器中，三台在池中，并且具有有效的服务器监控页面：

http://www.pool.ntp.org/scores/83.209.8.142

http://www.pool.ntp.org/scores/130.236.254.17

http://www.pool.ntp.org/scores/195.178.181.98

另一个是非法的，它不具备以下条件：

http://www.pool.ntp.org/scores/0.0.0.2

正如 kasperd 所指出的，该 A 记录上返回的 RR 是循环负载平衡的，因此我们无法判断您的上游 DNS 是否对您撒谎，或者非法地址是否暂时进入了池中。根据我作为池管理员的经验，我知道，服务器必须具有高可用性，从而得到监控系统的良好评分，才能被纳入池中。因此，我个人怀疑无法访问的地址能否进入池中，并怀疑这是上游 DNS 故障。但除非您能可靠地重现结果，否则我怀疑我们永远不会知道。

我突然想到，如果pool.ntp.org使用 DNSSEC 签名，我们就能立即判断这是缓存中毒问题还是池中垃圾问题。如果我有几分钟的空闲时间，我可能会在池服务器管理员列表中提出这个问题。

编辑：我已经提出了这个问题在管理员列表中，并且已经有一个独立的确认，这个地址做似乎正在进入游泳池，尽管它显然不应该。我想，请关注这个空间。

编辑2： 显然，这是一个真正的错误，现已修复。我同意 kasperd 的观点，值得督促插件的作者使插件对池中的垃圾更加健壮。

答案3

0.0.0.2 本身是“有效的”，但只能用作来源地址根据RFC1700因此你无法 ping 通它。

相关内容