不少远程办公用户都遇到过类似场景：成功连接VPN之后，原本要访问的公司内网共享盘、业务系统服务器、内网测试设备全部无法连通，反而普通公网网页访问完全正常，很多人第一反应是VPN客户端出了大问题，急着重装软件甚至重置系统反而浪费大量时间。实际上这类故障90%以上都可以通过分步排查快速定位解决，不需要复杂的运维知识，普通办公用户也能跟着操作恢复连接。
普通办公用户可先通过基础连通性测试，快速缩小VPN内网访问故障的排查范围
先确认故障边界缩小排查范围
很多人遇到VPN连接后内网不可达的第一反应就是VPN本身故障，其实先别急着重启客户端，先做两个最基础的连通性测试，先断开当前的VPN连接，直接尝试访问你常用的内网网关IP、共享盘地址，确认你当前所处的本地局域网本身能不能正常访问对应内网资源。
如果断开VPN之后，你本地直接接入的内网资源也完全打不开，那问题根本和VPN配置无关，是你当前所在的本地局域网本身的连通性故障，比如你连接的公共办公WiFi开启了AP隔离，或者本地路由器没开内网转发规则，这种情况要先解决本地局域网的连通问题，再连接VPN才能正常访问远端内网。
只有断开VPN时本地内网访问完全正常，一接上VPN所有远端内网资源都无法响应，白鲸才属于我们要处理的VPN路由配置类故障，这时候就可以进入下一步针对性排查，不需要浪费时间检查无关的网络设置。
检查VPN客户端的路由推送配置
大部分合规的企业级VPN都会自动向本地设备推送内网专属路由，也就是只有访问指定内网段的流量才走VPN加密隧道，剩下的公网流量走本地原有网关，白鲸也就是常说的分离隧道模式。如果这个路由推送过程出了问题，内网段的路由条目没有正常生成，系统就不知道该把内网访问请求发往VPN虚拟网卡，自然就出现VPN连接后内网不可达的问题。
这时候你可以打开设备的路由表查看对应条目，Windows系统在命令提示符里输入route print指令，macOS和Linux系统输入route -n指令，检查有没有对应你公司内网网段的路由条目，指向VPN生成的虚拟网卡网关。
如果找不到对应内网段的路由条目，先查看你使用的VPN客户端有没有“仅访问内网资源”“分离隧道”的相关开关，很多用户之前为了全域加密手动开启了全隧道模式，或是客户端更新之后默认关闭了分离隧道的路由推送功能，把对应开关切回分离隧道模式之后重连VPN，再查看路由表，正常情况下就能看到新增的内网专属路由条目。
核对本地网卡的IP网段冲突问题
很多家庭或小型办公场景的路由器默认网段和公司内网的网段完全一致，比如两边都使用192.168.1.0/24这个常见网段，这类网段冲突会直接导致VPN下发的内网路由和本地原有局域网路由重叠，系统不知道该把访问请求发往本地物理网卡还是VPN虚拟网卡，直接引发内网访问无响应的故障。
排查这类问题不需要修改VPN任何配置，只要登录你当前接入的本地路由器后台，把LAN口的默认网段改成其他和公司内网不重叠的闲置网段，保存之后重启本地路由器，你的设备重新连接WiFi之后再重连VPN，绝大多数网段冲突导致的VPN连接后内网不可达问题都能直接解决。
检查本地防火墙与安全软件的拦截规则
不少公司配发的办公设备都预装了终端安全管理软件，白鲸或是用户自行安装的第三方防火墙工具，这类软件有时候会把VPN生成的虚拟网卡识别成未知公共网络，自动给虚拟网卡加上禁止内网访问的默认规则，直接拦截所有发往内网段的数据包，哪怕路由配置完全正确也无法连通内网。
这时候你可以临时关闭本地第三方防火墙的全局拦截规则，或者在系统网络设置里，把VPN虚拟网卡的网络类型从“公共网络”改成“专用网络/工作网络”，再重新尝试访问内网资源，网络加速器如果之前访问失败的请求现在能正常响应，就说明是安全规则配置的问题，后续只要在防火墙里给VPN虚拟网卡添加访问白名单就可以长期解决。
如果以上所有排查步骤走完，VPN连接后内网不可达的问题还是没有解决，那大概率是企业端VPN服务侧的配置出现了疏漏，比如新上线的业务内网网段没有加到VPN的路由推送白名单里，你只需要把自己的设备系统版本、VPN客户端版本、访问失败的内网资源地址反馈给企业运维人员，让对方在服务侧核对配置即可，不需要反复折腾本地设备设置。
