systemd-timesyncd需要打开传入的临时端口。

Question

我正在尝试为Ubuntu服务器配置某种时间同步。服务器位于云提供商-无状态防火墙的后面。通过一些尝试和错误，我发现为了使ntp工作，我必须打开传入的UDP端口123。

然后我读到现在更喜欢使用systemd-timesyncd，所以我试着改用它。但这不起作用。服务日志中充满了

systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com).
systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.94.4:123 (ntp.ubuntu.com).

只有在我还白化了防火墙中短暂的UDP端口32768–65535之后，才开始工作：

systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

打开这个范围的端口是否真的是操作systemd-timesync所必需的？

编辑回应@耶稣-爱-你的回应如下。更高的端口不应该是必要的，但在我的例子中，由于某种原因，它们显然是必要的。请参阅systemd-timesync服务的日志(由我用#注释)：

# Before I enabled the 32786+ ports
May 21 11:49:21 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.198:123 (ntp.ubuntu.com).

# After I enabled the ports
May 21 11:49:06 myhost systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

# After I disabled them again. Note that there are no log entries inbetween for almost
# three days. This, imo, pretty much proves that the ports are required.
May 24 09:29:34 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.91.157:123 (ntp.ubuntu.com).

关于港口的进一步信息：

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:42212           0.0.0.0:*                           2656121/systemd-tim

看起来，42212是服务期望通信发生的端口。但是几分钟后，当下一个轮询发生时：

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:37240           0.0.0.0:*                           2656121/systemd-tim

现在港口变了。几分钟后，它又变成了51120。因此，我得出结论，每次尝试同步时，服务都会尝试在随机端口上进行通信。

Answer 1

它确实使用了临时端口.

在更多的研究中，我发现了这些：

SNTP (RFC 4330)，它允许(更常见的)临时源端口号

https://iec61850.tissue-db.com/tissue/630

IANA分配给NTP的UDP端口号是123。SNTP客户端应该在UDP目标端口字段中对客户端请求消息使用此值。这些消息的源端口字段可以是为标识或多路复用目的而选择的任何非零值。服务器将这些字段转换为相应的回复消息。这与RFC 2030的规范不同，后者要求源端口和目的端口都为123。

https://datatracker.ietf.org/doc/html/rfc4330#section-4

因此，这一切的答案似乎是，systemd-timesyncd正在实现SNTP协议，而不是NTP，因此使用的是短暂的源UDP端口。那是故意的。现在的问题变成了“如何处理无状态防火墙上的临时端口”/shrug。

Answer 2

我在Debian 10 "Buster“和Debian 11 "Bullseye”上所要做的就是打开出站UDP端口123。

• 我的入站端口123没有打开。
• 重新启动任何服务都是不必要的。

/var/log/syslog的结果：

Debian 10：

9月23日18:21:19 app systemd-timesyncd20076：第一次同步到时间服务器194.35.12.189:123 (0.debian.pool.ntp.org)

Debian 11：

9月23日18:25:21 post systemd-timesyncd418：时间服务器的初始同步65.21.190.104:123 (0.debian.pool.ntp.org)

Answer 3

我的确有同样的问题。这对我有用(如果您正在使用iptables)：

-A INPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate ESTABLISHED -j ACCEPT -A OUTPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

据我所知，systemd类似于ntp的客户端实现(https://wiki.archlinux.org/title/Systemd-timesyncd)，只是建立了一个传出请求，因此在您的情况下不应该进行进一步的调整。

根据https://www.ietf.org/rfc/rfc5905.txt的说法，必要的端口仍然是123 (UDP)。

所以回答你的问题，不，你提到的那些更高的端口，是不必要的。你一切都做得对

也许你只是错过了重新启动服务的机会？

sudo systemctl restart systemd-timesyncd systemctl status systemd-timesyncd.service timedatectl status

请注意:如果这个答案在你的情况下并不有效，那就知道我刚刚有了同样的问题。所以你非常接近真正的答案。向兄弟问好