Windows 10 - 互联网时间同步错误 - 超时

Windows 10 - 互联网时间同步错误 - 超时

我家里有 Airtel (ISP) 宽带。同一 ISP 也是我的移动网络提供商。我有连接到 Airtel 宽带的 DIR 615 路由器、Windows 10 台式机和笔记本电脑。

当我使用 Airtel 宽带时,两台 Windows 10 PC 都无法与各种 Internet NTP 服务器同步时间。它返回超时。我尝试了 10 到 12 个 NTP 服务器。但是,其他设备(如我的 Linux VM 以及 DIR 615 路由器)能够在同一宽带上与同一 NTP 服务器正确同步时间。然而,当我在 Windows 10 上切换到 VPN 并绕过 ISP 时,Windows 10 PC 能够成功地与各种 NTP 服务器同步时间。

此外,当我使用 Nistime32bit.exe 等第三方应用程序时,它们会成功与 Airtel 宽带上同一台 Windows 10 PC 上的 NTP 服务器同步时间。我已尝试使用 TCP 13 和 UDP 123 端口。现在,当我使用 Airtel 移动热点时,两台 Windows 10 PC 都会正确同步时间,不会出现任何超时错误。很难相信 ISP 阻止了出站端口,因为路由器和 Linux VM 在同一网络上同步正确,甚至 Windows 10 PC 上的第三方应用程序也是如此。然而,带有 Windows 10 内置进程的 Windows 10 PC 却出错了。很难相信这两个 Windows 10 操作系统都有问题,因为它们在移动热点上同步正确。W32time 服务在两台 PC 上运行良好。

我向 ISP 寻求帮助,但他们没有回应。

有人知道这里到底发生了什么吗?我还能尝试解决哪些问题以及问题可能出在哪里?我检查了事件查看器,它有很多事件,但没有发现任何有意义的东西。

路由器和 Windows 10 中的防火墙完全关闭。如果我绕过路由器并从我的 PC 直接建立 PPPoE 连接到 ISP,结果也是相同的。

在此处输入图片描述


看到评论和答案后进行编辑。

我尝试了多个服务器,包括位于我国的一些服务器,但行为一致。宽带 - 失败,VPN - 成功,移动热点 - 成功。宽带上的路由器 - 成功,宽带上的 Linux VM - 成功。

感谢@user1686 的详细回答。这正是谜题中缺失的一环。

我所在国家的所有 ISP 的工作方式和行为方式都相同。它们都阻止 1024 以下的传入端口。我印象中 NTP 同步是客户端到服务器的,但不知道 Windows 的对称 123 < -- > 123,因此即使是入站 123 也很重要。

我现在已经测试了我的 ISP 确实通过发送魔术包来远程启动我的 PC 来阻止 UDP 123 入站。当我通过我的移动互联网将其发送到 UDP 4000(在路由器中路由到 UDP 9)到宽带公共 IP 时,它会唤醒,但在 UDP 123(路由到 UDP 9)上它会失败。我还使用了一个名为 SimplePort Tester(PCWinTech.com)的小实用程序来重新检查 UDP 123 入站确实无法访问。

我尝试在 Windows XP VM 上进行时间同步,假设它可能使用的是较旧的 NTPv3,但它甚至无法同步宽带上的时间。所以,看起来当时的 XP 也使用 123 < -- > 123。

我会说服我的 ISP 至少在一段时间内开放入站 UDP 123 以进行测试,但他们考虑我的请求的可能性非常小!

在此处输入图片描述

答案1

大多数 NTP 和 SNTP 客户端都以“客户端/服务器”模式工作。这与其他 UDP 客户端相同 - 计算机从临时端口向服务器的 NTP 端口 123 发送 NTP 查询,并从端口 123 收到对该临时端口的响应。这很可能是您的 Linux NTP 客户端的行为方式。

然而,Windows 的内置 NTP 客户端使用“对称”模式,在该模式下,它会发送数据包来自本地端口 123到服务器的端口 123。同样,响应也从远程端口 123 到达本地端口 123。

(这种对称端口的使用在某种程度上是 NTP 所独有的,在两个 NTP 服务器相互同步的对等情况下更为常见。我不确定 Windows 为什么这样做,但这可能是因为 Windows Server 可以充当真正的 NTP 服务器,作为 AD DC 功能的一部分。)

但“对称”模式的问题是网络防火墙,这些到端口 123 的入站响应与入站完全无法区分要求到端口 123。

许多 ISP 部署网络级防火墙来阻止某些“危险”协议,例如那些容易被滥用来放大 DDoS 的协议,不幸的是 NTP 就是其中之一。因此,作为预防措施,ISP 可能会阻止所有进入其客户端口 123 的 UDP 数据包,错误地认为这只会阻止客户运行 NTP 服务器。

或者,ISP 这样做可能是假设所有客户都有带 NAT 的个人路由器,而且许多路由器实际上会重新分配出站数据包的本地端口 - 因此即使计算机发送数据包 123→123,路由器也可能将其转换为 61473→123,问题就不会发生。但是,并非所有路由器都会进行这种重新映射(这种类型的 NAT 通常会干扰游戏)。

建议:

  • 如果您的路由器允许您在“锥形 NAT”和“对称 NAT”之间进行选择,请尝试切换到后者,看看是否有帮助(不,该术语实际上与对称 NTP 完全无关)。

  • 否则,您可能需要继续使用第三方 NTP 客户端,它们以客户端模式运行并且不会出现此问题。

  • 微软知识库文章关于指定使用哪种模式,但尽管它会影响 NTP 标头中的模式位,但它确实不是实际上让 Windows 使用不同的源端口。不幸的是。

    (NTPv3 确实指定了源端口必须不是在客户端模式下为 123,但 NTPv4 不再禁止这样做,所以这可能是为什么 Windows 乐意使用 123→123,而不管 NTP 标头中指定了什么模式标志。)


1状态防火墙,例如家用路由器上的防火墙,通过跟踪之前看到的出站数据包来区分查询和响应。但是,虽然状态防火墙在较小的网络边界很常见,但我怀疑它们不容易扩展到“整个 ISP”级别,因为查找每个数据包的状态意味着性能降低。因此,如果 ISP 运营无国籍者防火墙,该说法仍然正确——在对称模式下,两种 NTP 数据包变得无法区分。

相关内容