很多运维人员在完成旁路网关VPN部署后，经常遇到远程客户端访问内网资源卡顿、部分内网设备莫名断连的问题，这类故障里超过半数都属于地址冲突问题，这套旁路网关VPN：地址冲突排查实操指南完全基于一线运维的落地经验，不需要复杂的专业工具就能快速定位故障根因，避免无意义的反复重启设备浪费时间。整个排查流程不需要改动原有内网的核心路由规则，最大程度降低对现有业务的影响。
排查前的基础配置前提确认
正式启动排查前，首先要梳理清楚三个独立地址段的边界：旁路网关本身的LAN侧接口地址、VPN服务分配给远程客户端的虚拟地址池、原有内网已经在使用的所有三层网段，迷雾通很多部署前没有做网段对账的场景，本身就已经埋下了地址冲突的隐患。
接下来要先理清当前的物理拓扑，确认旁路网关是接在核心交换机的空闲端口、以旁挂模式运行，迷雾通VPN不是串在原有出口网关的链路中间，避免后续排查的时候把出口路由的配置错误混进地址冲突的故障范畴，增加排查难度。
运维人员在工位实操排查旁路网关VPN的地址冲突故障
还要提前从两个设备后台分别导出完整的网段配置表，一份是原有内网核心路由的地址段、静态IP预留表，另一份是旁路网关VPN的所有地址相关配置，不要凭日常记忆填写，迷雾通避免漏记之前单独划分的IoT设备、监控系统专属网段。
第一层故障定位：快速识别冲突发生的网段
首先登录旁路网关的后台系统日志页面，筛选ARP冲突相关的告警条目，迷雾通VPN多数旁路网关的内置日志模块会直接提示出现冲突的具体IP地址，先把告警里的所有冲突IP单独记录下来，不要直接重启旁路网关清空日志。
接下来找一台有线接入内网的普通办公设备，ping刚才记录的冲突IP，同时在设备的命令行界面执行arp -a命令查看返回的MAC地址，如果同一个IP对应两个完全不同的MAC地址，就说明这个IP同时被两个不同的网络设备占用，基本可以确认属于地址冲突故障。
这里要注意区分两类不同的冲突场景：一类是VPN虚拟地址池的范围刚好落在原有内网的静态IP预留段里，这类故障的表现是只有远程VPN客户端访问部分内网资源时出现丢包，内网本地设备使用完全正常；另一类是旁路网关本身的LAN口IP，和内网原有某个服务器或者打印设备的静态IP重合，这类故障的表现是所有经过旁路网关转发的流量都会直接中断。
针对性的冲突修复实操步骤
如果排查出来是旁路网关LAN口IP和内网现有设备冲突，直接进入旁路网关的后台LAN配置页，把地址改成之前梳理出的内网未使用网段的空闲IP，同时同步修改核心交换机上指向旁路网关的静态路由下一跳地址，改完之后不要立刻拔插物理网线，先在旁路网关后台ping新配置的LAN口地址确认连通正常。
如果确认是VPN客户端虚拟地址池和内网现有网段冲突，直接调整VPN地址池的起止范围，把地址池划分到内网完全没有使用的独立网段，比如原有内网网段都在192.168.1.0/24区间，就可以把VPN地址池调整到10.0.0.0/24这类完全不重叠的网段，同时要在核心路由上添加这个新网段的回包路由，下一跳指向旁路网关的LAN口地址。
排查过程中的常见误区规避
很多运维人员遇到地址冲突之后第一反应是扩容内网网段，把原有内网的子网掩码改大，这类操作会导致内网大量设备的ARP表刷新不及时，反而扩大故障的影响范围，甚至导致全内网的设备出现连通异常，完全不是最优解法。
还有不少管理员为了快速消除告警，会直接关闭旁路网关的ARP冲突检测功能，假装冲突不存在，这种操作会导致远程VPN客户端随机出现访问资源异常的问题，后续新增内网静态IP设备的时候还会出现新的冲突，属于典型的掩耳盗铃操作。
所有配置调整完成之后，要做一次全量的双向连通性验证，分别用远程VPN客户端访问内网的服务器、打印设备、监控系统，同时用内网的普通设备主动访问VPN分配给远程客户端的虚拟地址，确认双向连通没有异常，避免调整完配置之后留下隐性的连通漏洞。
