我正在尝试为 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吗？
编辑以回应@Jesus-Loves-You 的回复。更高的端口不应该是必要的，但就我而言，出于某种原因，它们显然是必要的。查看服务日志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。因此，我得出结论，每次尝试同步时，服务实际上都会尝试在随机端口上进行通信。
答案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 端口。这是设计使然。现在的问题变成了“如何在无状态防火墙上处理临时端口”/耸耸肩。
答案2
我在 Debian 10 “Buster” 和 Debian 11 “Bullseye” 上所要做的就是打开出站 UDP 端口 123
- 我的入站端口123未打开。
- 无需重新启动任何服务。
结果是/var/log/syslog：
Debian 10：
9 月 23 日 18:21:19 应用程序 systemd-timesyncd[20076]: 首次同步到时间服务器 194.35.12.189:123 (0.debian.pool.ntp.org)。
Debian 11：
9 月 23 日 18:25:21 发布 systemd-timesyncd[418]: 初始同步至时间服务器 65.21.190.104:123 (0.debian.pool.ntp.org)。
答案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-timesyncd类似于客户端实现（https://wiki.archlinux.org/title/Systemd-timesyncd）NTTP 协议只需建立一个传出请求，这样应该您的情况无需进一步调整。
根据 https://www.ietf.org/rfc/rfc5905.txt，所需端口仍为端口号 123 (UDP)
所以回答你的问题，不，你提到的那些更高的端口是不是必要的。你做对了一切
也许您只是错过了服务重启？
sudo systemctl restart systemd-timesyncd systemctl status systemd-timesyncd.service timedatectl status
请注意：如果这个答案对你的情况不起作用，要知道我刚刚也遇到了同样的问题。所以你离真正的答案已经很近了。兄弟，祝你好运