不少远程办公的企业用户都遇到过VPN客户端显示连接成功，却完全无法访问内网共享文件夹、业务服务器的问题，多数人只会反复重连VPN、重启设备，反而耽误故障恢复时间，这套VPN连接后内网不可达：日志分析思路指南全部基于实际运维场景的落地操作，不需要复杂的抓包工具，逐层核对日志就能定位绝大多数常见故障点。
第一步：优先定位VPN客户端本地日志的关键标记点
目前主流的SSL VPN、IPsec VPN客户端大多默认在本地留存运行日志，不需要提前开启调试模式就能直接查看，首先要在日志里找隧道协商完成后的后续执行记录，很多人误以为VPN连接成功就代表全链路通，实际上日志里只有显示“策略推送完成”的字段，才代表总部VPN网关的安全规则已经把允许访问内网网段的配置下发到本地，要是日志卡在“路由注入阶段失败”的提示，说明设备根本没有获取到访问内网所需的静态路由，这时候直接测试内网访问自然不会有响应。
这里要特别注意区分日志里两个容易混淆的状态，“隧道连接成功”的记录只代表用户设备和总部VPN网关的外层加密通道已经建立完成，不代表内层的转发、权限规则已经全部生效，很多用户看到客户端界面的绿色对勾标识就跳过日志检查直接测试业务，白白浪费大量不必要的排查时间。
运维人员通过查看本地VPN客户端日志逐层定位内网访问故障点
第二步：关联网关侧日志核对隧道权限匹配结果
如果你在本地客户端日志里已经确认路由注入流程执行成功，接下来就可以联系企业网络管理员导出VPN网关的对应隧道日志，用你本地获取的虚拟IP地址作为过滤关键词，查找对应会话记录里有没有出现“网段访问拒绝”的匹配条目，很多时候是你的账号所属用户组近期被运维人员调整过，原本开放的内网业务网段权限被误收回，这类问题本地客户端日志不会给出明确提示，只会静默丢弃访问内网的报文。
排查这个环节的时候不要直接要求管理员修改权限，先把你本地日志里的公网出口IP、隧道建立的精确时间、分配到的内网虚拟IP三个信息同步给管理员，网关侧可以直接过滤对应时间段的目标会话，不用翻查全量的用户连接记录，能大幅缩小排查范围，排除无关的干扰项。
第三步：通过流量日志验证内网回程路径是否通畅
如果协商日志和权限校验都没有异常，内网访问还是无响应，这时候就要在网关侧开启对应隧道的流量日志记录，你在本地尝试ping一台确认在线的内网业务服务器，看流量日志里有没有对应的ICMP请求报文到达内网接口，如果日志里完全没有这条请求的记录，说明是VPN隧道内的转发规则出了问题，免费加速器用户发出的报文根本没有被正确转发进内网域。
如果流量日志里能看到你发出的ICMP请求已经到达内网服务器的直连网段，但是完全没有回程报文的相关记录，那大概率是内网业务服务器的默认路由没有指向VPN网关，很多内网服务器之前只配置了内网三层交换机的静态路由，没有把返回给VPN虚拟IP段的路由指向VPN网关，这类问题在客户端和网关的协商日志里完全不会有报错提示，只有流量日志能精准定位到故障点。
第四步：排查本地路由表与VPN日志的匹配偏差
还有一类高频故障场景是用户本地本身就配置了和目标内网网段重合的静态路由，比如之前为了访问公司旧测试环境手动添加过路由规则，VPN连接之后新注入的路由和旧路由出现优先级冲突，这时候看VPN日志里明明显示路由注入成功，但是操作系统选路的时候优先走了本地旧的无效路由，自然没法到达内网地址。
这类场景下你可以在本地执行对应系统的路由查询命令，Windows系统用route print，Linux和macOS系统用ip route show，把当前系统的路由表和VPN日志里打印的注入路由条目逐行比对，如果发现有同网段的优先级更高的冲突路由条目，删掉无效的旧路由之后重连VPN就能恢复，这类问题在多网卡的办公设备上出现概率很高，很多人外接了公司物理内网网线之后又远程连VPN，很容易出现路由优先级错乱的情况。
整套VPN连接后内网不可达的日志分析思路不需要一开始就动用复杂抓包、vpn下载更换设备测试等操作，从客户端本地日志到网关协商日志再到流量日志逐层递进，就能覆盖绝大多数常见故障场景，不要一遇到问题就直接重装VPN客户端，很多时候重装只会把本地留存的运行日志清空，反而丢失了最直接的故障定位线索。
