很多远程办公用户连接企业VPN之后，明明客户端提示连接成功却访问不了内网的OA、文件服务器这类资源，大部分人第一反应是VPN服务出了问题，其实按照VPN连接后内网不可达：日志分析思路逐层拆解，不用盲目重启客户端或者反复输入账号密码，就能快速定位绝大多数常见问题，还能避免误改本地网络配置引发的其他上网故障。
第一步：优先核验VPN客户端侧的本地日志完整性
很多用户排查故障的第一个误区是直接联系运维人员调整企业端的VPN网关配置，忽略本地客户端生成的连接日志里已经藏了绝大多数前置故障线索。
打开你当前使用的VPN客户端的日志存储目录，先逐行检查从发起连接请求到提示连接成功的全流程记录，小火箭共享账号网站重点看身份认证阶段有没有异常报错、加密隧道协商阶段的参数有没有和服务端预设规则匹配。
这里要注意一个常见误区，不要把客户端弹出的“连接成功”提示当成隧道完全建立的依据，很多轻量VPN客户端只会校验控制链路的连通性，不会校验数据转发链路的状态，日志里如果出现“路由推送失败”“内网网段匹配冲突”这类字段，基本就可以直接定位问题出在路由下发环节，不需要再额外测试外网连通性。
居家远程办公的用户正在操作设备查看日志，逐层排查VPN连接后内网无法访问的故障。
第二步：结合系统路由表日志校验转发规则优先级
完成客户端侧日志核验之后，接下来要调取本地操作系统的路由表生成日志，对照VPN服务端推送的内网网段路由条目，检查有没有出现本地原有路由和VPN下发路由的冲突。
这类场景在实际使用中出现的概率非常高，很多用户本地办公的局域网网段和企业内网的网段完全一致，VPN连接之后系统路由表会出现两条同优先级的同网段路由，系统默认会优先走本地物理网卡的转发路径，自然就访问不到远端的内网资源，这类问题在系统路由日志里会直接标注路由冲突的提示。
这个阶段不要随便手动添加静态路由强制指向VPN虚拟网卡，如果你没有完整梳理本地所有网段的转发需求，很容易出现连接VPN之后本地打印机、局域网共享设备也无法访问的次生问题，正确的做法是先调整本地局域网的网段配置，避开和企业内网重叠的地址段。
第三步：回溯VPN网关侧的用户接入日志定位权限类问题
如果前两步的日志都没有发现异常，就可以联系企业网络管理员调取VPN网关的对应接入日志，按照VPN连接后内网不可达：日志分析思路，核对你的接入账号对应的内网访问权限配置。
很多企业的VPN网关会给不同部门的用户划分不同的内网访问权限，部分用户的账号只开通了远程桌面接入权限，没有开放内网资源的IP网段放行规则，这类情况在网关日志里会直接记录你的访问数据包被策略拦截的记录，不是隧道本身的连通性故障。
这里要注意一个常见的配置误区，很多管理员调整完用户权限之后没有同步更新VPN的网段推送列表，导致用户的客户端没有拿到对应内网资源的路由条目，就算权限已经开通也无法正常访问，对照网关日志里的推送路由列表和用户本地拿到的路由条目做比对，就能快速确认是不是这个问题。
第四步：通过ICMP探测日志验证隧道数据转发有效性
完成前面三步的排查之后，最后可以在内网的核心交换机上开启临时的ICMP访问日志，追踪你设备发向内网资源的ping包转发路径，确认数据包是在隧道中途被丢弃，还是根本没有进入VPN加密隧道。
如果探测日志显示数据包始终走本地公网网关转发，说明本地的路由规则没有生效，回到之前的路由表环节重新校验配置即可；如果数据包已经成功抵达内网网关但没有回包，shadowrocket就可以排查内网资源服务器本身的访问限制规则，比如有没有绑定客户端IP地址段、有没有放通VPN虚拟网卡的地址段访问权限。
整个排查流程里不要跳过日志核验的步骤直接修改配置，很多看似随机的内网不可达故障，日志里早就留下了完整的故障时间线和报错标记，顺着VPN连接后内网不可达：日志分析思路逐层推进，既能减少无效的排查操作，也能避免误改网络配置引发的其他使用问题。
