主页 / server / 问题 / 1064319
Accepted
Martin Melka
Asked: 2021-05-22 05:40:57 +0800 CST

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

  • 772

我正在尝试为 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。因此，我得出结论，该服务每次尝试同步时都会尝试在随机端口上进行通信。

firewall port systemd-timesyncd

3 个回答

  1. Best Answer

    它确实使用临时端口。

    经过更多研究，我发现了这些：

    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 端口。这是设计使然。现在的问题变成了“如何在无状态防火墙上处理临时端口”/耸耸肩。

    • 3

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

    • 我的入站端口 123 未打开。
    • 不需要重新启动任何服务。

    结果/var/log/syslog：

    Debian 10：

    9 月 23 日 18:21:19 app 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)。

    • 2

  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类似于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

    请注意：如果这个答案在您的情况下并没有真正奏效，请知道我刚刚遇到了同样的问题。所以你非常接近真正的答案。最好的问候兄弟

    • 0

相关问题