背景介绍

先来看一个近期遇到的真实案例。某企业的IT运维同事反映，公司内部的办公电脑突然无法通过NTP协议同步时间了。这家公司用的是一条宽带专线。事情蹊跷的地方在于，不经过公司内部的路由（也就是让电脑直接连接光猫），时间同步就能恢复正常。

简单来说，就是两种情况的对比：

当路线是「专线光猫 → 公司路由 → 交换机 → 电脑」时，NTP同步失败；
而当路线变成「专线光猫 → 电脑」直连时，NTP同步却一切正常。

整网拓扑

了解一下这家公司的网络架构吧。拓扑是比较标准的三层模型：从出口路由器开始，依次连接核心交换机、汇聚层再到接入层。无线网络采用的是AC控制器配合面板AP的组网方案。整个网络设备都来自同一个主流品牌。

网络出口则部署了一条2000兆的宽带专线，完成了整个基础网络的搭建。拓扑结构如下图所示：

分析思路

面对这类PC时间同步故障，首要任务就是精准定位。既然是时间同步，那走的肯定是NTP协议，第一步就得确认时间服务器的地址是否能正常访问。顺着这个逻辑，排查思路可以归纳为三条：

第一，验证时间服务器的网络可达性；第二，如果请求发出去了，就在网络路径上抓包，看NTP报文丢在了哪个节点；第三，对比电脑直连光猫和经过路由上网这两种情况，排查是否存在异常流量挤占了NTP协议所需的资源。

排查分析

(1) 第一步：确认时间服务器可达性

在PC的时间同步设置页面，可以看到系统默认使用的服务器地址是 `time.windows.com`。二话不说，先ping一下看看。

结果显示，DNS解析正常，网络也是通的。这说明基本连通性没有问题。那么，怀疑的矛头就该指向出口路由器了：会不会是它的某些安全策略把NTP报文给误拦截了？

(2) 第二步：关闭出口路由相关防护功能观察

经验表明，一些网络设备内置的攻击防护或安全策略，有时可能会“误伤”正常的协议报文。现场的出口路由器也具备这类功能，于是尝试将其中的攻击防护选项暂时关闭。

关闭之后再次测试，时间同步依然失败。看来，问题可能并非出在路由器的拦截上。接下来，得用更直接的方法——抓包，看看NTP报文到底经历了什么。

(3) 第三步：抓包确认NTP报文交互

为了看清全貌，在现场同时监控了路由器内网侧（LAN）和互联网侧（WAN）的流量，并以IP地址为192.168.10.8的测试电脑为观察点。

先看【LAN侧抓包】结果：

再看【WAN侧抓包】结果：

对比两张图，结论非常清晰：NTP请求报文已经成功通过路由器的NAT转换，发送到了外网。但是，从WAN口并没有看到任何来自前端的NTP回复报文。这说明，报文丢在了公网线路上，路由器本身并无拦截行为。

(4) 第四步：确认内网是否存在异常流量

公网线路丢包，有时候也可能是内部网络存在异常大流量，导致出口拥堵引起的。顺着这个思路，和客户的IT深入沟通后，果然发现网络中有个别设备在偷偷跑PCDN（一种消耗大量上传带宽的服务）。

不过话说回来，如果整网带宽和性能充裕，通常不至于影响NTP这种小数据包的交互。为了排除干扰，还是让IT停止了这些PCDN服务。但测试下来，PC同步时间困难的情况依旧存在。综合所有排查信息，问题的根源已经非常明确了。

原理及解决方案

问题的根本原因，并非之前怀疑的路由器拦截，而是运营商提供的宽带专线本身出现了异常，未能正常响应NTP协议请求。

因此，最终的解决方案也很直接：将详细的排查过程和结论整理上报给网络运营商，由他们来检查和修复这条宽带专线的异常状态。