很多用户在OpenWrt上部署OpenVPN、WireGuard这类VPN服务的时候，经常会遇到客户端连入后无法访问内网资源、甚至整个局域网断流的问题，多数情况都是VPN服务端配置的虚拟网段和OpenWrt本身的LAN网段产生了地址冲突，这篇指南就从实际运维场景出发，一步步带你定位冲突点，不用反复刷固件就能快速解决问题。
第一步：先确认地址冲突的直观现象
很多新手遇到VPN连不上、连上之后打不开内网NAS、甚至连OpenWrt管理后台都进不去的情况，第一反应是VPN密钥配置错了，其实先排查地址冲突能节省大半时间。正常情况下VPN客户端拨号成功后，应该能拿到VPN服务端分配的虚拟IP，同时能正常访问OpenWrt LAN侧的所有设备。如果拨号成功后，客户端显示的虚拟IP和你家局域网的IP段开头三位完全一致，比如LAN是192.168.1.x，VPN分配的也是192.168.1.x，那大概率已经触发了地址冲突。
还有一类隐蔽的现象是，部分内网设备能访问，部分完全不通，比如你手机连VPN能访问家里的监控，但是笔记本连VPN就只能上外网碰不到任何内网资源，这时候要检查是不是VPN网段和局域网内某个静态绑定的设备IP完全重合，出现了IP抢占的问题。这类隐蔽冲突不会导致全局断网，很容易被误判成VPN的权限配置错误，优先排查IP重合问题能跳过很多不必要的配置核对步骤。
对照指南一步步排查VPN网段与LAN网段的冲突问题，无需重刷固件即可快速修复故障
检查OpenWrt本身的多网段配置重叠
进入OpenWrt的管理后台，梯子找到网络-接口页面，先把所有已经启用的接口网段全部列出来，除了默认的LAN口，很多用户还开了访客WiFi、Docker虚拟网桥、旁挂AP的管理网段，这些网段都不能和你VPN服务里配置的虚拟网段重合。很多用户之前配置其他服务的时候随手用了默认网段，自己都记不清开了多少个虚拟子网，这一步全部梳理出来就能排除大半隐藏冲突。
比如很多人部署Docker跑插件的时候，默认Docker生成的网桥网段是172.17.0.x，如果之前配置VPN的时候随手选了172.17.0.x作为虚拟地址池，就会直接出现冲突，导致VPN的路由转发规则完全失效。这一步的预期结果是，你整理出来的所有本地接口网段，没有任何一个的子网范围和VPN设置里的虚拟IP池范围有交集。
这里有个常见误区，很多用户以为只要网段开头数字不一样就不会冲突，比如LAN是192.168.1.0/24，VPN设成192.168.1.128/25，就觉得没问题，实际上两个网段都属于192.168.1.0/24的大子网，还是会触发ARP地址抢占，导致部分设备直接断网。配置网段的时候不能只看前三位，要结合子网掩码判断两个网段的地址范围有没有重叠区域。
排查VPN服务端的路由推送配置错误
很多OpenWrt的VPN配置教程里，会让用户推送“允许所有流量走VPN”的全局路由，如果你配置的虚拟网段和你家宽带运营商的光猫默认网段重合，比如光猫本身的管理地址是192.168.0.1，你VPN的虚拟网段刚好设成192.168.0.0/24，就会导致拨号后的客户端把光猫的管理流量全部往VPN接口转发，直接出现连外网都失败的情况。
这一步的检查方法很简单，进入VPN服务的配置页面，找到虚拟IP地址池、推送的内网路由两个选项，把当前配置的网段和光猫后台的LAN网段做比对，同时也要和你常用的外部网络比如公司内网、学校内网的常用网段做区分，避免你在外网连家里VPN的时候，和当前所处的网络网段冲突。这一步的预期结果是，VPN配置的虚拟网段，和所有你会用到的本地、远端内网网段都完全错开，推荐选10.0.0.0/8里平时很少用到的小网段，比如10.8.0.0/24作为VPN专属网段。
验证修改后的配置有效性
改完VPN的网段配置之后，不要忘了重启OpenWrt的VPN服务进程，不要直接重启整个路由器，避免其他正在跑的业务中断，等进程完全重启之后，先拿一台不在当前局域网内的设备拨号测试，快鸭看拿到的虚拟IP是不是属于新配置的网段。如果拨号过程直接报错，就回去检查VPN配置文件里有没有残留之前旧网段的路由规则，删掉冗余规则之后再重启进程即可。
如果测试之后已经能正常访问OpenWrt后台、内网的NAS和其他智能设备，再检查局域网内原本出现断流的设备是不是已经恢复正常，要是还有个别设备访问异常，就去检查那台设备的ARP表，有没有残留之前冲突IP的错误映射，清空ARP缓存之后就能恢复正常。
整个OpenWrt VPN地址冲突排查的流程不需要用到额外的专业工具，只要捋清楚所有本地生成的网段范围，不贪图方便用默认的常见192.168.x.x网段，就能从根源上避免绝大多数的地址冲突问题，快鸭后续如果要新增Docker网桥、访客网络这类新接口，也可以提前先和VPN网段做比对，就不会再出现同类故障。
