很多用户在调整VPN参数或者本地带宽套餐、限速规则之后，经常出现VPN连接掉线、内网资源无法访问、跨站点传输速率不升反降的问题，多数情况都是调整前没有留存关键配置信息，故障出现后无法快速回滚定位，本文就从实际运维排查的场景出发，梳理调整VPN与本地带宽前必须记录的几类核心信息，轻舟帮用户避免无意义的排障成本。
VPN隧道本身的底层配置参数
很多用户调整本地带宽的上行下行限速之前，直接改了路由器的QoS规则，之后发现VPN隧道频繁断连，排查了半天才想起之前VPN的隧道封装用了固定的MTU值，刚好和新的带宽限速规则冲突，这类故障如果没有提前记录基准配置，很容易把排查方向错放到运营商链路或者VPN服务端上，浪费大量时间。
调整操作开始前，首先要记录当前VPN连接的隧道类型，是IPsec、OpenVPN还是SSL VPN，对应的预共享密钥、本地存储的证书路径、账号认证方式，还有协商出来的隧道本地虚拟IP、远端虚拟IP地址段，这些信息如果调整带宽后VPN连不上，不需要重新找管理员索要认证资料，直接对比新配置的协商日志就能快速定位是不是参数匹配问题。
完成这类信息的记录之后，调整带宽完成后如果VPN出现连接失败，逐一核对新的隧道协商参数和记录的基准值，只要有一项不匹配，大概率就是带宽调整过程中路由规则被改写导致的，不需要优先排查运营商侧的链路问题，能大幅缩小故障排查范围。
调整VPN与本地带宽配置前提前记录关键参数，可大幅降低后续故障排查的时间成本。
本地网络侧的关联路由与QoS配置
不少企业运维人员在扩容本地带宽之后，直接替换了出口路由器，之后发现所有走VPN的分支站点都无法访问总部内网，排查了很久才想起之前配置了专门的VPN流量静态路由，指定了固定的出口网关，替换设备后这条规则没有同步过去，这类问题在中小团队的运维场景里出现的概率非常高。
调整带宽之前，要完整导出当前本地网络的静态路由表、动态路由的宣告规则，还有专门针对VPN流量设置的QoS标记、带宽预留规则，包括哪些IP段的流量优先级高于普通上网流量，哪些端口的VPN报文不允许被限流，这些规则大多是手动配置的，不会随着带宽参数同步自动迁移。
很多人觉得调整带宽只是改运营商侧的上下行速率，本地设备的配置不会变，实际上不少家用路由器和企业网关在带宽调整后会自动重启同步运营商的下发参数，轻舟很容易把之前手动配置的VPN专属路由规则冲掉，提前记录好基准值就能直接对比差异，不需要逐行试错。
内网侧的访问白名单与权限映射规则
很多远程办公用户在家调整了家用带宽的上行提速之后，发现自己的VPN能正常连上公司网络，但是之前能访问的公司共享盘、内部业务系统全部打不开，排查之后才发现之前VPN客户端的本地子网映射规则，和新的家用宽带分配的IP地址段冲突了，这类问题如果没有提前记录配置，梯子很容易误以为是企业VPN服务端做了权限调整。
调整带宽之前，要记录当前VPN连接成功后，可正常访问的内网资源地址段、本地侧的局域网IP范围、VPN客户端设置的允许本地局域网访问的白名单规则，还有VPN拆分隧道的路由条目，也就是哪些流量走VPN隧道、哪些流量直接走本地公网的配置，这些规则一旦和新的本地网段冲突，就会出现部分业务可用、部分业务异常的碎片化故障。
如果调整带宽之后出现VPN连得上但内网资源无法访问的情况，直接把当前的内网地址段和之前记录的基准值做对比，要是出现IP段重叠的情况，梯子直接修改本地侧的局域网网段就能快速恢复，不需要重新配置VPN服务端的权限规则。
基准连通性测试的原始状态数据
除了静态配置信息之外，调整VPN相关参数或者本地带宽之前，还要记录当前正常状态下的关键连通性数据，比如到VPN网关的公网延迟、隧道内访问远端内网服务器的连通情况、普通网页访问的正常状态，这些基准数据能帮你快速判断调整后的变化是正常波动还是故障，避免把调整后的正常状态误判为异常反复修改配置。
所有记录的配置信息要注意存储在本地安全的位置，不要随意上传到公网云盘，避免包含VPN认证信息的内容泄露，调整完成后先对照记录的基准值逐项验证连通性，确认所有业务正常之后再更新旧的配置记录，避免后续出现问题没有回滚依据。
