在企业跨站点组网、远程办公的日常运维场景里，不少管理员更换运营商接入带宽、调整线路套餐、加速器更换运营商服务商时，经常遇到调整完成后原有VPN隧道直接断开、跨站点业务全部中断的问题，大部分这类故障都可以通过调整前的信息记录提前规避。本文就围绕VPN与运营商线路：调整前需要记录什么的实际落地需求，拆解所有需要提前留存的核心事项，帮运维人员把后续排障的前置准备做足。
现有VPN组网的公网侧基础参数记录
首先要完整记录VPN两端的现有公网IP属性，不管是站点到站点的IPsec VPN，还是远程员工使用的SSL VPN，都要先确认两端VPN网关的出口公网IP是运营商分配的固定公网IP，还是运营商内网NAT下的动态私网IP，对应同步记录的内容还要包括VPN网关WAN口获取到的公网地址、运营商侧分配的网关地址、当前线路使用的DNS服务器地址，还有当前VPN服务占用的端口段，比如IPsec协议默认用到的500、4500端口之前有没有被运营商封禁过，之前申请端口放开的备案记录也要一并整理留存。
很多运维人员容易漏记现有VPN的NAT穿透状态，比如当前站点两端的VPN网关是不是都处于运营商的一级NAT层级下，之前有没有配置过静态端口转发规则来维持VPN隧道的长期保活，这些参数如果没提前记录，调整线路之后直接替换网关配置，很容易出现新线路下NAT层级变化，导致隧道完全无法建立的问题。
VPN隧道的内部业务运行基线记录
这里要记录的不是VPN的底层配置参数，而是当前隧道正常运行时的实际业务状态，首先要把所有走VPN隧道的私网网段列表全部整理出来，包括总部侧的内网业务服务器网段、分支侧的办公终端网段、还有之前特意配置放行进隧道的单独测试网段，不要漏掉临时添加的小众业务网段，加速器不然调整完之后很容易出现部分业务网段访问正常、部分网段完全不通的隐蔽故障，排查起来要耗费数倍的时间。
运维人员提前记录VPN与运营商线路核心配置，避免调整后VPN隧道意外中断
接下来要做一次全链路的连通性基线验证，记录从VPN一端的内网终端访问对端所有内网业务地址的连通状态，还有大文件跨VPN传输、实时协作类业务的正常运行状态，这些记录不需要做量化的测速统计，只要标记当前哪些业务走隧道是稳定可用的，调整完线路之后可以直接对照验证，不用挨个询问业务侧用户是否正常。
还要记录当前VPN隧道的冗余配置状态，比如之前有没有配置过多运营商线路的VPN多活冗余规则，有没有设置自动切流的路由优先级策略，这些策略如果没提前梳理记录，调整新线路之后很容易出现新旧路由规则冲突，导致业务流量还往已经停用的旧线路上转发的问题。
运营商侧线路的现有限制规则记录
不少运维人员调整线路前只会对比带宽资源，完全忘了记录原有运营商线路的特殊限制规则，比如之前的旧线路有没有被允许透传IPsec协议，有没有封禁SSL VPN常用的443端口之外的自定义服务端口，部分面向家用或者小微企业的宽带套餐默认会禁用IPsec类的隧道协议，之前如果是单独联系运营商后台放开的权限，给梨加速器调整新线路的时候要提前确认新套餐有没有同等权限，不然调整完成后VPN服务会直接失效。
还要记录原有线路的公网IP分配规则，比如旧线路是支持申请固定公网IP的，新的运营商线路如果只能分配动态私网IP，那原有配置的两端固定IP对接的IPsec VPN就完全无法适配，需要提前改成动态域名对接的方式，这些预判工作如果没提前做，等旧线路正式停用之后才发现问题，会直接耽误正常业务运行。
调整前的备份与回滚触发条件记录
最后要把当前VPN网关的完整配置文件做一次全量备份，导出的备份文件要单独存放到不依赖当前VPN网络的本地终端里，同时还要明确记录调整失败的回滚触发条件，比如调整新线路之后VPN隧道长时间无法建立、核心跨站业务全部中断的话，就立刻切回旧线路恢复服务，不要在新线路上反复调试耽误业务可用性。
还要提前记录好VPN设备的本地管理员账号密码，不要只存放在依赖VPN访问的内网密码服务器里，万一调整之后远程管理不上VPN网关，还能直接用本地网线直连的方式登录设备排查问题，避免出现完全无法修改设备配置的尴尬情况。
