很多用户开启全局VPN之后，发现没法访问家里的NAS、办公室的共享打印机、同网段的监控摄像头，折腾半天以为是VPN线路故障，其实大概率是VPN排除局域网规则配置出错了。这类规则的核心作用是让本地局域网的访问流量不经过VPN隧道，既不影响内网设备互访，也能保证外网流量走加密通道，很多普通用户甚至运维新手配置时很容易踩坑，最后反而出现内网断连、路由冲突的各类问题。
最常见的规则顺序颠倒错误
很多人配置VPN分流规则的时候，习惯先加“全局流量走VPN”的默认策略，后面再补“排除局域网”的规则，这种顺序在大部分开源客户端和企业VPN网关里是直接失效的。因为路由匹配逻辑是从上到下优先级递减，前面已经把所有流量都指向VPN虚拟网卡，后面加的局域网段规则根本不会被触发。
排查这个问题的时候可以先打开设备的路由表，查看目标局域网段的下一跳地址，如果下一跳显示的是VPN虚拟网卡的地址，就说明规则顺序写反了。正确的调整方式是把所有局域网排除的规则移动到VPN默认路由的前面，再重新加载配置。
局域网段覆盖不全的隐性错误
不少用户对局域网的认知只停留在192.168.1.0/24这个最常见的网段，配置排除规则的时候只加了这一个段，完全忽略了自己网络里可能存在的其他内网网段。比如很多运营商光猫默认的管理网段是192.168.0.0/24，部分公司办公网同时划分了办公业务、IoT设备、服务器存储三个不同的内网VLAN，网段完全不在预设的范围内。
还有很多人会漏掉RFC1918标准里定义的另外两个私网地址段，也就是10.0.0.0/8和172.16.0.0/12这两个大段，一旦你所在的内网使用了这两类网段，排除规则就相当于完全没生效。检查的时候可以先查看本地网卡的IP地址、子网掩码，再扫描同网段下已经分配的设备IP，把所有用到的私网网段都逐一加入排除列表，不要只留默认的单个小网段。
虚拟网卡网段冲突导致的规则失效
很多人配置完排除规则之后，明明网段和顺序都没问题，还是没法访问内网的特定设备，这时候要排查VPN虚拟网卡本身分配的IP网段，是不是和你本地局域网的网段重合了。比如你本地内网用的是10.8.0.0/24段，VPN服务端给虚拟网卡分配的地址池刚好也是10.8.0.0/24，系统路由会直接判断这两个网段属于同一个逻辑子网，分流规则根本没法区分流量该走本地网卡还是VPN隧道。
这类冲突问题排查起来很隐蔽，因为你访问内网设备的时候不会直接提示路由错误，只会出现连接超时、丢包率忽高忽低的现象。调整的时候可以修改VPN服务端的虚拟地址池配置，把它改成完全不和本地私网网段重叠的其他地址段，之后再重新连接VPN测试内网访问。
网关级VPN和终端级VPN的规则混用误区
现在很多用户会同时用两种VPN，一种是路由器上刷固件配置的全局网关VPN，另一种是电脑手机上单独装的终端客户端VPN，这两类场景下的排除局域网规则配置逻辑完全不一样，很多人直接把终端上的配置逻辑套到路由器上，就会出现整个内网所有设备都没法互访的问题。
在路由器网关侧配置排除规则的时候，你不能只把路由器自身的管理网段加入排除列表，还要把所有内网设备的互访流量都标记为不需要走VPN隧道，否则手机访问同网段的电视盒子、电脑访问NAS的流量都会被强行送到VPN远端节点，不仅速度极慢，甚至直接连接失败。配置完成之后可以尝试用内网设备之间互传文件测试，如果传输速度和没开VPN的时候一致，就说明排除规则生效正常。
规则生效后的二次校验方法
很多用户配置完规则之后，随便点开一个内网共享文件夹能访问，就以为整个排除规则没问题，实际上部分边缘场景的网段很容易被遗漏。完整的校验流程应该先尝试访问光猫管理后台、内网打印机、本地部署的私有云服务，再访问VPN远端节点的内网资源，确认两类流量的走向都符合预期，没有出现不该走隧道的流量被加密、该走隧道的流量漏回本地运营商网络的问题。
还要注意不要随意添加来源不明的全局分流规则包，很多网上流传的规则包为了实现全量外网流量走VPN，会直接把所有私网段的排除规则删掉，你导入之后哪怕之前配置是正常的，也会直接出现内网访问故障。每次更新分流规则之后都要重新核对一遍局域网排除相关的条目，避免被其他规则覆盖。
