VPN全隧道模式会将用户设备所有出站流量全部转发到VPN远端网关处理，相比分流模式能覆盖全部业务访问需求，很多企业运维人员和个人用户配置时容易忽略细节导致连接异常、本地网络不可用甚至隐私边界错位，本文从实际故障排查场景出发，盘点高频出现的配置错误，给出可落地的逐项检查方案，帮使用者快速定位问题。
全隧道路由优先级配置错误
很多用户配置VPN全隧道模式时，没有调整系统路由表的优先级规则，忽略了本地直连路由和VPN下发路由的权重差异，就会出现访问本地局域网打印机、内网NAS设备完全不通的现象，这也是新手配置全隧道模式最常踩的坑。
排查的时候可以先断开VPN连接，确认本地局域网的互访功能完全正常，排除本地链路本身的故障，之后连接VPN后在终端执行路由表查看命令，检查本地直连网段的路由条目是否被VPN下发的0.0.0.0全量路由覆盖。
正确的配置逻辑是在VPN网关端添加本地直连网段的排除路由，让这部分流量不进入隧道转发，既保留全隧道模式对公网流量的全覆盖，也不会打断本地局域网的正常访问，很多使用者误以为全隧道就是所有流量必须走隧道，把本地网段也强制加入转发路径，反而制造不必要的访问故障。
运维人员正在逐项检查VPN全隧道模式的路由优先级配置规则
远端DNS转发配置疏漏引发泄漏
VPN全隧道模式下所有DNS请求理论上都应该转发到VPN远端指定的DNS服务器处理，不少配置者没有清空本地系统的原有DNS服务器列表，小火箭加速器也没有开启客户端的强制DNS隧道转发规则，就会出现部分DNS请求绕过隧道直接向本地运营商DNS发起查询的问题。
这类故障的现象是部分公网业务访问走本地链路，部分走隧道，完全达不到全隧道的预期效果，还可能导致原本要通过隧道统一处理的访问记录被本地链路侧的设备捕获，破坏预设的隐私边界，违背全隧道模式的部署初衷。
检查的时候可以在连接VPN后，访问公开的DNS泄漏检测站点，确认所有返回的DNS服务器地址都属于VPN远端配置的地址段，如果出现本地运营商的DNS地址，就说明配置存在疏漏，小火箭加速器需要在VPN客户端配置里开启强制全DNS隧道转发选项，同时清空系统网卡的备用DNS配置，避免本地DNS条目优先级过高抢占转发路径。
隧道MTU值不匹配引发的隐性断连
VPN全隧道模式会在原有IP报文之外额外封装一层VPN协议头，相当于报文的整体体积变大，如果两端的MTU值没有对应调整，就会出现大尺寸报文被中途网络节点丢弃的问题，shadowrocket小流量的网页访问看起来正常，大文件传输、实时交互业务就会频繁卡顿甚至断连。
这类问题排查起来很容易被误认为是公网链路不稳定，很多运维人员排查半天公网带宽和链路连通性都找不到原因，实际上就是全隧道模式下没有把两端的MTU值设置得比本地公网的MTU更小，留出封装协议头的冗余空间。
验证的时候可以在连接VPN后，向远端网关发起不分片的大报文ping测试，如果出现报文无法送达的情况，就说明MTU配置不匹配，逐步下调隧道接口的MTU数值直到大报文可以正常传输，就能解决这类隐性故障，不需要额外调整公网链路的配置。
多网卡环境下的全隧道流量逃逸
很多终端同时接了有线网卡、无线网卡甚至随身WiFi多个网络接口，配置VPN全隧道模式的时候如果没有绑定正确的物理出站接口，也没有设置流量强制隧道转发规则，就会出现部分应用的流量直接从其他未被VPN接管的网卡流出，完全脱离隧道保护。
这类故障的隐蔽性极强，用户看起来VPN已经正常连接，以为所有流量都走了全隧道，实际上部分敏感业务的流量直接暴露在公网，完全不符合预设的安全规则，这类配置错误在企业办公终端的全隧道部署场景中出现频率很高。
排查的时候可以在连接VPN后，shadowrocket逐个禁用多余的物理网卡，观察流量逃逸的现象是否消失，之后在VPN网关的配置规则里添加流量强制绑定隧道接口的策略，禁止流量从非隧道的其他接口直接转发，就能彻底规避这类配置漏洞，保证全隧道模式的流量覆盖完整性。
