很多企业远程办公场景下，用户成功拨号VPN客户端后，明明显示连接状态正常，却无法访问内网的文件服务器、OA系统或者业务数据库，这类问题除了用户本地设备的配置问题，很大一部分根源出在网络端的配置疏漏上，本教程就聚焦VPN连接后内网不可达：网络端排查的全流程步骤，帮运维人员快速定位故障点，避免无意义的逐台用户设备调试。
VPN虚拟接口段路由发布校验
首先要确认VPN服务端分配给远程用户的虚拟IP地址段，有没有正确发布到内网核心路由的路由表中，很多新手部署IPsec或者SSL VPN的时候，只在服务端配置了地址池，忘了在内网核心交换机上添加指向VPN虚拟网段的静态路由，导致内网服务器回包的时候找不到返回VPN用户的路径，自然就出现单向不通的情况。
排查的时候可以先登录内网核心设备，查看路由表中是否存在对应VPN地址池的条目，下一跳必须指向VPN服务端的内网物理接口地址，而不是其他内网网关，如果发现路由条目缺失或者下一跳配置错误，直接修正之后再测试连通性即可。部分动态路由组网的环境下，还要确认VPN虚拟网段已经被加入动态路由协议的发布清单中，不会被核心设备的路由过滤规则拦截。
内网访问控制策略的放行校验
很多企业内网部署了防火墙、准入控制系统，不同安全域之间默认是拒绝所有陌生网段访问的，VPN虚拟网段默认属于远程接入域，很多管理员配置安全策略的时候，只放行了VPN用户访问内网资源的单向流量，忘了放行内网资源回包的反向流量，或者直接把VPN地址池加到了内网黑名单里。
运维人员登录内网核心设备校验VPN虚拟网段的路由发布配置
这里要注意排查的时候不要只看VPN服务端本身的策略，加速器还要逐台检查VPN服务端和内网业务服务器之间所有串接的安全设备的访问控制规则，确认VPN虚拟网段的源地址，能够正常访问内网业务网段的目标端口，没有被中间的ACL规则拦截。很多运维人员习惯只在VPN出口设备检查策略，忽略了内网业务区前端部署的专属防火墙规则，这类疏漏往往会耗费大量排查时间。
还有一个常见误区是，很多企业内网配置了基于IP地址段的VLAN权限隔离，VPN分配的虚拟网段没有被加入到允许访问业务VLAN的白名单里，哪怕路由全通，二层或者三层的VLAN隔离规则也会直接丢弃数据包，这类问题很容易被忽略，排查的时候要同步核对VLAN的访问控制配置。
VPN服务端的内网推送配置校验
很多时候VPN连接后内网不可达，加速器是因为服务端给客户端推送的路由配置出现了错误，部分管理员为了实现用户所有流量都走VPN隧道，错误配置了全流量隧道的推送规则，却没有在内网出口做好NAT适配，导致VPN用户的流量进入内网之后，源IP地址没有被正确转换，内网设备收到陌生源地址的数据包直接丢弃。
还有一种常见的配置疏漏是，VPN服务端没有给远程客户端推送正确的内网DNS服务器地址，用户访问内网域名的时候，请求被发去了公网DNS服务器，自然解析不到内网服务器的IP地址，表现出来的现象就是内网域名打不开，直接用内网IP访问却正常，这种情况要先确认VPN客户端拿到的DNS地址是否和内网办公场景下的DNS地址一致，必要的时候可以在客户端上手动添加内网静态路由做临时验证。
跨三层网络的MTU值适配排查
VPN隧道本身会对原始数据包进行加密封装，额外增加报文头的长度，如果内网链路的MTU值配置过小，超过封装后报文的最大传输单元，就会出现大体积数据包被分片丢弃的情况，表现出来的现象就是小流量的ping测试能通，但是访问内网大文件、加载业务系统的大资源页面的时候直接卡住断开。
排查这个环节的时候，可以在VPN服务端上调整隧道接口的MTU值，适配内网链路的最小MTU参数，同时开启TCP MSS钳制功能，避免TCP协商的报文分段大小超过链路承载上限，调整完成之后再测试内网业务的全场景访问，确认不会出现随机丢包的情况。部分跨运营商专线部署的异地VPN场景下，中间传输链路的MTU值也可能存在不一致的情况，需要逐段核对链路参数。
需要注意的是，单次网络端排查的结果只能覆盖当前定位到的故障点，旋风vpn不能完全排除用户本地设备的防火墙、本地路由配置异常带来的同类问题，如果网络端所有配置校验完成之后故障依然存在，再转向用户侧的本地环境做进一步排查即可。整个网络端排查流程不需要改动用户本地的任何配置，运维人员可以在机房侧快速完成全量校验，大幅提升远程接入故障的处理效率。
