很多企业远程办公用户使用VPN接入内部网络时，经常遇到明明显示拨入成功，却打不开内部OA、连不上文件服务器的问题，不少人排查网络故障半天，最后才发现根源是VPN私网地址冲突，也就是本地局域网的网段和远端VPN私网的网段出现重合。这类问题不属于VPN本身的加密传输故障，大多是不同场景下的网段规划疏漏导致的，梳理清楚常见的冲突场景和对应解决方法，能大幅降低VPN运维的排障成本。
家用宽带默认网段引发的VPN私网地址冲突场景
很多普通家用路由器出厂默认的LAN侧网段都是192.168.1.0/24，不少早期企业搭建VPN服务的时候，图省事也把内部办公私网设置成了完全相同的网段，这是普通远程办公用户最常遇到的冲突场景。
这种场景的典型表现是，用户在家拨入企业SSL VPN之后，访问192.168.1.x段的内部业务地址时，系统默认把请求导向家里的路由器管理后台，根本不会走VPN隧道转发，不少用户自己还会疑惑为什么输入OA地址之后跳转到了路由器设置页。
家用宽带默认网段与企业内网网段重合，是VPN私网地址冲突最常见的触发场景
排查这个场景的第一步不需要先调整VPN服务端配置，先在本地Windows设备上打开命令提示符窗口输入route print指令，查看当前路由表中192.168.1.0段的网关，如果同时出现本地物理网卡网关和VPN虚拟网卡网关的两条条目，基本就可以确认是这类冲突。
多VPN同时拨入的叠加冲突场景
不少外包或者跨项目的运维人员，经常需要同时拨入甲方A的IPsec VPN和甲方B的SSL VPN，两个不同远端私网如果都规划了相同的10.0.0.0/8大段，就很容易出现地址冲突，这类场景的隐蔽性比家用场景高很多。
这种场景的故障表现很容易被误判，用户可能能正常访问其中一个甲方的内部资源，但是另一个甲方的服务器要么响应极慢要么直接无法连通，很多人第一反应会怀疑VPN带宽不足，实际上是路由转发的时候把本该发往A甲方的流量错发到了B甲方的隧道里。
这类场景的验证方式也很简单，先断开其中一条VPN，测试剩下那条VPN覆盖的所有资源访问是否正常，再换另一条单独拨入测试，如果单拨状态下所有业务访问都正常、同时拨入就出问题，就可以定位是两个远端VPN的私网网段出现了重叠冲突。
分支机构站点到站点VPN的网段冲突场景
很多连锁企业的门店网络初期搭建的时候，没有做全公司统一的网段规划，每个门店的兼职IT人员自己随便设置路由器LAN地址，后续总部搭建站点到站点IPsec VPN要把所有门店私网打通的时候，就会出现两个门店用了同一段私网地址的问题。
这种场景下的冲突不会直接体现在普通用户终端上，小鸟VPN大多出现在VPN网关设备的路由配置页，当管理员添加感兴趣流规则的时候，部分设备会提示源目地址段重叠，部分老旧款VPN网关甚至不会给出任何提示，直接生成错误的转发规则。
排查这类场景的时候，管理员需要把所有接入VPN的分支机构私网网段全部整理成汇总表格，逐行比对有没有重合的网段，不要只核对总部的网段和分支是否冲突，还要逐一检查不同分支之间的网段是否重叠。
通用的VPN私网地址冲突解决技巧
针对家用场景的冲突，最稳妥的操作是修改本地家用路由器的LAN侧网段，把默认的192.168.1.0/24改成192.168.31.0/24这类不常用的小众网段，修改完成之后重启本地路由器，再重新拨入VPN就可以恢复正常的流量转发逻辑。
针对多VPN拨入的场景，优先在VPN服务端后台配置精细的路由推送规则，不要给终端推送完整的10.0.0.0/8大段路由，只把用户实际需要访问的几个业务小网段推送到终端路由表，从根源上减少不同VPN推送的网段重叠的概率。
针对站点到站点VPN的冲突场景，要重新做全公司的私网地址统一规划，小鸟给每个分支机构分配完全不重叠的固定私网段，后续新接入的站点必须提前报备网段，确认和所有已有接入段没有冲突之后，再接入VPN网络。
需要注意的常见误区是，不少用户遇到冲突之后直接手动修改本地虚拟网卡的IP地址，这种操作很容易导致系统路由规则混乱，小鸟甚至可能出现本地所有上网流量全部被导入VPN隧道的异常情况，非专业运维人员不建议直接手动修改系统路由表。
