很多使用OpenWrt搭建自托管VPN服务的用户，常会遇到远程拨入后无法访问家里NAS共享资源、内网摄像头加载失败甚至拨入后本地网络直接断连的问题，飞鸟VPN掉线原因排查这类故障九成以上都和VPN地址冲突相关，很多新手排查时容易直接去改防火墙规则，绕了很多弯路也没解决问题，本文结合普通家庭和小型工作室的OpenWrt部署场景，给出可直接落地的冲突排查实操流程。
前置排查：先区分冲突发生的网段范围
很多用户刚搭完OpenWrt的VPN服务，比如常用的OpenVPN或者WireGuard，默认给VPN客户端分配的网段和OpenWrt本身的LAN网段是同一段，比如很多人习惯把LAN设为192.168.1.0/24，开VPN的时候没改默认配置也用了同一段，这时候拨入的客户端要访问LAN设备就会出现路由寻址错乱，系统不知道该把数据包往物理LAN口发还是虚拟VPN接口发。
这一步操作不需要修改任何配置，只要登录OpenWrt的网页管理后台，进入接口菜单，把所有已配置的接口网段全部列出来，包括WAN口从上游光猫或者主路由获取的网段、LAN口自身的网段、VPN服务端的虚拟接口网段，如果是旁路由模式部署的OpenWrt，还要把旁路由所在的上游主路由网段也一并记录下来。
这里要注意很多新手容易忽略WAN口的网段，比如家里光猫默认网段也是192.168.1.0/24，OpenWrt的WAN口从光猫拿到同网段地址，飞鸟同时LAN也设成同一段，就算不开VPN本身就已经存在隐性冲突，开VPN之后只会把故障放大，不要一上来就急着修改VPN配置，先把所有三层接口的网段全部核验一遍，排除基础的网段重叠问题。
用户登录OpenWrt管理后台查看接口列表，区分VPN与内网网段排查冲突
VPN服务端配置侧冲突排查步骤
先针对普及率最高的WireGuard服务场景排查，进入OpenWrt的WireGuard配置页，查看服务器端的IP地址/子网掩码项，这里填写的地址是虚拟隧道接口的本地地址，对应的网段就是后续分配给拨入客户端的地址池网段，要保证这个网段和之前记录的所有其他接口网段完全不重叠，没有任何地址段的交叉。
如果使用的是OpenVPN服务，要额外检查luci向导生成的推送路由配置项，很多用户搭远程访问服务的时候，不小心把VPN的全局推送路由设成了和LAN完全一致的网段，就算VPN地址池单独划分了不重叠的段，系统也会优先把对应网段的流量往VPN虚拟接口转发，导致本地内网的设备访问全部失效。
这里有个非常普遍的操作误区，很多用户为了省去配置静态路由的步骤，特意把VPN地址池设成和LAN同一段，想让拨入的VPN客户端和内网设备处于同一个二层网络，这种操作在OpenWrt的默认转发规则下几乎一定会触发地址冲突，因为虚拟接口和LAN桥接口的转发逻辑不兼容，反而会出现一半设备能通、一半设备丢包的奇怪现象。
客户端侧冲突验证与收尾校验
改完服务端配置保存应用之后，先不要急着用外部公网的设备拨VPN，先在OpenWrt本地的终端界面用ping命令测试VPN虚拟接口的网关地址，再随机选一个LAN下的有线设备地址测试连通性，确认本地路由表没有出现下一跳指向错误接口的异常条目。
找一台外部的测试设备拨入VPN，不要直接访问内网资源，先查看拨入之后设备自身获得的VPN虚拟地址，再用路由跟踪命令测试访问OpenWrt LAN网关的路径，确认第一跳是VPN的虚拟网关，而不是设备本身所处的外部网络网关，就能验证VPN侧的路由规则已经正常生效。
如果测试的时候出现部分内网资源能访问、部分资源访问失败的情况，要检查内网有没有其他使用特殊私网网段的设备，比如部分批量部署的IoT设备用了10.0.0.0段的地址，刚好和你VPN分配的网段重合，这时候不需要改动已有的VPN配置，只要给对应IoT设备单独划到其他闲置网段就能解决冲突。
排查完成之后建议把所有网段的规划记录存在OpenWrt的自定义系统备注里，后续新增Docker虚拟网段、旁路由配置或者其他VPN服务的时候，提前核对已有的网段列表，就能从根源上避免再次出现同类的地址冲突问题，减少后续不必要的故障排查时间。
