很多职场用户在远程办公时都会遇到VPN连接后内网不可达的问题，拨完隧道之后既打不开公司的共享文件服务器，也没法访问内网部署的业务系统，联系技术支持时如果只笼统描述“连不上内网”，往往要来回沟通好几轮才能定位故障。提前整理好对应的关键信息一次性提交，能大幅缩短排障周期，避免不必要的时间消耗。
用户整理VPN连接后的网络状态关键信息，提交给技术支持以缩短内网不可达故障的排障周期
VPN连接本身的基础状态信息
首先不要跳过VPN客户端本身的状态反馈，你需要先说明当前使用的VPN接入方式，是Windows/macOS系统自带的原生VPN客户端、还是公司统一配发的专用VPN客户端，连接成功之后客户端界面有没有弹出隐藏的报错提示，VPN加速器比如部分客户端会在后台提示“隧道路由分配异常”这类不显眼的提示，很多用户不会特意留意。
接下来要把VPN虚拟网卡拿到的核心参数同步给技术支持，你可以在系统的网络状态页、或者VPN客户端的详情页里，找到虚拟网卡获取的IP地址、水母子网掩码、分配到的内网DNS服务器地址，这些信息是技术支持判断隧道侧地址池是否正常分配的核心依据，不少内网不可达的根源就是虚拟网卡没拿到合法的内网段地址，用户自己很难第一时间发现。
故障场景的前置网络环境信息
你需要说明发起VPN连接的当前出口网络属性，比如是家里的家用宽带WiFi、还是手机分享的移动热点、还是出差入住的酒店公共网络、或是其他合作单位的办公内网，不同出口网络的NAT规则、防火墙限制差异很大，不少公共网络会默认拦截IPsec或者OpenVPN的专用隧道协议，这类信息能帮技术支持快速判断故障出在运营商侧还是企业内网侧。
同时还要补充连接VPN之前的本地网络状态，比如没启动VPN的时候你能不能正常访问公网，本地有没有同时运行其他代理工具、其他闲置的VPN客户端，或是装过生成虚拟网卡的虚拟机软件，很多用户本地存在多个虚拟网卡时，系统路由表会出现冲突，就算VPN隧道正常建立，访问内网的流量也会被引导到错误的网卡上，这类本地环境信息是远程排障最容易被遗漏的关键点。
内网不可达的具体验证测试结果
不要笼统描述所有内网资源都无法访问，要把实际测试的场景细节列清楚，比如你尝试访问的内网资源具体IP或者域名是什么，是内网的OA系统地址、还是运维用的服务器SSH地址、还是共享盘的网络路径，测试的时候是直接用IP访问失败、还是用域名访问失败，这两类故障的根因完全不同，前者大概率是隧道路由配置缺失，后者可能是VPN分配的DNS规则没有在本地生效。
你还需要把本地执行的基础网络探测结果完整同步，比如在命令行里执行ping内网网关的返回结果，水母是请求超时还是直接提示目的主机不可达，再执行tracert路由探测命令，看探测包在哪一个节点开始完全丢包，这些路径测试的结果能帮技术支持快速定位故障点，判断问题出在隧道传输段、内网网关转发段还是目标服务器的访问拦截规则上。
同类场景的对照参考信息
你可以补充之前的正常使用对照状态，比如之前有没有在同一台设备上成功连接过这个VPN访问内网，最近有没有做过可能影响网络的操作，比如更新了操作系统大版本、升级了VPN客户端、或是新安装了第三方安全类软件，不少故障都是用户本地的配置变更触发的，对照之前的正常状态能大幅缩小排查范围。
最后可以补充同场景其他用户的故障情况，比如身边其他同事用同样的运营商网络、连接同一个VPN服务，是不是也出现了内网不可达的问题，如果是批量用户出现同类故障，大概率是企业总部VPN网关的配置更新出了问题，如果只有单个用户出现异常，基本可以定位是用户本地的网络配置冲突。
整理这些信息的过程本身也是一次自主排查的过程，不少用户梳理测试细节的时候，自己就能发现是输错了内网资源地址、或是本地忘记关闭闲置代理这类小问题，就算没法自行解决，把完整信息提交给技术支持之后，水母也不需要运维人员一步步引导做重复测试，能把原本多轮沟通的排障流程压缩到单次反馈就定位根因，大幅提升故障处理的整体效率。
