很多用户在遇到VPN连接后网页加载卡顿、大文件传输中途中断、部分内网业务系统无法访问的问题时，第一反应就是直接修改VPN的MTU数值，往往改完之后反而出现更多连接异常，甚至原本能正常连通的VPN隧道直接断开。VPN与MTU设置：调整前需要记录什么，是所有网络运维人员和普通VPN使用者都需要先理清的前置步骤，跳过信息记录直接修改配置，大概率会导致故障排查链路完全混乱，甚至无法回溯原有正常配置的状态，小问题演变成长时间的网络中断。
原有网络环境的基准MTU实测值
首先要记录的是VPN隧道建立之前，本地直连公网的原生网络MTU实际数值，不能直接沿用网卡默认的1500数值，因为部分家用路由器、运营商内网会修改底层MTU参数，原生网络的MTU基准值是后续调整VPN MTU的核心参考基线。
记录这个数值的时候，需要断开所有VPN连接，通过不分段的大包ping测试完成，确认没有丢包的情况下得到的最大传输单元数值，就是原生网络的真实MTU，这个数值如果记录错误，后续所有VPN MTU的调整都会失去参考依据，甚至出现调整后的VPN MTU比原生网络的MTU还要大的低级错误。
当前VPN隧道的默认运行参数
很多VPN客户端和服务端都会自带默认的MTU适配参数，调整之前必须先把当前正在生效的VPN配置完整记录下来，包括隧道封装协议的类型、当前已经设置的MTU数值、MSS钳位的开启状态、是否开启了数据包分片相关的开关。
这些参数的记录需要同时覆盖VPN客户端侧和服务端侧，不能只记录其中一端的配置，否则很容易出现两端参数不匹配，调整之后隧道协商失败的问题，部分企业级VPN服务端还会针对不同用户组分配不同的MTU策略，也要确认当前账号所属的策略组对应的默认配置，避免修改客户端配置之后被服务端的策略覆盖，完全看不到调整效果。
故障现象对应的具体业务场景特征
调整MTU本身是为了解决特定的网络异常，调整之前必须先把当前遇到的故障对应的场景完整记录，包括哪些网站、哪些内网业务在VPN连通之后无法正常访问，小体积数据包的访问是否正常，只有大文件传输或者高清视频流传输的时候才会出问题。
还要记录故障出现的时间点，是更换了本地网络环境之后才出现，还是VPN服务端升级配置之后才出现，这些场景信息可以帮你快速定位MTU不匹配的具体位置，避免调整完MTU之后故障现象变化，你无法判断是调整配置带来的影响还是原有网络本身的问题，导致排查方向完全走偏。
关联网络设备的配置状态
很多用户的本地网络中除了VPN客户端之外，还串联了路由器、防火墙、其他代理服务等网络设备，调整VPN MTU之前需要记录这些关联设备上和MTU、MSS相关的配置是否有自定义修改的痕迹，有没有开启强制分片的规则。
如果是在企业内网环境下使用VPN，还要记录内网核心交换机、出口网关上针对VPN流量的特殊处理规则，部分网关设备会对特定协议的VPN流量做额外的封装，这类封装带来的额外开销也必须在后续调整MTU的时候纳入计算，没有提前记录的话很容易忽略这部分开销，导致调整后的MTU依然不符合传输要求。
完成所有上述信息的记录之后，你才可以开始尝试调整VPN的MTU参数，每次调整的步长不要过大，调整之后要先验证之前正常的业务是否还能正常连通，再验证原本的故障现象是否得到缓解，一旦出现新的异常，可以直接对照之前记录的原始配置快速回滚，避免长时间断网的问题。如果多次调整MTU都没有解决原有故障，也可以对照之前记录的所有信息逐一排查其他可能的故障点，不会因为修改过配置丢失排查线索。
