MTU/MSS导致网站无法访问

MTU即最大传输单元（Maximum Transmission Unit），该 值 是TCP/IP协 议中的一个重要参数值，用于描述协议数据单元承载的有效数据大小。MSS（Maximum Segment Size，最大报文长度），是TCP协议定义的一个选项，MSS选项用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度。超过MSS值的TCP报文在传输过程终将会被分段。对于不同类型的网络，甚至同种类型网络中不同品牌网络设备默认定义MTU/MSS的大小都可能不同，设置合适的MTU/MSS值，可以解决部分“网站打不开”、“网速慢”等问题。本文就是由于一个典型的MTU/MSS值差异导致网站无法访问的典型案例。

网络结构

笔者单位的网络结构如图1所示，这是一个构建在共享网络上的星型VPN网络。核心路由器与每一个分支节点的接入路由器之间构建隧道模式的IPSec VPN网络，所有分支节点之间的通信均通过核心路由器中转，网络中主要承载数据业务和视频会商业务。为了便于业务管理和保证视频会商质量，将每一个节点的局域网划分为为20和30的两个VLAN，两个VLAN之间通过路由器以单臂路由形式互通。在核心路由器出接口配置服务质量控制，使视频会商业务能够拥有足够的带宽保证。

故障现象

由于工作需要，近来网络中新增了若干分支节点。为了减少兼容性问题，新增节点的网络设备也采用与现有设备统一品牌产品。但是，由于原有设备型号已经停产，只能选择该品牌设备的后续型号。

采购设备到货后，VPN很快就搭建完成。新增设备部署IPSec VPN时，除配置安全提议过程中有少数命令发生变化外，其余配置变化不大，这就是选择统一品牌设备组网的好处。新增分支节点网络中数据业务和视频会商业务均工作正常，但奇怪的是，中心节点始终无法通过网络访问分支节点的视频会商设备的Web管理页面。为排查问题，详细对比了新老设备构建VPN的安全提议、安全策略和默认参数配置，均未发现不同。在中心节点使用telnet工具连接新增分支节点的TCP 80端口，有正常响应。

故障分析

在这个组网方案中，新增节点与网络中原有节点的差异是造成视频设备Web管理页面无法访问的直接原因，这一点是十分明确的。解决这一故障的关键也在于找出新老节点之间的这种差异。

为了佐证上述判断，做一个简单的测试。由新增节点分别访问新老节点的视频设备Web管理页面，我们发现，无论是新旧节点，都无法远程访问新节点的视频设备Web管理页面。那么，在访问过程中到底发生了什么呢？这就需要用到抓包工具了。图2是访问新节点视频会商设备Web管理页面时的WireShark工具抓包截图。

通过抓包发现，此次Web访问过程中，完成了一次TCP三次握手，先后发出了两次http数据get请求，并得到了一次响应。第二次的get请求之后就发生了“Tcp Previous segment not captured”后续数据丢失，直至发送FIN指令终止连接。通过这次抓包可以看出，Web访问实际上在网络中已经发生，但是由于某种原因导致后续数据丢失，才造成了我们无法访问Web页面的事实。

为排除网络安全设备阻断HTTP数据传输的可能，我们做了一个试验。将一台视频会商设备直接接到核心路由器的一个以太网接口，并访问该设备的Web管理页面，发现可以正常访问Web页面。这就排除中心节点安全设备拦截了那些数据表的可能。

找出这些后续数据报文被拦截的位置，是查找问题的一条途径。由于IPSec VPN采用的是隧道模式，数据在隧道中传输过程中是被加密的，很难定位数据报文被拦截的准确位置。另一条途径就是通过两次http请求后响应数据报文的差异，来分析后续数据报文被丢弃的原因。

通过对TCP协议的摘要信息进行比较，除了索引号外，最大区别就在于TCP数据报文长度。第一次响应的TCP数据报文大小为451，而被丢弃的数据报文是1460。接下来出场的就是ping工具，格式为“ping -f -l[承载数据大小] IP地址 ]”，“-f” 参数强制 ICMP协议数据负载不会被拆分。经过反复尝试，发现承载数据为1415是一个分界点。

只有小于等于1415的负载能够通过VPN网络。而在原有分支节点和中心节点网络中，这个分界点是1472。有了这一结论，尝试对视频会商设备的MTU进行修改，将其改为1400，再访问其Web，果然管理页面正常打开了。

修改视频设备MTU值起到了限制承载数据大小的目的，但这不是问题的症结，问题仍在新增加的路由器上。因为我们不能每次增加一个设备都去调整设备的MTU值，这样太不人性化了。MTU只是规定了这个设备的TCP数据报最大负载，只有像使用ping -f时明确配置了报文不分段的情况下，超过协商值的数据报文将会被丢弃。

显然，视频会商设备的Web页面不太可能进行这种配置，那么问题就很可能出现在报文分段尺寸上。默认情况下，MSS值通常被设为1460，即超过载荷超过1460bit时数据报文将会在进行IP封装时被分段。我们之前使用Wireshark进行抓包比较时也发现，被丢弃的数据报文大小一致。试想，如果以1460的MSS来拆分TCP报文，那么产生的IP报文将无法通过载荷只有1415bit的IPSec隧道。这也能够解释为什么客户端和服务器之间完成了TCP协议的三次握手和HTTP协议的两次get通信，并在报文丢失后发送了FIN信号终止连接。因为，这些报文承载数据长度都很小，远远没有达到1415bit的最大传输单元的尺寸。

为什新增分支节点可以访问原有节点的Web管理页面呢？我想那是因为原有设备的最大分段长度是小于1415的，产生的分段报文能够正常通过隧道。

故障解决

已经明确了问题的症结所在，所要做的就是调整新增节点路由设备出口的MSS，通过调整TCP报文分段保证产生的T报文长度小于VPN隧道最大传输单元长度，即可防止长生超过限制的超大数据载荷。

具体做法是，在新增节点路由器外网口配置“tcp mss1400”，将路由器最大分段长度设为1400，这样超过1400bit的载荷TCP报文将会被拆分。经测试，调整后所有节点的视频设备Web管理页面均可以正常访问了，至此问题圆满解决。

经验总结

其实，MTU长度差异导致的网络故障在日常维护中也是时常会遇到的。对于本案例来说，新增节点时选择同一品牌产品的目的，就是尽可能减少设备兼容性问题。然而，因为不同时期的产品技术实现细节上的差异，却造成了组网过程中的怪异现象。

对于这样的问题，要求维护人员能够准确理清数据流向，综合利用多种工具和方法，定位故障，尽可能在网络基础设施层面解决问题。不要将解决问题的着力点放到终端服务中，否则结果很可能是摁倒了葫芦瓢又起。