systemd-timesyncd 需要打開傳入的臨時埠

我正在嘗試為 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。因此，我得出結論，該服務每次嘗試同步時都會嘗試在隨機埠上進行通信。

它確實使用臨時埠。

經過更多研究，我發現了這些：

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 埠。這是設計使然。現在的問題變成了“如何在無狀態防火牆上處理臨時埠”/聳聳肩。

引用自：https://serverfault.com/questions/1064319