保留私有路由、去掉重定向：OpenVPN 分离隧道

隧道起来了，应用也加载了，然后笔记本上其他一切开始变得古怪。这就是只删一行来实现“仅私有”策略的常见结果。移除一条被推送的默认路由确实改变了流量去向，却没有说明流量应该改去哪里，而且完全没有涉及名称解析。策略需要两个正向的部分才能被检验。

删掉重定向只是改动的一半

全隧道重定向与仅私有策略的差别，在于它们对世界的主张不同。重定向主张覆盖每一个目的地，而私有策略只主张一份清单，其余保持原样。只删掉主张而不写清单，会得到一个在局域网之外什么都到不了的客户端，看起来像路由故障而不是策略缺口。先把清单写好再移除主张，这两步的先后就不再重要。

两个部分都是要求，而不是默认值。私有前缀必须进入隧道，普通目的地必须保持连接前的路径。

如果组织强制要求全隧道，那么这里的一切都不适用。仅私有设计属于已批准分离路由的部署场景。

pull-filter 是匹配，不是开关

pull-filter 指令移除名称匹配某个前缀的被推送选项，它能做的仅此而已。忽略重定向会让其他被推送选项原样保留，这通常正是你想要的：路由、DNS 设置和路由网关值仍然会下发。它也无法移除写在本地配置文件里的指令，因为过滤只作用于服务器推送的内容。

要抵住忽略所有以 route 开头选项的诱惑。那种写法也会丢掉连接所需的私有路由，还可能丢掉隧道赖以工作的网关信息。

route-nopull 是比看起来更宽的决定。它整体阻止客户端接受被推送的路由和 DHCP 风格选项，这与只过滤掉某一项是不同层面的策略。

从应用向外写路由清单

从用户真正会打开的东西出发，再补上支撑的部分。位于 10.60.20.15 的应用意味着它的子网 10.60.0.0/16，而一个私有名称意味着应答它的解析器。因此，只提出一个应用需求的用户，实际需要两个目的地和一个 DNS 决定。清单之外的一切在结构上都在范围之外，这正是策略可复核的原因。

在配合的服务器上，这些都变成两条被推送的路由，而它们都不是重定向。保留现有服务提供的隧道拓扑和路由网关值。

当只有部分用户需要这项策略时，按客户端或按组应用。为了满足一个团队的需求而改动所有人的路由，正是让分离隧道变成中断的方式。

让 DNS 走同一条路径

通往解析器的路由不是解析器策略。在 systemd-resolved 客户端上，语义结果是私有命名空间的一个路由域指向内部解析器，这正是只有那些名字才会使用它的原因。Windows 客户端则需要它自己的命名空间策略机制。配置文件里的 DNS 服务器行本身并不会安装这两者中的任何一个。

要看操作系统选了什么，而不是配置文件要求了什么。在 Linux 上，resolvectl status 会显示每条链路的域和服务器；在 Windows 上，命名空间策略表就是等价证据。

要让解析器经隧道可达，否则策略指向的是一个无法查询的地址。隧道到不了的解析器地址，会把可用的策略变成超时。

重连时验证两个部分

改动后重新连接客户端，检查通往私有地址和公共地址的实际路由。然后解析一个私有名称和一个公共名称，确认各自使用了预期的解析器。公共网站能打开只能证明后半部分，而这后半部分通常是碰巧生效的。

用一句话记录完成的策略：这些前缀和名称走这条连接，其余一律走本地路径。然后把它留在配置文件里，而不是每次登录后去修适配器设置。