不少企业运维人员或者个人重度网络用户，在配合运营商完成线路割接、带宽扩容、公网IP段更新这类调整操作后，经常遇到VPN隧道中断、内网资源访问失败、协商流程卡住的异常问题，绝大多数故障的根源都不是调整操作本身出错，而是调整前没有留存足够的基准参照信息，出问题之后运营商、VPN设备厂商、内网业务侧多方排查找不到对照依据，互相推诿浪费大量时间，提前梳理全量需要记录的关键信息，是把调整后故障概率降到最低的核心前提。
现有VPN隧道的基础连通性基准数据
首先要完整记录当前VPN两端的公网接口地址，不管是常用的IPsec站点间VPN还是面向移动用户的SSL VPN，都要逐一确认客户端侧的公网出口IP、服务端的公网监听IP，同时标注当前运营商分配给线路的公网IP属性是静态固定还是动态拨号获取，本地出口有没有经过多层NAT映射，很多用户调整线路后直接更换了新的公网IP，没同步修改VPN对等体的地址配置，直接导致隧道完全无法发起协商。
接下来要完成基准连通性的留痕操作，在调整前的正常业务时段，持续测试从本地网络到VPN对端公网地址的连通状态，记录常规的延迟波动、丢包情况，再用路由追踪工具拿到当前从本地到VPN服务端的完整转发路径，确认中间经过的运营商节点有没有特殊的路由策略限制，这些原始数据都是调整后对比排查的核心参照，一旦调整后路由路径跳数明显增加、中间多了陌生的运营商防火墙节点，就能直接定位是运营商侧的路由变更导致的VPN连通异常。
VPN设备侧的核心配置快照信息
要逐一记录VPN设备上关联当前运营商线路的物理接口参数，包括接口的双工模式、VLAN绑定规则、接口归属的安全域，还有接口上配置的所有访问控制策略条目，很多运维人员调整线路的时候直接拔下旧线插上新线，没注意新线路的VLAN标签要求和旧线路不一致，导致VPN对应的物理接口直接处于未激活状态，后续所有隧道配置都无法生效。
还要导出完整的VPN隧道配置离线快照，比如IPsec VPN的IKE协议版本、协商用的加密算法、预共享密钥、感兴趣流的匹配网段规则，SSL VPN的用户地址池范围、虚拟网卡的路由推送规则，不要只靠人工记忆留存，最好把完整配置文件导出后存在本地离线存储，调整后如果出现配置误覆盖的情况，可以直接对照快照逐行核对恢复，避免靠试错修改配置浪费大量业务时间。
还要额外记录VPN和内网其他业务系统的联动规则，比如有没有把VPN用户的访问日志上传到指定的日志服务器，有没有配置基于VPN网段的访问控制白名单，很多人调整完线路之后只测试了VPN能不能正常拨号连接，没注意日志上传、跨区域文件共享这类联动功能失效，最后排查半天才发现之前的联动规则绑定了旧的运营商线路网段，调整后没有同步更新。
运营商侧线路的关联规则备案
要提前和运营商对接人员确认当前线路上已经配置的所有专属规则，包括公网IP的端口映射条目、固定IP和设备MAC的绑定关系，有没有开通针对企业专线的专属转发通道，还要确认运营商侧的边界防火墙有没有针对VPN常用的UDP 500、UDP 4500端口放行，很多运营商线路调整流程会默认重置所有用户自定义的特殊规则，要是之前没提前记录这些规则，调整后运营商默认封禁了VPN协商的必要端口，隧道就会一直卡在协商阶段无法完成建立。
还要完整记录当前线路的宽带拨号认证账号、密码，以及线路当前绑定的接入设备MAC地址，不少运营商的BRAS接入设备会做账号和MAC地址的强绑定校验，如果调整线路的时候更换了接入的VPN设备物理接口，没有提前告知运营商解绑旧的MAC地址，就算本地所有配置都完全正确，也无法正常拨号上线，后续的VPN隧道自然也无法建立。
终端侧VPN接入的常规状态记录
针对使用SSL VPN的移动办公用户群体，要提前记录不同接入场景下的VPN连接状态，比如用户用家庭宽带、公共WiFi、手机流量分别接入VPN的时候，有没有出现过NAT穿透异常、协商超时的情况，调整完运营商线路之后可以直接用相同的终端在相同的场景下做对照测试，快速定位是运营商线路变更导致的问题还是终端本地配置异常，缩小故障排查范围。
还要记录VPN分配给终端的虚拟IP段和内网业务系统的访问关系，比如哪些业务系统的访问白名单里已经添加了VPN的虚拟地址段，调整后如果VPN分配的虚拟IP段发生变化，就可以直接对照记录去更新业务侧的白名单规则，避免出现VPN拨号成功但打不开核心业务系统的异常情况。
很多运维人员最初都会觉得VPN与运营商线路调整前需要记录什么这类问题都是冗余的操作，等到真的出现大面积故障的时候，没有基准信息做对照，根本分不清故障点是在运营商侧、VPN设备侧还是内网业务侧，反而要花几倍的时间去逐一排查，提前把这些关键信息全部留存好，不仅能把调整后的故障概率压到最低，就算真的出现异常也能快速定位根因，不用在多方对接的时候互相推诿浪费时间。
