私有 DNS 名称还是只用 IP？分享前先决定

当私有服务向远程用户开放时，两个问题会被混为一谈。第一个是客户端应该使用哪个名称；第二个是服务应该接纳哪些来源。请按这个顺序回答，因为错误的访问规则后面的正确名称仍然会失败，而无法解析的名称后面的正确规则根本没有机会被检验。

条件一：客户端有哪条解析器路径？

私有名称只有在客户端的解析器能够回答它时才有效。这意味着，获授权的远程客户端必须到达持有该区域的 DNS 服务器，可以经由隧道，也可以经由组织已为远程用户运行的解析器。隧道是一种传输通道，不是目录。它给客户端提供通往解析器的路径，却不会告诉客户端该查询哪个区域。

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

公网解析器不会因为笔记本电脑连上了 VPN 就学会私有区域。

后缀同样值得注意。请使用组织所控制域名的子域，让所有权和证书规划保持明确。避免使用 .local：多播 DNS 规范 把该后缀绑定到链路本地解析，而经过路由的隧道不会替你复现这种行为。

条件二：服务收到哪个来源？

访问规则是按地址编写的，所以有用的问题是：经过路由和转换之后，服务看到的是哪个地址。对于位于 10.20.30.40 的示例服务，办公室客户端来自 10.20.30.0/24，远程客户端来自另一个地址池，例如 10.99.0.0/24。

如果网关对远程地址池做了转换，服务看到的就是转换器，为 10.99.0.0/24 编写的规则就不会匹配。

要从服务一侧而不是客户端一侧来读这件事。服务主机上的监听日志或数据包捕获会显示实际到达的来源；客户端自己的地址只是对沿途幸存下来之物的猜测。

条件三：名称绑定的是服务还是主机？

指向单台机器地址的名称会把每个客户端绑定到那台机器上。指向负载均衡器或稳定服务地址的名称，则能在其背后的主机被替换后继续存在。请有意识地选择，因为日后更改意味着要更改每个客户端的书签以及每张证书的主题。

对于单个内部服务，直接记录通常就够用，也更容易推理。

对于任何将被替换、重建或扩容的对象，稳定的前端值得多花这份配置。检验很简单：如果能在不告知用户的情况下替换后端，名称就绑定在服务上；如果做不到，就绑定在主机上。

分别检验这两个决定

先解析，再连接。返回预期地址的解析检验证明了名称路径，却对访问规则只字未提。连接检验同时证明路径和规则，因此只能在解析成功之后运行。

curl -sv --max-time 5 https://files.corp.example/health

然后测试一次被禁止的来源，并记录结果。

在文档中把两份记录分开保存：名称及其区域，被接纳的来源与规则负责人。当其中一项改变时，另一项不必随之改变。

决定通常在哪里出错

常见的失误是：服务发布在一个只在办公网络上才能解析的名称之下，而访问规则只接纳办公网段。于是远程用户报告服务损坏，实际上却是两处彼此独立的遗漏。第二种常见失误则相反：为了让名称问题消失而添加的宽泛访问规则，会让服务可以从没人想要的来源访问到。两者都是配置上的遗漏，而从用户的座位上看起来一模一样。

这两种错误都无法从一次成功的检验中看出来。正因如此，这两个决定值得分开记录、分开检验，即使由同一个人做出也不例外。

在服务上线之前把这两项都写下来，因为下一次变更会更容易推理。记录很短：一行写名称及其区域，一行写被接纳的来源与规则负责人。