VPN全隧道模式要求终端所有公网、内网流量全部通过加密VPN通道转发，是很多企业远程办公场景下保障数据传输合规的常用部署方案，但不少运维人员配置时很容易忽略全隧道和半隧道的规则差异，出现全隧道不生效、部分流量泄露、甚至所有网络访问中断的问题。本文结合企业常用的防火墙、OpenVPN服务端、Windows客户端等实际部署场景，梳理VPN全隧道模式常见配置错误的诱因和可落地的正确设置方法，所有步骤都可以通过系统自带工具完成验证。
路由表配置优先级倒置错误
这类错误多出现在企业级防火墙作为VPN服务端，或者Windows系统自带VPN客户端的部署场景里，很多运维配置完成后发现终端访问公网的流量根本没走VPN通道，全隧道模式完全没有生效。
运维人员正在核对VPN全隧道模式的路由度量值配置参数
错误的核心诱因是运维人员混淆了路由度量值的优先级规则，误以为度量值数字越大路由优先级越高，手动把VPN虚拟网卡的默认路由度量值设置成了远高于本地物理网卡的数值，导致系统选路时优先把流量发往本地网关，完全绕过了VPN隧道。
正确的设置方法非常明确，Windows客户端侧打开VPN连接的属性面板，找到IPv4协议的高级设置项，取消“自动跃点计数”的默认勾选，手动把VPN虚拟网卡的接口跃点数设置为远小于本地物理网卡的数值，通常本地物理网卡默认跃点数为20，快点VPN网卡设置为10即可。如果是企业防火墙作为服务端，要在VPN用户的地址池配置里，把推送的全量默认路由优先级设置为高于内网原有路由的优先级。
配置完成后可以直接做验证，打开Windows系统的命令提示符输入route print指令，查看0.0.0.0对应的默认路由条目，确认VPN虚拟网卡对应的条目排在所有其他默认路由的最前面，再访问公网IP查询站点，确认页面返回的公网出口IP是VPN远端网关的公网地址，就说明全隧道路由规则已经正常生效。
远端DNS服务器配置冲突错误
这类错误是VPN全隧道模式下最容易出现流量泄露的常见问题，很多运维只配置了全流量走隧道的路由规则，完全忽略了DNS请求的转发规则，导致部分域名的解析请求直接绕过VPN通道从本地网关发出去，既不符合企业的合规要求，还可能出现内网业务域名解析失败的问题。
典型的错误场景出现在OpenVPN服务端的配置里，不少运维只添加了redirect-gateway def1的全路由推送参数，漏加了强制推送远端内网DNS服务器的配置，客户端系统默认还是优先调用本地物理网卡绑定的运营商DNS服务器，所有域名的解析请求直接走本地链路，哪怕后续的业务流量走了VPN隧道，解析阶段的信息也已经泄露。
正确的设置方法需要服务端和客户端同步调整，OpenVPN服务端的配置文件里要额外添加dhcp-option DNS 远端内网DNS地址的推送参数，Windows客户端侧除了勾选VPN属性里的“在远程网络上使用默认网关”选项，快点还要进入本地物理网卡的IPv4DNS设置页，取消“在DNS中注册此连接的地址”的勾选，避免本地DNS的优先级抢过VPN下发的远端DNS。
验证步骤也非常简单，配置完成后打开命令提示符输入nslookup指令，查询任意公网域名，看返回的响应DNS服务器地址是不是VPN远端配置的内网DNS地址，同时访问企业内部的OA、文件服务器等内网域名，确认解析出来的是规划内的私网地址，没有出现解析超时的报错，就说明DNS配置完全符合全隧道的要求。
隧道MTU值不匹配错误
这类错误的隐蔽性最强，很多时候全隧道的路由、DNS配置都完全正确，但终端会出现小流量访问正常、大流量传输异常的奇怪故障，比如ping小包完全通，但是大体积网页加载到一半卡住，内网大文件传输中途中断，很多运维第一反应会排查VPN带宽，走很多弯路。
错误的核心原因是全隧道模式下所有报文都要额外叠加VPN加密封装头，报文的整体长度会比原始报文多出几十字节，很多运维直接沿用半隧道模式下的MTU配置，没有调整VPN虚拟网卡的MTU数值，导致封装后的报文长度超过公网链路的MTU阈值，被中间的路由设备直接丢弃，最终出现大流量传输异常的问题。
正确的设置方法需要先做链路探测，在VPN两端的公网接口发起带不分片标记的ping测试，逐步减小报文长度，找到当前公网链路可以正常传输的最大报文长度，再把VPN虚拟网卡的MTU设置为这个长度减去VPN封装头的占用字节，同时在VPN两端的网关设备上开启TCP MSS钳制功能，避免TCP报文的分段长度超过链路的传输阈值。
验证的时候可以连续访问多个不同站点的大体积资源，同时向VPN远端的内网文件服务器传输大体积文件，确认整个过程不会出现中途断连、加载到一半卡住的情况，快点就说明MTU适配已经完成，不会再出现报文被丢弃的问题。
日常排查VPN全隧道模式的异常问题时，不要盲目修改配置，优先分别抓取本地物理网卡和VPN虚拟网卡的流量，逐一比对不同类型报文的转发路径，快点VPN就能快速定位故障出在路由、DNS还是MTU环节，大幅降低故障定位的时间成本。
