很多运维人员在遇到VPN隧道丢包、传输卡顿的时候，第一反应就是直接修改TCP重传相关的系统配置，反而没留存原有状态，黑石VPN官网导致调整后出问题没法回滚，甚至把原本只是局部波动的VPN故障扩大成全链路断连，本文就围绕VPN与TCP重传：调整前需要记录什么这个核心问题，梳理所有必须提前留存的关键信息，避免无准备调整带来的次生故障。
VPN隧道两端的原生TCP协议栈默认参数
很多人调整重传配置的时候只改单端的服务器参数，完全没留意客户端侧的TCP默认配置，两端参数不匹配反而会让重传机制完全失效，原本想优化丢包场景下的传输稳定性，最后反而让正常连接的VPN会话频繁被异常重置。
运维人员提前留存VPN隧道两端TCP原生参数，为后续配置调整预留可回滚的基线
这里需要记录的内容包括初始的TCP重传超时基数、最大重传重试次数、快速重传触发阈值、拥塞控制算法类型，所有参数都要在VPN隧道正常连通、没有出现故障的时候就提前导出，不要等故障爆发之后临时抓包记录，避免故障状态下的参数本身就是异常值，后续调整完成后找不到正确的基线做回滚。
当前VPN隧道的实时链路状态基线
调整TCP重传配置的核心目的是适配当前链路的波动特征，要是没有提前记录基线数据，根本没法判断调整之后链路质量是变好还是变坏，甚至会把原本正常的传输波动当成配置调整后的故障，做出错误的二次修改。
需要记录的内容包括隧道两端的实时往返延迟区间、连续多日内的常规丢包分布时段、跨运营商链路的抖动峰值、VPN封装外层的公网路径MTU实测值，这些数据不能只取某一个时间点的快照，要覆盖业务高峰和低峰两个典型场景，避免用非典型状态的链路数据作为调整依据，导致配置适配性极差。
现有VPN服务的绑定配置与路由规则
不少运维人员调整TCP重传参数的时候，忽略了VPN服务本身是绑定在特定物理网卡、特定虚拟隧道接口上的，全局修改TCP配置很可能影响到同一台服务器上跑的其他业务流量，引发非预期的业务故障。
需要完整记录当前VPN进程绑定的网卡标识、隧道接口的专属TCP配置规则、所有指向VPN加密网段的静态路由条目、VPN服务自带的流量整形队列参数，避免调整重传的时候覆盖了原本针对VPN流量做的专属路由策略，导致部分业务网段的流量直接绕过加密隧道走公网，突破预设的隐私边界。
过往同类故障的排查日志与历史配置变更记录
很多重复出现的VPN隧道断连、大文件传输卡顿问题，本质上之前已经有人调整过重传配置，要是没有历史记录，很容易重复踩之前已经踩过的坑，做无用功的同时还可能引发新的兼容性问题。
要导出最近一段时间内所有涉及VPN隧道TCP参数调整的操作日志、故障发生时的内核报错快照、之前做过的重传配置调整对应的效果记录，确认之前的调整是因为什么原因回滚，避免这次调整之后出现同样的适配问题，导致VPN服务完全无法建立连接。
所有记录的信息都要单独存放在和VPN运行服务器隔离的存储介质里，不要直接存在待调整的设备本地，避免调整过程中设备出现异常没法调取原有数据回滚。调整完成后也要对照之前记录的基线数据逐一验证，确认VPN连通性没有出现异常、加密流量没有出现路由偏移之后，黑石再逐步放量给业务使用，不要直接全量替换配置引发大范围故障。
