很多企业用户在远程接入SSL VPN或者IPsec VPN之后，明明客户端显示连接成功，却完全访问不到内网的OA服务器、文件共享服务器或者业务系统，反复重试连接也没法解决，直接找技术支持的时候如果只说“VPN连了上不了内网”，运维人员很难快速定位问题，提前整理好对应的排障信息，能把故障排查的效率提升数倍，也能避免来回反复核对信息浪费双方时间。
第一类：VPN连接基础状态的验证信息
首先你需要先确认自己当前VPN客户端的连接状态截图，不要只拍桌面右下角的小图标，要把客户端完整的连接详情页拍下来，里面要包含分配给你的VPN内网虚拟IP地址、当前的连接时长、使用的加密协议类型这些信息，很多用户容易忽略的点是，给梨加速器部分VPN客户端显示的“连接成功”其实只是和公网的VPN网关建立了隧道，但是内网地址分配失败，这种情况本身就属于网关侧的地址池资源耗尽故障，你把截图发过去，技术支持第一时间就能排除地址分配环节的问题。
接下来你要提供自己本地设备的公网出口网络属性，比如你当前是用家里的家用宽带接入，还是公司旁边的咖啡馆公共WiFi，还是手机热点共享的网络，有没有同时开启其他代理工具、其他VPN客户端，很多时候用户同时开了两个不同厂商的VPN客户端，路由表出现冲突，就会出现内网访问完全失效的情况，这类信息不需要做复杂测试，只要如实描述当前的上网环境就可以。
远程办公用户收集VPN故障相关的排障验证信息
第二类：本地路由与连通性测试的结果信息
你可以在Windows系统的命令提示符里输入route print命令，在macOS或者Linux系统里输入netstat -rn命令，把执行之后输出的路由表内容完整截图或者导出文本发给技术支持，重点要确认的是，内网目标网段的路由条目是不是指向了VPN生成的虚拟网卡，而不是你本地的物理网卡，很多用户本地本身就配置了静态路由指向旧的内网网关，VPN接入之后路由优先级没有覆盖，就会出现访问内网的数据包根本没有走VPN隧道的问题。
接下来你要做两次最基础的ping测试，第一次是ping你从VPN客户端拿到的虚拟网关地址，第二次是ping你平时访问的内网业务系统的服务器IP，不要直接ping域名，先测试IP层面的连通性，把两次ping测试的完整输出结果截图，哪怕是全部请求超时也要完整发过去，不要只说ping不通，技术支持可以从返回的超时提示类型判断是隧道传输丢包，还是根本没有匹配到正确的路由。
如果ping测试完全没有响应，你还可以做一次tracert路由跟踪测试，跟踪的目标地址选内网里你最常访问的业务服务器IP，把跟踪的每一跳结果都完整记录下来，如果第一跳就直接出了本地的公网网关，就说明内网网段的路由根本没有导入VPN隧道里，这类问题大概率是VPN网关侧的路由配置漏加了对应网段的推送规则，运维人员可以直接去后台检查配置。
第三类：边界场景的特殊补充信息
你还要说明VPN连接后内网不可达的具体表现，是所有内网IP都完全访问不了，还是只有特定的几个业务系统打不开，公网的网站在VPN连接之后能不能正常访问，部分企业的VPN配置了全隧道模式，所有流量都要走内网网关转发，如果内网的公网出口故障，就会出现连公网也打不开的情况，和半隧道模式下只有内网访问失效的故障原因完全不同，把这个细节说清楚，能直接缩小故障的排查范围。
如果你之前在同一个网络环境下用同一台设备连接VPN访问内网是正常的，最近一次出现故障之前你有没有修改过本地的网络配置，比如有没有手动改过虚拟网卡的IP地址、有没有安装过新的安全类软件、有没有升级过操作系统版本，很多终端安全软件会默认拦截陌生虚拟网卡的转发流量，升级系统之后也可能重置VPN客户端的驱动权限，这类用户侧的变更信息，往往是很多隐蔽故障的核心诱因。
如果你身边有其他同事在同一个时间段也出现了同类故障，也要把这些同事的接入网络环境、使用的设备类型一起汇总给技术支持，如果是多用户集中出现同类故障，大概率是VPN网关侧的配置变更或者带宽资源耗尽导致的，加速器不需要逐台排查终端配置，运维人员可以直接从网关侧入手定位问题。
很多用户提交故障信息的时候习惯只截浏览器打不开网页的报错图，这类信息几乎没有任何排障价值，你按照上面的维度整理好所有信息之后，技术支持不需要反复和你核对细节，就能在最短时间内定位故障根因，也能避免你自己做很多无效的重试操作，大幅缩短故障的整体修复时长。
