很多企业远程办公场景下，用户拨完SSL VPN或者IPsec VPN之后，公网访问一切正常，但内部OA、文件服务器、业务系统完全无法连通，不少运维人员第一反应是反复调整网关配置，反而浪费大量排查时间。本文梳理的VPN连接后内网不可达日志分析思路，全部基于主流企业级VPN网关、终端系统的实际日志字段拆解，不需要额外付费第三方工具就能落地，能帮运维人员跳过无效试错环节快速定位根因。
VPN网关侧首条连接日志的基础校验
排查的第一步不要上来就抓终端侧报文，先登录VPN网关的系统日志页面，找到对应拨号用户的认证成功日志条目，先确认系统分配给终端的内网虚拟IP段，是不是和内网业务网段的路由域属于同一个。很多新手运维会忽略日志里“虚拟路由绑定失败”这类非红色告警的隐性提示，以为认证成功就代表接入流程全部完成，实际上如果用户所属的VPN组绑定了错误的虚拟转发实例，就算拨号成功，网关本身也没有往内网转发流量的基础权限。
这里要注意核对日志里的推送路由条目，正常VPN网关认证成功后，会给终端推送内网网段的指向路由，如果日志里显示“路由推送条目超限”或者“指定网段推送失败”，直接就能定位问题，不需要再去终端反复发起ping测试浪费时间。
运维人员优先校验VPN网关侧的拨号连接日志，跳过无效试错快速定位故障根因。
终端系统路由表与VPN进程日志交叉验证
拿到网关侧的日志确认分配地址和推送路由都正常之后，再去终端侧调取日志，Windows系统可以先打开事件查看器，定位到应用和服务日志里的RasClient条目，macOS和Linux可以查看系统日志目录下的ppp或者openvpn相关记录，先确认终端侧有没有成功收到网关下发的路由规则。很多用户终端装了第三方终端安全软件，会默认拦截虚拟网卡的路由写入操作，这类情况VPN网关侧完全不会有任何报错，只有终端日志里会出现“路由添加权限被拒绝”的相关记录。
这一步的验证方式很简单，终端拨号成功之后直接执行route print（Windows系统）或者ip route show（Linux/macOS系统），查看内网业务网段的下一跳是不是指向VPN生成的虚拟网卡地址，如果没有对应条目，就对应终端日志里的路由写入失败记录，直接调整终端安全软件的放行规则即可。
这里常见的误区是很多人会误以为是VPN网关配置错了路由推送，反复去修改网关的配置条目，实际上网关侧已经把路由报文正常发出来了，终端侧拦截之后没有回传报错，才会出现两边信息不对称的情况，交叉核对两边的日志就能快速排除这个干扰项。
内网回程流量的设备日志回溯排查
如果前面两步的日志都没有异常，终端能看到正确的内网路由，VPN网关也显示路由推送成功，接下来就要去内网核心交换机、内网防火墙的日志里找对应VPN虚拟网段的访问记录。很多企业的内网安全域默认是拒绝陌生网段访问的，VPN分配的虚拟IP段如果没有提前加到内网业务区的放行白名单里，终端发往内网的流量到了内网防火墙之后就会被丢弃，这类丢弃日志只会出现在内网安全设备上，VPN网关本身没有对应的流量拦截记录。
排查的时候可以先从终端发起一个往内网业务服务器的长ping，同时在内网核心交换机的日志里找对应源IP是VPN虚拟地址的ICMP报文记录，如果完全没有对应报文的转发日志，说明流量还没出VPN网关的转发域，VPN试用1小时回头再查VPN网关的内网接口放通策略。如果能在核心交换机看到报文进入的记录，但看不到回包的转发日志，那问题就出在业务服务器或者内网防火墙的回程路由配置上。
这里很容易踩的坑是很多运维默认内网设备已经配置了到VPN虚拟网段的回程路由，实际上前期配置的时候漏写了静态路由，业务服务器收到VPN终端的请求之后，不知道往哪个地址段回包，直接把回包丢给公网网关，自然终端就收不到内网的响应，这类情况在日志里的表现就是只有单向的访问请求记录，完全没有回包相关的日志条目。
特殊场景下的日志特征匹配
还有一类比较隐蔽的故障，就是VPN连接后内网部分网段可达、部分网段不可达，这种情况直接去查VPN网关日志里的ACL命中记录，很多企业为了做权限隔离，给不同VPN用户组配置了细粒度的内网访问控制，ExpressVPN官网运维调整内网网段之后忘记同步更新VPN侧的ACL规则，就会出现部分业务能访问、部分业务不通的情况，日志里会明确标注对应访问流量被VPN网关的ACL策略拒绝。
整个排查流程不需要一开始就开启全流量抓包，顺着VPN网关日志、终端日志、内网转发设备日志的顺序逐层定位，就能把VPN连接后内网不可达的日志分析思路落地，大部分常见故障都能快速定位根因，不需要做无意义的全量配置遍历。
