很多用户在日常运维或者自行调整VPN与网线连接：调整前需要记录什么没有明确的概念，经常直接插拔网线、修改VPN客户端配置，最后出现拨入失败、内网资源无法访问、分流规则错乱等问题时，找不到回溯参考的基准信息，只能花费数小时逐段排查故障。实际上提前做好关键信息的记录，能把调整后的故障排查效率提升数倍，也能避免很多不必要的配置回滚操作。
本地有线网络的基础配置参数
首先要完整记录当前有线网卡的全量配置信息，不要只简单记下IP地址，要明确标注当前网卡是DHCP动态获取地址模式，还是手动指定的静态IP模式，把对应的IP地址、子网掩码、默认网关、DNS服务器地址全部整理成文本保存。如果之前为了适配特定内网VPN的接入要求，手动修改过本地hosts文件的条目，也要把相关条目完整导出留存。
调整VPN与网线连接前完整记录有线网络配置参数，可大幅提升后续故障排查效率
这里的常见误区是很多用户认为更换网线、蘑菇VPN调整物理接入位置不会改动本地配置，实际上如果调整操作涉及到把网线从原有内网端口迁移到新的交换机端口，原有静态IP如果和新接入的网段出现冲突，哪怕物理链路完全正常，也会出现VPN隧道无法建立的问题，提前记录完整参数，出问题时可以直接一键回滚原有配置，不用反复核对参数。
当前VPN连接的核心运行状态信息
接下来要记录当前正在生效的VPN连接的核心参数，包括VPN的隧道类型、预共享密钥、自定义的加密算法、拨入账号的专属后缀等个性化配置，很多VPN客户端在检测到底层物理网卡变动时，会自动把自定义配置重置为出厂默认状态，没有提前记录参数的话，用户只能联系企业网络管理员重新申请配置信息，耽误正常业务使用。
除此之外还要导出当前VPN连接生成的虚拟网卡地址，以及系统内的全量路由表规则，明确哪些业务网段的流量是走VPN加密隧道传输，哪些网段的流量是直接通过本地有线链路访问公网。很多用户调整完网线之后会发现原本可以正常访问的内部业务系统报错，本质是系统默认覆盖了之前手动设置的分流规则，提前留存路由表备份就能快速对比调整前后的差异，不用逐行排查规则。
物理链路与上层设备的对应关系
还要记录当前整条有线链路的物理接入对应关系，比如网线一端接入的是电脑的哪一个有线网卡接口，另一端接入的是墙面的哪个网口，对应的上联交换机的端口编号是多少。不少企业的内网会划分不同的VLAN，只有指定端口的网线才能接入VPN专属网络，调整时如果误把网线插到普通办公VLAN的端口，哪怕所有软件配置都完全正确，也无法正常拨入企业VPN。
条件允许的情况下，还可以记录当前有线链路直连的上联设备的MAC地址，比如默认网关的MAC地址、对端交换机端口的MAC地址，调整完成之后如果出现链路不通的情况，可以直接对比当前获取的MAC地址和之前记录的是否一致，快速判断故障出在物理链路接错，还是上层网络设备本身的异常，大幅缩小故障定位的范围。
调整前的基准业务访问状态
最后需要记录调整前的基准业务访问结果，在调整操作开始之前，先逐一测试所有依赖这条VPN和有线链路的业务，包括VPN拨入的响应状态、内网文件服务器的访问状态、核心业务系统的加载状态，把这些正常运行的表现逐一记录下来，避免调整完成之后出问题时，无法判断故障是本次调整导致的，还是之前就隐性存在的。
这里需要注意隐私边界的相关要求，所有记录包含内网网段、VPN密钥、蘑菇业务系统地址的配置文件，都要保存在本地离线存储设备中，不要随意上传到公网云盘或者分享给无关人员，避免敏感配置泄露带来的内网安全风险。
很多用户容易忽略的一个记录项是本地网卡的优先级排序，如果之前为了保证VPN流量优先走有线传输，手动把有线网卡的优先级调到了WiFi之上，调整网线的过程中系统很可能自动重置网卡优先级，导致后续VPN流量默认走无线链路，之前针对有线链路做的所有适配配置全部失效，提前把网卡优先级的排序截图留存，调整完成之后核对一遍就能规避这类隐性问题。
