很多自行搭建OpenWrt VPN的用户，经常会遇到VPN客户端接入后无法访问内网设备、部分网页加载异常、隧道频繁断连的问题，排查了协议配置、端口映射、防火墙规则之后都找不到原因，这类故障里有超过七成的诱因都是IP地址冲突。这篇教程从配置前置校验到分层故障定位，一步步拆解OpenWrt VPN地址冲突排查的完整流程，普通用户不需要专业网络工具就能完成全流程排查，解决绝大多数同类故障。
配置前的网段规划前置校验
绝大多数OpenWrt VPN地址冲突的根源，都来自配置初期的疏漏，很多用户直接沿用VPN服务端的默认网段，完全没有提前核对现有网络的所有私网段，后续出现故障之后很难第一时间联想到网段重叠的问题。
配置OpenWrt VPN之前的核心前提，是先梳理当前OpenWrt系统下所有正在使用的私网网段，包括主LAN侧的默认网段、下级有线AP和无线AP的独立网段、Docker容器占用的自定义网段、旁路由配置的专属网段，以及后续要分配给VPN接入客户端的服务端网段，所有这些网段必须完全不重叠，连大段的前三位地址都不能重合。
很多新手的常见误区是以为VPN是独立加密隧道，分配的地址和本地内网完全隔离，实际上只要开启了VPN的内网路由转发功能，OpenWrt系统就会把VPN服务端的分配网段直接注入主路由表，两个同网段的路由条目同时存在时，内核的数据包转发逻辑会直接混乱，根本分不清该把数据包送往本地内网设备，还是送往隧道另一端的远程VPN客户端。
普通用户无需专业网络工具，即可逐步核对所有在用私网段排查OpenWrt VPN地址冲突故障
第一层故障定位：本地路由表冲突排查
排查地址冲突的第一步，先登录OpenWrt的网页管理后台，进入「网络」板块下的「路由」选项，直接查看系统当前生成的所有路由条目，重点核对有没有两个目的网段完全重合的规则。
这里要注意区分不同VPN协议的路由生成逻辑，OpenVPN的服务端默认会自动向系统注入VPN分配网段的路由，WireGuard的相关路由需要用户手动配置，如果之前配置过其他虚拟专网服务、免费梯子自定义VLAN网段，很容易和VPN的分配段撞在一起，确认冲突之后直接删掉重复的冗余路由条目，给VPN服务更换一个完全不重叠的闲置网段再重启服务，大部分基础的本地冲突就能直接解决。
第二层故障定位：远程客户端侧的网段冲突排查
不少用户会遇到这类特殊场景：家里部署的OpenWrt VPN配置完全正常，本地测试接入一切正常，但在外部其他网络环境下接入VPN，vpn加速器却完全访问不到家里的内网设备，这时候排查OpenWrt本地的路由表没有任何问题，故障根源其实出在客户端当前所在的局域网网段上。
这类场景的冲突逻辑是，用户当前所处的外部网络，比如公司内网、酒店公共WiFi的局域网网段，刚好和OpenWrt VPN推送的家庭内网网段完全重合，客户端的本地系统收到VPN下发的路由规则之后，根本分不清当前要访问的IP地址是本地局域网的设备，还是隧道另一端的家庭内网设备，直接把数据包往本地局域网转发，加密隧道的转发逻辑就完全失效了。
解决这类跨场景冲突的方法，不能只调整VPN服务端的分配网段，最好直接把OpenWrt主LAN的默认网段改成比较少见的私网段，避开绝大多数公共场所默认使用的192.168.1.0/24、192.168.0.0/24这类通用网段，也可以在OpenWrt的VPN配置里开启精细化的策略路由规则，只把需要访问的内网特定网段路由推送给客户端，不要推送全量内网段，就能大幅降低这类跨网冲突的发生概率。
常见配置误区的修正方法
很多用户为了实现VPN接入之后可以同时访问内网和公共网络，直接在VPN配置里开启了全局NAT转发，这时候如果VPN网段和主LAN网段出现部分重叠，会出现部分内网设备能正常访问、部分设备完全无法连通的诡异情况，很多人误以为是VPN协议的兼容性问题，反复更换协议版本浪费大量时间，实际上只要把两个网段完全错开，故障就会立刻消失。
还有一类很容易被忽略的隐性冲突场景，就是OpenWrt下配置的IPv6 ULA私网地址段，和VPN服务分配给客户端的IPv6前缀出现重合，这类冲突不会出现在IPv4的路由表中，很多用户排查的时候直接跳过了IPv6相关的配置项，导致故障持续存在，排查地址冲突的时候要同时核对IPv4和IPv6的所有私网段，不要只检查其中一部分。
做完所有排查调整之后，可以找一台不在本地局域网内的远程设备接入VPN，分别测试访问内网不同网段的设备，以及正常访问公共网络的连通性，确认没有路由跳转错误、部分网站打不开的异常情况，就说明地址冲突的问题已经完全解决。后续新增任何内网网段、调整VPN相关配置的时候，都先核对一遍所有在用网段的唯一性，就能从源头避免这类故障再次出现。
