很多用户在调整VPN分流规则、扩容路由器带机量或者修改负载均衡策略后，经常出现原有VPN连接掉线、部分设备无法访问内网资源、科学上网甚至整段网络断流的问题，大部分这类故障都不是调整操作本身的错误，而是调整前没有留存足够的基准参考信息，出问题后无法快速回溯定位，本文就从实际运维排查的角度，梳理VPN与路由器负载调整前必须记录的几类核心信息，帮你把调整风险降到最低。
当前VPN链路的基准运行状态信息
首先要记录的是所有正在生效的VPN隧道的基础参数，包括每条隧道的连接协议、加密套件、对端网关地址、预共享密钥或者证书的存储路径，不要只记后台显示的隧道名称，很多时候名称是中文备注，调整配置后如果名称乱码，你根本对应不上实际的对端节点。
调整VPN与路由器负载前，运维人员逐一记录当前网络的基准运行参数
接下来要记录每条VPN隧道当前的实际负载占比，也就是实时上下行带宽占用、当前承载的在线终端数量、已经建立的TCP和UDP会话数，这些数据是你后续调整负载阈值的核心参考，如果你直接把负载上限改到远低于当前实际占用值，保存配置的瞬间就会触发隧道过载保护直接断连。
还要记录VPN侧已经配置好的分流规则明细，包括哪些网段走VPN隧道、哪些IP走本地直连、排除的域名列表，很多人调整负载均衡的时候误把分流规则里的路由条目覆盖，事后根本回忆不起之前排除了哪些办公系统地址。
路由器底层的现有负载配置基线
首先要记录路由器当前的CPU、内存实时使用率，还有不同核心进程的资源占用占比，尤其是VPN守护进程、NAT转发进程的单独占用情况，很多嵌入式路由器的VPN进程本身资源占用就很高，你后续调整负载规则的时候如果给其他进程分配过多资源，就会直接挤掉VPN进程的运行空间。
接下来要记录路由器现有的会话总数、端口映射规则、静态路由条目、VLAN划分规则的全部明细，很多用户调整负载均衡策略的时候，会默认清空之前的静态路由表，要是你没有提前导出备份，后续内网不同VLAN的设备就完全无法互访。
还要记录路由器当前的上下行带宽的基线测速结果，注意这里的测速是不经过VPN的本地直连测速，和之前记录的VPN隧道测速做对比，你后续调整负载权重的时候，才能准确判断是调整操作导致的带宽下降，还是运营商本身的线路波动。
现有网络的故障定位参考标识
首先要记录当前网络环境下，几个关键测试节点的连通性状态，比如VPN对端内网的某个固定服务器IP、本地运营商的DNS服务器地址、公共的递归DNS地址，分别记录ping值、连通稳定性、路由跟踪的跳数路径，后续调整后如果出现连通异常，你可以直接对比这些记录快速判断故障点是出在本地路由器、VPN隧道还是运营商线路。
还要记录当前网络下所有特殊设备的IP和MAC绑定关系，比如需要走固定VPN隧道的监控摄像头、办公服务器、远程打卡终端，这些设备如果在调整负载后被分配到其他隧道，很可能出现业务无法正常上报的问题，提前记录绑定关系可以帮你在故障出现后快速完成修正。
很多人容易忽略的是，调整前还要记录当前VPN连接的日志级别、路由器的日志存储路径，要是调整后出现隐性的丢包、闪断问题，你可以直接对比新旧日志的差异，不需要重新复现故障就能找到异常触发的具体配置项。
最后要提醒的是，所有记录的信息最好单独导出存放在调整操作设备的本地，白鲸加速器不要放在需要通过当前网络访问的云盘或者内网服务器上，万一调整后整个网络断连，你还能随时调取之前的基准信息回溯配置，最大程度降低调整操作带来的业务中断风险。
