两个 VPN，一个解析器：谁最后写入谁赢

两个 VPN 客户端同时连接。一个用于工作，一个用于实验室网络，内部名称却只为最后连接的那个客户端解析。这个现象看起来像其中一个客户端的缺陷，实际上通常是两个程序在没有任何约定下写入同一份解析器配置的可预测结果，谁拥有哪个名称并没有说清。

神话：最新的 VPN 拥有 DNS

并不存在“最新的连接获胜”这种通用规则。实际发生什么取决于平台机制，也取决于每个客户端怎么写。替换解析器文件的客户端产生一种结果，按连接添加域名的客户端产生另一种结果，什么都不做的客户端则保留原有状态。

所以观察到的行为是两种实现的性质，而不是有文档的优先级。只从启动顺序推断，有时对，有时会以难以复现的方式出错。不如把映射写下来。存在于两个客户端里的设计并不是设计。

把命名空间映射到解析器

列出私有后缀以及每个网络需要的解析器，然后决定公共名称该去哪里。这份清单就是设计。没有它，客户端只是在碰运气做决定。

支持按连接设置 DNS 或路由域的平台可以把这种拆分明确表达出来：一个域走一条连接，另一个域走另一条，其余全部遵循显式的默认值。两个各自覆盖同一文件的扁平脚本无法保住这份设计，因为每个都认为自己拥有整份配置。

在 Windows 上，名称解析策略表可以把后缀指向特定服务器，VPN 客户端也可能在那里安装规则。要检查策略而不是适配器列表，因为解析名称的不是适配器列表。

保留一条引导路径

每个客户端都必须先找到自己的端点，才能使用该端点提供的服务。如果端点主机名只能通过隧道解析，而隧道又需要解析好的主机名，就形成了一个表现为连接超时的循环依赖。在两个隧道之外保留一条引导路径。在它救回连接的那天之前，它不花任何代价。

要看通往每个解析器的路径，而不只是为它配置的名称。只能通过另一条隧道到达的解析器，其表现等同于缺失，症状是超时而不是路由错误。

地址重叠不是 DNS 问题

两个使用同一地址段的私有网络无法靠 DNS 顺序修好。如果两条隧道都要求 10.0.0.0/8，即使名称正确解析，仍会指向主机无法路由到正确隧道的地址。这需要地址层面的方案，比如不同的地址段、命名空间或转换，而不是再加一条解析器设置。早点决定这一点，可以避免在永远不会生效的 DNS 配置上绕很远的路。

在归咎于名称解析之前，先比较两条隧道的地址分配。当两端推送同一个前缀时，主机只会为它保留一条路由，通过第二条隧道解析出的名称仍然落到第一条隧道拥有的地址上。不同的地址段、按网络划分命名空间或转换才是修正办法；每个客户端连接之后，确认路由表显示的是你预期的路径。

用真实应用来验证

选两个只存在于各自命名空间中的主机，再加一个公共名称，然后分别通过应当拥有它的客户端去解析。期望的解析器给出正确答案，并不能证明应用能到达该主机，因为通往那个地址的路由仍可能失败。每次查询之后，都用用户真正会运行的程序做一次连接测试。

带有自己加密 DNS 选项的客户端可以绕过你刚刚验证过的策略，所以要把这一设置纳入检查。然后按厂商支持的顺序重新连接两个客户端并重复查询；如果顺序一变答案就互换，说明仍有竞争写入者拥有一部分配置。在改动任何东西之前，先弄清是哪个组件安装这条规则——客户端、操作系统配置文件还是管理代理。记录顺序和所有者，让下一个人不必重新发现。