Windows 10 - 網路時間同步錯誤 - 逾時

Windows 10 - 網路時間同步錯誤 - 逾時

我家有 Airtel (ISP) 寬頻。同一個 ISP 也是我的行動網路供應商。我有 DIR 615 路由器連接到 Airtel 寬頻、Windows 10 桌上型電腦和筆記型電腦。

當我使用 Airtel 寬頻時,兩台 Windows 10 PC 都無法與各種互聯網 NTP 伺服器同步時間。它返回超時。我已經嘗試過超過 10 – 12 個 NTP 伺服器。然而,其他裝置(例如我的 Linux VM 以及 DIR 615 路由器)能夠在相同的寬頻上與相同的 NTP 伺服器正確同步時間。然而,當我在 Windows 10 上切換到 VPN 並繞過 ISP 時,Windows 10 PC 能夠成功地與各種 NTP 伺服器同步時間。

此外,當我使用 Nistime32bit.exe 等第三方應用程式時,它們會成功與 Airtel Broadband 上同一台 Windows 10 PC 上的 NTP 伺服器同步時間。我已經嘗試過 TCP 13 和 UDP 123 連接埠。現在,當我使用 Airtel 行動熱點時,兩台 Windows 10 電腦都能正確同步時間,不會出現任何逾時錯誤。很難相信 ISP 會阻止出站端口,因為路由器和 Linux VM 在同一網路上正確同步,甚至 Windows 10 PC 上的第三方應用程式也能正確同步。然而,具有 Windows 10 內建進程的 Windows 10 電腦會出現錯誤。很難相信這兩個 Windows 10 作業系統都存在問題,因為它們在行動熱點上正確同步。 W32time 服務在兩台電腦上運作良好。

我向 ISP 尋求幫助,但他們沒有回應。

有人知道這裡到底發生了什麼事?我還可以嘗試排除哪些問題以及問題可能出在哪裡?我檢查了事件檢視器,這是一堆事件,但沒有發現任何有意義的內容。

路由器和 Windows 10 中的防火牆完全關閉。

在此輸入影像描述


看到評論和答案後編輯。

我已經嘗試了幾台伺服器,其中包括一些位於我所在國家/地區的伺服器,但行為是一致的。寬頻 - 失敗,VPN - 成功,行動熱點 - 成功。寬頻路由器 – 成功,寬頻 Linux VM – 成功。

謝謝@user1686 的詳細解答。這就是謎題中缺失的一環。

我國所有 ISP 的工作和行為都相同。它們都阻止低於 1024 的傳入連接埠。

我現在已經測試過,我的 ISP 確實透過發送魔術封包來遠端啟動我的 PC 來阻止 UDP 123 入站。當我發送它到 UDP 4000(路由到路由器中的 UDP 9)時,通過我的行動互聯網到寬頻公共 IP,它會喚醒,但在 UDP 123(路由到 UDP 9)上它會失敗。我還使用了一個名為 SimplePort Tester (PCWinTech.com) 的小型實用程式來重新檢查 UDP 123 入站確實無法存取。

我嘗試在 Windows XP 虛擬機器上進行時間同步,假設它可能使用較舊的 NTPv3,但它甚至無法在寬頻上同步時間。所以,看起來連當時的 XP 都在使用 123 < -- > 123。

我會說服我的 ISP 至少在一段時間內打開入站 UDP 123 進行測試,但他們根本不會考慮我的請求!

在此輸入影像描述

答案1

大多數 NTP 和 SNTP 用戶端都以「客戶端/伺服器」模式工作。這與其他 UDP 用戶端相同 – 電腦從臨時連接埠向伺服器的 NTP 連接埠 123 發送 NTP 查詢,並從連接埠 123 向該臨時連接埠取得回應。這很可能就是您的 Linux NTP 用戶端的行為。

然而,Windows 的內建 NTP 用戶端使用「對稱」模式,在該模式下傳送封包從本地端 123到伺服器的連接埠 123。

(這種對稱連接埠的使用對於 NTP 來說有些獨特,並且在兩個 NTP 伺服器相互同步時的點對點情況下更常見。我不確定 Windows 為什麼這樣做,但這可能是由於以下事實Windows Server 可以充當真正的NTP 伺服器,作為AD DC 功能的一部分。

但「對稱」模式的問題在於到網路防火牆,這些對連接埠 123 的入站響應與入站完全無法區分1要求到連接埠 123。

許多 ISP 部署網路級防火牆來阻止某些「有風險」的協議,例如那些容易被濫用用於 DDoS 放大的協議,而 NTP 不幸的是其中之一。因此,作為預防措施,ISP 可能會阻止所有入站到其客戶連接埠 123 的 UDP 封包,並錯誤地認為這只會阻止客戶運行 NTP 伺服器。

或者,ISP 可能會假設所有客戶都有帶有 NAT 的個人路由器,並且許多路由器實際上重新分配出站資料包的本地端口,因此即使計算機發送資料包 123→123,路由器也可能會將其轉換為61473→123 就不會出現這個問題了。然而,並非所有路由器都會進行這種重新映射(這種類型的 NAT 通常會幹擾遊戲)。

建議:

  • 如果您的路由器允許您在「Cone NAT」和「Symmetric NAT」之間進行選擇,請嘗試切換到後者,看看是否有幫助(沒有,該術語實際上與對稱 NTP 完全無關)。

  • 否則,您可能需要繼續使用第三方 NTP 用戶端,它們在客戶端模式下運行,不會出現此問題。

  • 有一個微軟知識庫文章關於指定要使用的模式,但雖然它會影響 NTP 標頭中的模式位,但它確實不是實際上讓 Windows 使用不同的來源連接埠。不幸的。

    (NTPv3 確實指定來源連接埠必須不是在客戶端模式下為 123,但 NTPv4 不再禁止這樣做,因此這可能是為什麼 Windows 樂意使用 123→123,無論 NTP 標頭中指定了什麼模式標誌。


1狀態防火牆,例如家用路由器上的防火牆,透過追蹤以前看到的出站資料包來區分查詢和回應。但是,雖然狀態防火牆在較小的網路邊界上很常見,但我懷疑它們不容易擴展到「整個 ISP」級別,因為查找每個資料包的狀態意味著效能下降。因此,如果 ISP 運營無國籍的防火牆,該聲明仍然正確 - 兩種 NTP 封包在對稱模式下變得無法區分。

相關內容