我家里有 Airtel (ISP) 宽带。同样的 ISP 也是我的移动网络提供商。我将 DIR 615 路由器连接到 Airtel 宽带、Windows 10 台式机和笔记本电脑。
当我在 Airtel Broadband 上时，两台 Windows 10 PC 都无法与各种 Internet 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 PC 会出错。很难相信这两个 Windows 10 操作系统都存在问题，因为它们在移动热点上正确同步。W32time 服务在两台 PC 上运行良好。
我向 ISP 寻求帮助，但他们没有响应。
有谁知道这里到底发生了什么？我还可以尝试解决什么问题以及问题可能出在哪里？我检查了事件查看器，这是一堆事件，但没有发现任何有意义的东西。
防火墙在路由器和 Windows 10 中完全关闭。如果我绕过路由器并从我的 PC 直接 PPPoE 连接到 ISP，结果相同。
看到评论和回答后编辑。
我已经尝试了几台服务器，包括一些位于我的国家的服务器，但行为是一致的。宽带 - 失败，VPN - 成功，移动热点 - 成功。宽带路由器 – 成功，宽带上的 Linux VM – 成功。
谢谢@user1686 的详细解答。那是谜题中缺失的一环。
我所在国家/地区的所有 ISP 的工作方式和行为方式都相同。它们都阻止低于 1024 的传入端口。我的印象是，对于 NTP 同步，它是客户端到服务器，但不知道 Windows 的 Symmetric 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 进行测试，但他们根本不会考虑我的请求的可能性很小！
大多数 NTP 和 SNTP 客户端以“客户端/服务器”模式工作。这与其他 UDP 客户端相同——计算机从临时端口向服务器的 NTP 端口 123 发送 NTP 查询，从端口 123 向该临时端口返回响应。这很可能是您的 Linux NTP 客户端的行为方式。
然而，Windows 的内置 NTP 客户端使用“对称”模式，在这种模式下，它将数据包从本地端口 123发送到服务器的端口 123。响应同样从远程端口 123 到达本地端口 123。
（这种对称端口使用对于 NTP 来说有些独特，并且在两个 NTP 服务器相互同步时更常见于对等情况下。我不确定 Windows 为什么这样做，但这可能是由于事实作为 AD DC 功能的一部分，Windows Server 可以充当真正的 NTP 服务器。）
但“对称”模式的问题在于，对于网络防火墙，这些对端口 123 的入站响应与对端口 123 的入站请求完全无法区分1。
许多 ISP 部署网络级防火墙来阻止某些“有风险”的协议，例如那些容易被滥用用于 DDoS 放大的协议，不幸的是，NTP 就是其中之一。因此，作为预防措施，ISP 可能会阻止所有进入其客户端口 123 的 UDP 数据包，错误地认为这只会阻止客户运行 NTP 服务器。
或者，ISP 可能会假设所有客户都有带 NAT 的个人路由器，并且许多路由器实际上重新分配出站数据包的本地端口 - 因此即使计算机发送数据包 123→123，路由器也可能会将其转换为61473→123 不会出现问题。然而，并不是所有的路由器都会进行这种重新映射（这种类型的 NAT 通常最终会干扰游戏）。
建议：
如果您的路由器允许您在“Cone NAT”和“Symmetric NAT”之间进行选择，请尝试切换到后者，看看是否有帮助（不，该术语实际上与对称 NTP 毫无关系）。
否则，您可能需要继续使用第三方 NTP 客户端，它们在客户端模式下运行并且没有此问题。
有一篇关于指定使用哪种模式的 Microsoft知识库文章，但是虽然它会影响 NTP 标头中的模式位，但它实际上并没有使 Windows 使用不同的源端口。不幸的。
（NTPv3 确实指定源端口在客户端模式下不能为 123，但 NTPv4 不再禁止这样做，因此这可能是 Windows 愉快地使用 123→123 的原因，而不管 NTP 标头中指定了哪些模式标志。）
1有状态防火墙，例如家庭路由器上的防火墙，可以通过跟踪以前看到的出站数据包来区分查询和响应。但是，虽然状态防火墙在较小的网络边界上很常见，但我怀疑它们不容易扩展到“整个 ISP”级别，因为查找每个数据包的状态意味着性能下降。因此，如果 ISP 运行无状态防火墙，则该陈述仍然成立——两种 NTP 数据包在对称模式下变得无法区分。