很多企业运维人员在对接运营商线路升级、带宽扩容或者VPN节点迁移的工作时，经常会因为前期信息记录不全，导致调整后出现VPN断连、跨站点访问异常、业务系统卡顿等问题，返工排查的时间甚至远超线路调整本身的耗时。本文就围绕VPN与运营商线路调整前需要记录什么的核心问题，梳理所有必须留存的关键信息，覆盖配置溯源、故障定位的全需求，帮运维团队把调整风险降到最低。
现有运营商线路的基础属性记录
首先要先确认当前在用的运营商线路本身的核心参数，不能只记带宽数值，要先留存线路的入户物理端口编号、运营商分配的公网IP段属性，区分是固定公网IP、动态公网IP还是运营商内网NAT映射的伪公网IP，不同的IP属性对应后续VPN隧道的封装逻辑完全不同。
还要记录线路当前绑定的VPN设备的WAN口对接参数，包括物理接口的协商模式、VLAN标签（如果运营商做了二层隔离的话）、线路的上下行实际承载的VPN业务占比，避免调整后运营商直接修改了二层封装规则，导致VPN隧道完全无法建立。
当前VPN隧道的全量配置快照
很多运维人员调整前只备份VPN设备的整体配置文件，很容易漏掉和当前线路强绑定的隧道专属参数，首先要记录所有IPsec VPN、SSL VPN的对端节点公网地址，以及两端协商用的预共享密钥、加密算法组合、生命周期参数，避免调整后两端参数不匹配导致隧道协商失败。
运维人员正在逐一核验记录运营商线路与VPN设备的核心配置参数
还要单独记录VPN隧道内的路由发布规则，包括静态路由的下一跳指向、OSPF或者BGP动态路由的宣告网段，还有跨站点互访的ACL放行规则，这些参数如果和新运营商线路的网段冲突，加速器调整后会直接出现部分业务网段能通、部分完全隔离的异常情况。
调整前的基线连通性测试数据
这部分信息是调整后故障定位的核心参照，加速器要在调整前的正常业务时段，连续多次测试所有VPN分支节点和总部之间的连通状态，记录不同业务网段之间的互访丢包情况、跨站点访问核心业务系统的延迟表现，不要随便用第三方测速工具的结果，要以内部业务系统的实际访问状态为准。
还要记录VPN隧道内的特殊业务端口的连通性状态，比如视频会议系统的专属端口、工业控制设备的私有通信端口，加速器很多时候调整后普通ping测试是通的，但特定业务的VPN隧道封装被运营商新的策略拦截，没有前期的端口连通性记录，很难快速定位问题根源。
关联网络设备的绑定关系记录
很多场景下运营商线路不是直接对接VPN设备，中间还串联了边界防火墙、流量清洗设备、核心交换机，调整前要记录所有串联设备上和当前VPN线路绑定的NAT规则、端口映射规则、安全策略放通条目，避免调整后直接覆盖原有配置，导致VPN的公网探测报文被拦截。
还要记录内网侧和VPN网关对接的核心交换机的三层接口参数、VPN下载VLAN透传规则，尤其是做了VPN隧道流量专属分流的场景，内网侧的路由指向如果没有提前记录，调整后很容易出现VPN流量走普通公网出口，导致业务数据泄露或者访问失败的问题。
最后还要注意几个常见误区，不要默认运营商线路调整后原有公网IP不会变，也不要直接把旧线路的VPN配置直接套用到新线路上，所有记录的信息都要在调整完成后逐一对照核验，确认VPN隧道的协商状态、业务连通性和调整前的基线状态完全一致，再逐步放开全量业务流量，避免影响正常业务运行。
