分离隧道与企业策略：哪条规则说了算

在分离隧道客户端里勾选一个应用感觉像是本地偏好，而在受管设备上，这更接近一次策略变更。例外把流量移出获批路径，而这条路径可能正是承载受管 DNS、过滤以及服务所识别的源地址的那条。客户端撤回你的修改并不是行为错误；部署只是在做它该做的事。

在争论那个复选框之前，先弄清策略到底在保护哪一项属性。

规则背后的属性

有些部署把所有流量都路由到获批网关。另一些在意名称解析，把查询留在企业解析器而不是本地网络。还有一些需要稳定的源地址，好让内部服务决定是否响应。

第四类部署强制终端状态：磁盘加密、补丁级别、代理健康。分离隧道并不改变这些，而绕过代理自身流量的旁路却可能改变它们。

这是四项不同的要求，每一项会被不同的例外破坏。提出变更前先读要求，因为写要求的人能立刻告诉你哪一项适用。满足错的那一项，什么也换不来。

有两个说法值得早早放弃。全隧道并不会把每个明文页面交给管理员，因为可见性由应用加密和终端控制决定。分离隧道也并非普遍不安全，因为受管 DNS、按应用策略和终端代理可以不受路径影响而继续生效。

按顺序执行检查

下面的顺序把例外缩小到真正失败的最小范围。在第一项不成立的检查处停下，因为后来的修补无法弥补先前的缺口。

问清现在哪些流量不再走获批网关，然后确认名称解析仍能到达企业解析器。检查相关应用是否遵守终止开关，还是把失败的那次尝试花在了直连路径上。再看共享服务：文档查看器或更新代理会把例外带得比复选框暗示的更远。最后记下重连时策略是否会重新施加，因为这个行为决定了任何本地改动能否存活。

每个答案都是事实，而例外申请需要的正是事实。VPN 烦不烦的争论不属于其中之一。在谈话开始前把答案写下来。

申请一个范围狭窄的例外

按这个顺序报告应用、目的地和失败的操作。让一个更新器留在直连路径上的请求可以审查；让整个浏览器绕开隧道的请求则不行。

描述你已尝试过什么、日志显示了什么，并把它发给拥有该配置文件的团队，而不是服务台里接电话的人。在受管设备上，配置文件所有者通常能创建一个在更新后仍然存续的受支持例外，而本地路由修改做不到。

如果答复是拒绝，把它当作设计决定，而不是需要绕过的障碍。下一次评审才是重新提出它的地方，并附上失败操作的记录和业务理由。绕过去所冒的风险，超过这个例外本身的价值。

让例外能够存续

批准变更之后，确认此前正常的部分，而不只是被修好的那部分。内部名称仍应通过企业解析器解析，私有资源仍应应答，先前失败的任务现在应当完成。

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

第一条命令证明解析器仍能应答内部后缀，第二条证明请求能从当前路径到达内部服务。重连后再跑一次，因为策略推送可能悄悄撤销测试中看起来稳定的改动。与工单一起保存两行输出，才算闭环。没有它们，这个例外就只靠某人对某个页面曾加载过一次的记忆。

把例外、它的用途以及涵盖的组件记在与部署说明相同的地方。没有记录的例外会变成下个季度的事故，而被记录下来的例外会成为设计能承受真实工作负载的证据。