很多企业和个人用户在更换运营商接入线路、调整VPN部署架构时，经常因为没有提前留存足够的基础配置信息，导致调整后VPN隧道无法建立、内网业务访问异常，甚至出现长时间断网的故障，梳理VPN与运营商线路调整前需要记录什么的完整清单，能最大程度降低调整操作的风险，也能在出现故障时快速定位回退。
现有VPN链路的基础运行参数记录
首先要记录当前VPN的两端公网接入地址，不管是IPsec站点到站点VPN还是SSL远程接入VPN，本地端的公网出口IP、对端VPN网关的公网地址都要逐行抄录，不要只依赖配置页面截图，小鸟部分设备的隐藏端口映射规则不会在首页完整展示，手动文字记录能避免遗漏关键信息。
这里要注意常见的配置误区，很多人调整前只记VPN的登录账号密码，忽略了原有线路的公网IP是动态分配还是静态绑定属性，如果之前的线路是静态公网IP，新线路如果没有提前向运营商申请公网IP资源，站点到站点模式的VPN会直接因为两端地址无法定位建立隧道，提前记录下原有属性就能提前规避这类低级问题。
提前逐一记录VPN与运营商线路的各项关键参数，最大程度降低线路调整后的故障风险。
VPN关联的内网路由与访问规则台账
要逐台记录VPN网关后台配置的感兴趣流规则，也就是哪些内网网段需要走VPN隧道传输，哪些网段直接走本地运营商公网出口，很多用户调整线路之后发现部分跨地域业务系统访问不了，就是因为调整时误删了原有细分的路由条目，没有提前留底的话排查要花费数小时的时间。
还要记录当前VPN隧道的内网互访权限，比如分支的哪些部门网段能访问总部的核心服务器区，哪些网段只能连总部的办公OA系统，这些ACL访问控制规则如果没有提前记录，调整后很容易出现越权访问或者普通员工无法访问办公资源的问题，后续整改还要走内部审批流程，耽误正常业务进度。
这类记录也是故障定位的核心参照，后续如果调整后出现VPN丢包、延迟升高的问题，拿原有记录的路由规则做对比，能快速判断是新运营商线路的路由转发问题，小鸟VPN官网还是VPN配置修改出错，不用在两个故障方向之间反复排查浪费时间。
原有运营商线路的底层网络特征记录
要记录原有线路的VLAN划分、专线的对接参数，如果是用运营商物理专线承载VPN流量的场景，要把运营商侧提供的VLAN ID、小鸟对接的VLAN子接口配置全部记录下来，新线路如果是同运营商的不同专线，参数不匹配的话哪怕物理网线插上去也跑不通VPN隧道。
还要记录原有线路的NAT映射规则，很多用户的VPN网关是部署在内网环境，通过运营商分配的公网IP做端口映射对外提供SSL VPN远程接入服务，提前把映射的端口、对应的内网VPN设备地址全部记录，调整新线路后可以直接照搬配置，不用反复测试端口连通性。
调整前的基线连通性测试结果留底
调整操作正式开始之前，要分别从VPN隧道两端测试对端的内网核心地址连通性，同时测试几个核心业务系统的访问状态，把测试结果用文本或者截图的方式记录下来，这个基线是后续判断调整后故障是出在VPN配置还是运营商线路的核心依据。
这里要避开常见的操作误区，很多用户觉得调整线路只是更换物理接入介质，不用做提前测试，结果调整后出现业务卡顿的问题，根本不知道是调整前就存在的隐性网络问题，还是调整操作导致的新故障，后续排查完全没有参照标准，很难界定故障责任方。
