很多用户在完成VPN客户端拨号、显示连接成功之后，发现既没法访问内网的文件服务器、业务系统，甚至连同内网段的其他设备都ping不通，第一反应往往是VPN服务器出了问题，但实际上绝大多数这类故障的第一排查点根本不在远端服务，而是本地系统的路由表配置，这也是VPN连接后内网不可达第一步优先要确认的网络设置，很多用户跳过这一步直接排查远端配置，反而会浪费大量排查时间。
VPN连接后内网无法访问时，优先检查本地路由表配置可大幅缩减故障排查时间
为什么路由表是第一优先级的检查项
很多人会误以为VPN连接成功就会自动把内网网段的路由规则推送到本地，但实际上不同类型的VPN协议、不同客户端的默认配置，都有可能出现路由推送失败的情况，系统本身的原有路由规则优先级如果高于VPN下发的规则，就会导致访问内网的流量根本没有走VPN隧道，自然无法连通。
不少用户同时开着多个虚拟网卡，比如虚拟机的虚拟网卡、WSL的虚拟网卡，梯子软件这些设备生成的路由条目经常会和VPN下发的内网路由产生冲突，这种冲突不会直接导致VPN连接失败，只会表现为内网不可达，从现象上很容易误导用户去检查VPN账号权限、远端防火墙这些更靠后的环节，这也是VPN连接后内网不可达：第一步检查什么这个问题的核心答案来源，路由表故障的发生概率远高于其他远端故障。
本地路由表的具体检查操作方法
Windows系统用户可以按下Win+R输入cmd打开命令提示符，扬帆云机场执行route print命令，找到活动路由条目里对应你公司内网网段的条目，比如内网是192.168.1.0/24段，就要看这个条目的下一跳地址是不是指向VPN虚拟网卡的网关地址。
macOS或者Linux系统的用户可以打开终端执行netstat -rn或者ip route show命令，同样查找目标内网网段对应的出口网卡，确认是不是你刚拨号成功生成的VPN虚拟网卡，而不是你本地正在用的WiFi或者有线物理网卡。
这里要注意区分默认路由和细分路由的区别，如果VPN配置了全流量隧道，那默认路由的下一跳应该指向VPN网卡，但如果是分流隧道，只有内网网段的路由指向VPN网卡，其他公网流量还是走本地原有网关，很多用户搞混这两种模式的判断标准，会误把正常的路由配置当成故障。
路由表检查的常见误区和对应修正方案
很多用户发现内网网段的路由条目不存在的时候，第一反应是重装VPN客户端，扬帆云机场实际上完全可以手动添加静态路由临时验证，比如在Windows下执行对应路由添加命令，把内网段地址、子网掩码和VPN网卡网关地址绑定，添加之后立刻测试内网连通性，如果能正常访问，就说明故障根源就是路由推送失败。
还有一类常见的误区是用户本地的物理网卡网段和VPN要访问的内网网段完全重合，比如用户家里的路由器默认网段和公司内网是同一个网段，这种情况下即使VPN推送了正确路由，系统也会优先走本地物理网卡的路由，这种冲突不属于VPN本身的配置故障，需要修改本地路由器的LAN口网段来规避。
完成第一步检查后的后续排查边界
如果确认本地路由表的所有条目都完全符合预期，内网流量确实是走VPN虚拟网卡转发的情况下，内网依然不可达，这时候才能进入下一个排查环节，检查VPN客户端获取到的内网IP地址是否和内网网段匹配，有没有出现地址分配错误的情况。
要注意的是，第一步的路由表检查只能覆盖本地配置层面的大概率故障，不能排除远端VPN服务器的防火墙规则拦截、内网交换机的访问限制这类远端问题，但先完成这一步检查，能排除绝大多数常见内网不可达故障，避免无意义的远端配置调试。
