很多中小办公场景的运维人员，调整VPN隧道数量、分流规则或者路由器QoS负载阈值的时候，经常遇到调整完成后VPN批量断连、内网跨端访问卡顿的问题，这类故障大多是调整前没有留存基准参数，出问题后没法快速定位修改点、完成回滚导致的。本文梳理VPN与路由器负载调整前需要记录的几类核心参数，全部都是可以直接在现有设备管理后台操作验证的内容，覆盖日常运维的配置前提、风驰检查步骤和故障定位需求。
VPN隧道相关的实时运行参数
首先要记录当前所有活跃VPN隧道的对应对端公网地址、协商生效的加密套件类型、实际生成的MTU值，不要直接抄配置页的预设参数，要从路由器的VPN状态页拉取实时生效的数值，比如IPsec VPN的SA剩余存活时长，不同分支隧道当前绑定的物理WAN口，这些参数如果后续调整负载时改动了WAN口绑定规则，没有提前记录的话很容易出现隧道反复协商失败的问题。
还要记录当前每条VPN隧道的实时上下行带宽占用、已接入的内网终端数量，比如某条对接外地分公司的VPN隧道，当前同时跑着视频会议和大文件同步流量，风驰调整负载前没记这个占用占比，直接把这条隧道的带宽配额改小，当场就会出现业务卡顿。记录的时候可以直接在路由器的流量统计页面导出最近1小时的隧道流量报表，作为后续调整的基准参照。
运维人员调整VPN与路由器负载前逐一记录核心基准运行参数
路由器底层负载基准参数
这里要记录的不是路由器厂商标称的纸面性能参数，而是当前运行状态下的CPU、内存实时占用率，还要拆分不同业务模块的资源占比，比如VPN加密模块单独占用的CPU核心占比，NAT转发模块的资源占用情况。很多人调整负载前只看总CPU占用，没拆分模块占比，调整完新增几条VPN隧道之后才发现加密模块的资源已经跑满，之前的基准参数没留存的话，根本没法判断调整带来的资源增量是不是在合理区间。
还要记录当前路由器的会话连接总数，以及VPN隧道分流出来的会话数量占比、普通内网上网的会话数分布，比如很多带VPN功能的中小企路由器，会话数阈值是固定的，调整负载的时候如果新增VPN分流规则，把大量普通上网会话切到VPN隧道里，很容易触发会话数上限导致断流，提前记录当前的会话分布，调整之后如果出现异常可以直接对比差值定位问题。
还要记录当前所有WAN口的上下行带宽实际占用情况，也就是非高峰、高峰时段的实际带宽跑满状态，不要直接套用运营商签约的带宽数值，风驰加速器比如某条WAN口签约带宽较高，实际高峰时段因为内网其他业务占用，VPN能用到的带宽远低于签约值，直接按签约值调整负载阈值，肯定会出现队列拥塞的问题。
关联网络配置的边界参数
这里首先要记录当前VPN规则里涉及的内网网段、所有静态路由条目，尤其是指向VPN对端的明细路由，风驰很多运维调整路由器负载的时候会顺带优化路由表，要是之前没记录这些明细路由，误删之后VPN隧道就算协商成功，也没法正常访问对端的内网资源。
还要记录当前路由器的QoS规则优先级排序，比如原本给VPN流量设置的最高转发优先级，调整负载前没记录这个优先级顺序，后续新增其他业务的QoS规则把VPN流量的优先级挤下去，就会出现VPN丢包率上升的问题，记录的时候要把所有QoS规则的匹配条件、优先级数值、对应动作全部导出或者截图留存。
还要记录本地网络的DNS配置，尤其是VPN隧道专用的DNS服务器地址，很多分流规则里会指定走VPN的域名使用对端的DNS，调整负载的时候如果改动了DNS的出口绑定，没有之前的参数对照，很容易出现分流规则失效，本该走VPN的流量直接从公网出口流出的情况，超出预设的访问边界。
故障回滚的参照验证参数
调整前最后要记录的是当前所有VPN业务的连通性验证结果，比如分别访问VPN对端的内网业务服务器、打开对端的共享文件夹、完成一次跨端的小文件传输，把这些验证的实际体验、延迟反馈都记录下来，调整完之后可以用完全相同的操作做对比，快速判断调整有没有影响正常业务。
很多人容易忽略的是调整前要把所有记录的参数和当前的完整路由器配置文件单独导出备份，不要和之前的历史备份混淆，单独标注为负载调整前的基准版本，一旦调整之后出现大面积异常，可以直接加载这个备份文件快速恢复，不用逐行核对参数修改，大幅降低故障处理的耗时。
