很多用户在通过VPN访问远端企业内网资源时，经常碰到一类诡异故障：连接VPN之后，本地局域网的打印机、NAS存储、监控摄像头全部失联，甚至输入路由器管理地址也跳转到陌生的网关页面，反复重启VPN客户端和本地路由器都没法恢复，这类故障绝大多数都属于VPN私网地址冲突问题，本文将从现象、关联原理到逐项排查步骤，理清这类故障和局域网的深层关系，给出可落地的常规解决方法。
冲突现象的典型表现
最常见的冲突表现是连接VPN前后本地局域网的可用性出现明显反差：断开VPN的时候，本地所有内网设备访问完全正常，没有丢包或者延迟异常的情况，一旦VPN隧道建立完成，所有指向本地私网段的请求全部失效，部分场景下还会出现公网访问也跟着异常的情况。
连接VPN后本地局域网设备失联，大多是私网地址冲突导致的
不少用户第一反应是VPN客户端损坏或者本地网卡故障，反复重装软件、更新驱动都没法解决问题，本质上这类故障和硬件本身的运行状态没有关系，核心根源出在地址空间的重叠上。
VPN私网地址冲突与局域网的核心关联
目前几乎所有家用、小型办公局域网的地址规划，都遵循RFC1918定义的私网地址规范，其中192.168.0.0/24、192.168.1.0/24这类网段是路由器出厂默认配置最高的选项，而不少企业搭建VPN服务的时候，远端内网也随手选用了这类通用私网段，两端的私网地址空间就出现了重合的可能。
当VPN客户端成功连接远端服务端时，系统会自动往本地路由表中添加指向VPN隧道的转发规则，这类路由的优先级往往高于本地局域网的普通路由，一旦本地局域网的网段和VPN推送的远端网段完全重合，操作系统就无法区分发往该网段的数据包，到底是要送到本地局域网的设备，还是走加密隧道送到远端内网，最终本该发往本地局域网的流量被错误转发到VPN隧道，就出现了本地内网资源全部失联的冲突现象。
第一步排查：确认两端网段的重叠情况
排查的第一步先断开VPN连接，登录本地局域网的路由器管理后台，找到LAN口配置页面，记录下当前本地局域网使用的私网段和对应的子网掩码，确认本地所有设备的DHCP地址分配范围。
之后重新连接VPN，在本地设备上查看系统路由表，Windows系统可以通过route print命令查看所有生效的路由条目，macOS和Linux系统可以通过netstat -rn命令查看，对比VPN推送的远端内网路由和之前记录的本地局域网网段，网络加速器如果出现完全重合或者部分地址段重叠，就可以直接定位是地址冲突导致的故障，这一步排查完成后就可以排除DNS异常、网卡硬件故障这类无关问题。
常见的合规解决方法
对于普通个人用户或者小型局域网场景，最稳妥的方案是修改本地局域网的私网段，比如原来本地使用192.168.1.0/24网段，可以更换为192.168.100.0/24这类使用率较低的私网段，修改完保存路由器配置并重启，等待本地所有设备重新获取新网段的IP地址之后，再连接VPN就不会出现路由重叠的问题，全程不需要调整远端VPN的任何配置。
如果没有权限修改本地路由器的网段配置，也可以尝试调整VPN客户端的自定义路由规则，在支持自定义路由的客户端配置页面，把本地局域网的完整网段添加到排除转发列表中，指定该网段的流量全部走本地网卡直接转发，不进入VPN隧道，这样哪怕两端网段有重叠，本地局域网的流量也不会被错误拐走，不过这个配置需要VPN服务端开放客户端自定义路由的对应权限，否则修改之后不会生效。
如果是企业侧的网络管理员，收到大量移动办公用户反馈同类冲突问题，可以重新规划远端VPN内网的私网段，避开家用局域网最常用的几个通用私网段，从根源上降低普通用户碰到地址冲突的概率，这类调整需要同步修改远端内网的网关、DHCP服务器等相关配置，整体工作量相对大，但可以解决绝大多数终端用户的冲突隐患。
需要避开的常见误区
不少用户碰到冲突之后，直接给本地设备设置静态IP试图绕开重叠网段，网络加速器这种操作只能让单台设备临时恢复本地局域网访问，其他接入局域网的设备还是会出现冲突，后续连接VPN的时候依然会出现路由抢占的问题，属于治标不治本的操作。
还有部分用户误以为只要连接VPN就必然要牺牲本地局域网的访问权限，实际上只要两端的私网段规划完全错开，完全可以同时正常访问本地局域网资源和远端VPN内网资源，快狗VPN不需要反复断开VPN来回切换网络环境。
