不少企业运维人员或者个人网络爱好者在调整VPN与NAT会话参数时，经常忽略调整前的信息留底工作，调参完成后很容易出现VPN隧道莫名断连、内网设备跨网访问异常、原有长连接业务全部中断的问题，事后回溯排查时找不到可对照的运行基准，故障定位效率极低。这份调整前需要记录的关键信息完整清单，全部基于实际网络运维场景设计，所有记录项都可以直接在网关上验证导出，没有空泛的操作要求。
现有VPN隧道的基础连通性基准信息
首先要记录的不是VPN的预设配置参数，而是当前隧道的真实运行状态，比如企业分支站点部署的IPsec VPN，要在两端网关分别执行隧道状态查询指令，记录当前已建立的隧道数量、每一条隧道的对端公网IP、协商完成的IKE阶段一和阶段二加密套件、当前隧道的剩余生存时长。
运维人员调整VPN与NAT会话参数前逐项记录运行基准信息
还要同步记录隧道两端的内网互访基准，比如从分支内网的业务服务器ping总部内网的核心存储服务器，确认连续发包的连通状态，同时记录两端VPN网关下当前已经通过隧道转发的实时会话数，不要只看配置页写的预设参数，很多实际运行的会话数会和配置阈值存在偏差，直接用配置参数做调整基准很容易出现误差。
当前NAT会话表的核心运行参数
很多用户调整NAT会话的时候只修改超时时间，完全没记录原有运行状态，调整前首先要在出口网关的NAT统计页面，记录当前总NAT会话数、不同协议的会话分布，猎豹VPN官网比如TCP、UDP、ICMP各自占的会话数量，还有当前NAT地址池的剩余可用公网IP端口段数量。
还要重点记录和VPN关联的NAT规则，绝大多数场景下VPN隧道的内网互访流量是不需要做地址转换的，猎豹要把所有排除VPN流量的NAT豁免规则逐条导出文本或者截图留存，确认每一条规则的匹配源地址、目的地址、动作属性，避免调整NAT的时候误把VPN隧道流量也加入地址转换队列，直接导致隧道协商失败。
这里的常见误区是只记录NAT会话的最大阈值，不记录当前实际占用的会话数，等你把阈值改小之后，原有存量会话会被系统强制清空，所有正在传输的VPN业务流量会直接断连，没有基准数据的话你根本不知道是改了哪个参数导致的故障。
关联业务的会话映射关系记录
调整之前还要梳理所有跑在VPN隧道上的业务对应的NAT会话特征，比如连锁门店的收银系统走IPsec VPN连总部服务器，猎豹每台收银机对应的VPN内网地址、建立的长连接会话的目的端口，都要在调整前抽样记录3到5台典型设备的会话条目，避免调参后部分特殊业务的会话被提前老化。
如果是个人用户用OpenVPN远程访问家里的NAS，调整NAT会话之前，要记录当前VPN客户端分配的虚拟地址段，和出口NAT规则里对应的端口映射条目，确认远程访问NAS的端口没有和VPN服务本身的端口产生冲突，避免调整后远程访问的端口映射规则被新的NAT规则覆盖。
调整前的故障定位基准快照
所有记录的信息都要做交叉验证，比如你记录完VPN隧道状态和NAT会话数之后，要做一次基准测试，从VPN客户端访问内网的业务系统，确认访问正常，猎豹VPN官网把这个状态作为调整前的基准快照，后续调整之后如果出问题，可以直接回滚对照，不需要从零开始排查。
还要提前导出网关设备的当前完整配置文件，单独存放在离线存储介质里，不要直接在原有运行配置上修改，很多运维人员调整完发现故障，想回滚的时候发现之前的配置已经被新的修改覆盖，根本找不到原始版本，反而把小故障拖成了大范围的业务中断。
不少人调整完VPN与NAT会话之后，发现部分老会话断连，误以为是参数改坏了，其实是调整前没有记录存量会话的超时时间，调整后原有会话被强制老化，只要对照之前记录的基准参数逐步回退，就能快速定位问题，不需要逐行排查所有配置。
