主页 / server / 问题 / 744958
Accepted
Bittrance
Asked: 2015-12-24 03:45:46 +0800 CST

ntpd 在 0.0.0.2 上获得“连接：无效参数”

  • 772

看来 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 时会出现此问题。

ip-address

3 个回答

  1. Best Answer

    所有的0.0.0.0/8都是保留的，所以这绝对不是 ntp 服务器的有效 IP。您可以查看IANA 注册表以获取更多信息。

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

    • 12

  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 的观点，即值得追随插件的作者，以使插件更加健壮，可以在池中胡扯。

    • 10

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

    • 1

相关问题