全隧道与拆分隧道：四个不同之处

隧道标签描述的是笔记本电脑其余流量去了哪里，而不是它跑得多快。在全隧道下，公网请求先经过 VPN 网关，再离开去往互联网。在拆分隧道下，私有目的地走隧道，其他一切都走本地路径。两者都能到达内部应用，所以人们最先做的可达性测试，并不能说明部署的是哪种策略。

换一种方式：测试出口，看公共回声页面报告哪个地址，以及是哪个解析器作答。

误区：拆分隧道只是更快的选项

拆分隧道常被当作性能特性来卖，它确实可能更快，但那只是副作用，而不是定义。定义是关于哪些目的地进入隧道的路由决策。只有直连路径确实优于绕行办公室时，速度差异才会出现。在拥塞的家庭链路和负载很轻的网关上，全隧道反而可能是两者中更快的。

所以诚实的框架讲的是路径的所有权与控制，而性能是事后测量的东西。为了速度而选择、却悄悄搬走你的 DNS 和公网出口的策略，选错了理由。

真正改变的是什么：出口

在全隧道下，公共网站看到的是办公室出口地址，办公室的过滤也能看到请求。在拆分隧道下，同一个网站看到的是用户家庭地址，办公室什么也看不到。这是两种不同的可见性模型，谁都不自动更安全。有用的问题是：组织真正能运营哪一种。

直接检查，而不是相信已连接的徽标。公共地址回声显示出口，解析器测试显示是谁的 DNS 作答。

那么网关要承载什么

承载视频通话、下载和私有应用的网关，需要的容量与只承载内部请求的网关完全不同。站点的互联网连接同时承载用户的进入和随后的公网出口，所以两条链路可能同时饱和。

本地突破去掉了那份负载和绕行，但它并不保证更好的体验，因为直连路径也可能拥塞。比较实际应用，而不是把路由标签当成性能测量。

全隧道下也存在例外

默认路由并不是每个数据包的清单。更具体的路由、本地网络允许、应用排除以及单独的 IPv6 规则都会移动流量，这就是为什么被描述为全隧道的策略仍然可能泄漏。操作系统的路由文档对强制隧道默认值作了这一区分，而客户端的例外列表通常就是泄漏所在。要验证行为，而不是意图。

IPv6 值得单独一看，因为只承载 IPv4 的隧道会把整个协议栈留在策略之外。

DNS 是独立的策略

内部名称需要认识它们的解析器，而那个解析器可能只能通过隧道访问。带有自己的加密 DNS 的浏览器可以完全绕过系统解析器，于是出现内部名称失败、公共名称可用的分裂，或者相反。

先决定查询应该去哪里，再让客户端和浏览器保持一致。成功的公网浏览从不测试内部名称解析，所以当内网站点消失时，它是错误的证据。

写下故障策略，然后测试它

决定隧道断开时会发生什么：全部阻断、只阻断私有资源，还是允许直连。自动重连并不回答这个问题，而只覆盖隧道接口的终止开关可能让被排除的应用照常通信。测试一次真实断开和一次网络变更，然后读取客户端的状态，因为文档描述的是预期行为，而不是已安装的行为。

把私有路由、公网出口、DNS 服务器、本地例外和故障行为记在一份简短笔记里。正是这份笔记，让没有写过它的人也能验证这套策略。