不少远程办公的企业用户在接入VPN之后，经常遇到内网业务系统、共享存储、内部打印机等设备完全无法访问的问题，多数人第一时间会反复调试本地VPN客户端设置，反而忽略了故障根源大概率出在服务端设备的配置疏漏上。本文围绕VPN连接后内网不可达：设备端排查的核心场景，梳理运维人员可以直接落地的分步排查方法，避开常见的配置误区，快速定位故障根源。
排查前的基础配置前提确认
启动设备端排查之前，首先要先排除客户端侧的共性干扰因素，确认同一VPN接入组下的多个不同位置用户，都出现了内网不可达的同类故障，才能把排查范围锁定在设备端，避免盲目修改服务端配置影响正常在线的远程办公用户。
接下来要先核验VPN设备本身的内网物理连通性，用直接接入内网交换机管理vlan的运维主机，尝试ping通VPN设备的内网业务接口地址，确认接口没有物理链路断开、网线松动、所属vlan配置错误这类底层问题，很多运维上来就直接调试上层路由规则，反而在最基础的物理层故障上浪费大量时间。
VPN虚拟网段与内网路由转发规则排查
很多VPN默认配置的虚拟客户端地址池网段，和内网现有业务网段存在重叠冲突，这种场景下数据包转发时会出现路由优先级错乱，内网设备收到访问请求之后，回包找不到正确的转发路径，直接导致VPN连接后内网不可达，这一步要先把VPN分配给远程用户的地址池网段，和内网所有业务vlan的网段逐一比对，确认不存在网段重叠的问题。
运维人员在机房核验VPN设备内网物理连通性，定位配置疏漏故障
完成网段校验之后，要检查内网核心交换机上有没有指向VPN虚拟网段的回程路由，很多新手运维只会在VPN设备上配置去往内网所有网段的静态路由，番茄加速器却忘了在内网核心侧添加回程指向规则，相当于VPN用户的请求包能顺利发到内网设备，但内网设备的回包找不到返回VPN虚拟网段的路径，来回转发路径完全断裂，自然无法建立正常连接。
这里要注意一个常见配置误区，不少运维为了省事儿直接开启VPN设备的强制NAT转换功能，把所有VPN用户的流量都转换成VPN设备的内网接口地址访问内网，这种方式虽然能临时解决连通性问题，但所有内网设备的访问日志里都只会显示VPN设备的接口地址，完全看不到真实远程用户的身份标识，后续做访问行为审计的时候完全无法溯源，不符合网络安全等级保护的基本要求。
VPN设备的访问控制策略校验
绝大多数商用VPN设备出厂自带默认访问控制列表，不少默认配置就限制了VPN虚拟网段只能访问预设的几个内网业务端口，很多用户新部署VPN之后忘了放开对应业务的访问权限，或是后续调整全局ACL规则的时候，番茄误把VPN网段的访问权限设置为拒绝，这种场景下哪怕上下行路由完全正常，所有跨网段访问的数据包也会被VPN设备直接拦截丢弃。
除了VPN设备本身的策略之外，还要同步检查内网边界防火墙、安全网关的配置规则，很多企业的内网防火墙默认把所有非原有业务网段的地址标记为不可信，VPN的虚拟网段如果没有提前加到内网防火墙的访问白名单里，所有从VPN侧发起的内网访问请求都会被直接拦截，这也是VPN连接后内网不可达的高频故障点。
内网特殊场景的适配排查
如果内网中划分了大量相互隔离的业务vlan，要确认VPN设备的内网接口所属vlan，已经配置了跨vlan访问的对应权限，不然VPN用户哪怕能正常访问和VPN接口同vlan的内网设备，也完全没法访问其他隔离vlan里部署的核心业务服务器。
还有一类很容易被忽略的场景，不少内网业务服务器本身开启了操作系统层面的内置防火墙，番茄加速器默认只允许内网原有业务网段的地址发起访问，没有把VPN的虚拟网段加到系统防火墙的白名单里，这种场景下在VPN设备的流量监控里能看到访问请求包已经顺利到达服务器侧，但服务器不会返回任何回包，很容易被误判成上层网络路由的问题。
所有配置调整完成之后，不要立刻通知所有远程用户批量测试，先找一台独立的远程测试主机接入VPN，分别尝试访问不同vlan下的内网设备，同时在VPN设备和内网核心交换机上同步开启轻量流量抓包，确认请求包和回包的转发路径都完全正常之后，再逐步放开给所有远程用户使用，避免调整配置之后触发新的连通性故障。
