很多自行部署OpenWrt VPN的用户，不管是为了远程回家调取NAS文件，还是外出时连回公司内网访问业务系统，经常会碰到连接VPN之后本地互联网断连、内网设备无法访问的异常，这类故障有相当高的概率是地址冲突引发的。不少新手排查时只会反复删除VPN配置重连，找不到问题根因，反而浪费大量时间，本文就把这类故障的常见诱因、可落地的排查步骤和避坑方案全部梳理清楚，帮大家快速定位解决问题。
最常见冲突场景：本地终端网段与VPN虚拟网段重叠
这是绝大多数新手第一次搭OpenWrt VPN就会踩的坑，很多用户拿到OpenWrt固件之后从来没改过默认LAN网段，大多保留了出厂的192.168.1.0/24段，而很多用户外出时连接的酒店、公司公共WiFi，本地局域网刚好也在用同一个192.168.1.0/24网段，连VPN之后终端系统的路由规则会出现错乱，把原本发往本地网关的数据包错导向VPN隧道，直接导致本地网络失联。
排查这个故障不需要改动OpenWrt的任何配置，先拿正在连接VPN的终端分别查询本地物理网卡的网段，以及VPN虚拟网卡被分配的网段，Windows系统用ipconfig命令、macOS或者Linux系统用ip a命令就能看到两个网卡的网段信息，对比两个网段的网络位，如果完全重合就可以直接定位是这类冲突。
解决的时候不要随便修改终端的静态IP，正确操作是登录自己家的OpenWrt后台，进到接口设置页面把LAN侧的网段改成不常用的私网段，比如192.168.9.0/24这类很少被公共WiFi默认使用的段，改完之后等待路由规则自动刷新，再重连VPN就能恢复正常。这里要提醒一个常见误区，很多人改完LAN段之后忘了同步调整OpenWrt内置的DHCP地址池范围，导致后续新接入的无线设备拿不到IP，反而引出新的网络故障。
OpenWrt VPN服务端虚拟地址池与内网物理网段冲突
这类场景一般出现在用户把OpenWrt直接作为VPN服务端使用的情况，不少用户配置VPN服务的时候图省事，直接把给远程接入设备分配的虚拟地址池，设置成和现有LAN网段完全相同的段，甚至直接复用了内网里摄像头、办公服务器已经静态绑定的IP段。
这类故障的表现不是终端连不上VPN，而是连接VPN之后远程访问OpenWrt内网的特定设备完全没响应，ping目标IP直接全部丢包，很多用户碰到这种情况第一反应是VPN的防火墙转发规则没开，反复调整端口映射和区域权限，折腾很久也解决不了问题。
排查的时候先登录OpenWrt后台，进到对应VPN服务的配置页面，查看虚拟地址池的网段设置，再对照内网所有静态分配IP的设备清单，把两个网段做完整比对，如果没有整理好的内网IP清单，可以用OpenWrt自带的ARP扫描工具扫一遍内网所有存活的IP，就能快速发现重叠的网段范围。
解决的时候直接调整VPN服务的虚拟地址池，选择一个完全不涉及现有内网物理网段的独立私网段，比如专门用10.0.0.0/24段给所有VPN远程接入的终端分配地址，同时要在OpenWrt的防火墙区域设置里，确认VPN对应的接口和LAN接口的互访权限已经放开，保证两个网段的设备可以正常传输数据。
多VPN隧道叠加的隐蔽地址冲突排查思路
不少进阶用户会在OpenWrt里同时部署两套甚至更多VPN服务，比如一套用来远程回连家里的内网，另一套用来做公网传输加密，这种场景下不同VPN服务各自分配的虚拟网段很容易出现重叠，引发系统路由规则紊乱。
这类故障的表现非常隐蔽，不会直接导致完全断网，通常是部分公网网站能正常打开、部分内网资源完全无法访问，普通用户很难联想到是地址冲突的问题。排查的时候可以登录OpenWrt的系统终端，用ip route show命令导出所有生效的路由条目，要是看到两个不同的网络接口指向同一个目标私网网段的规则，这类重复路由就是冲突的直接证据。
解决的时候要给每一个部署在OpenWrt里的VPN服务单独规划完全独立的虚拟网段，多个VPN就用多个完全不重叠的私网段，不要有任何地址范围的交叉，配置完之后再逐条核对路由表，确认没有重复的网段指向规则即可。
很多用户碰到OpenWrt VPN地址冲突的时候第一反应是升级固件或者更换VPN协议，其实绝大多数场景下根本不需要改动核心配置，只要顺着本地终端网段、OpenWrt LAN网段、VPN虚拟地址池、多隧道路由这几个层级逐层排查，基本都能快速定位问题，不需要额外安装第三方插件就能完成修复。
