为什么专用终结点仍然返回公共地址

笔记本电脑已连接，隧道报告自身已启动，而存储账户仍然拒绝每一个请求。专用终结点存在，通往其子网的路由也存在，而这个名称要么返回公共地址，要么根本无法解析。隧道本身没有任何问题：客户端从未被告知应由哪台服务器为该名称作答。沿着查询向外追踪，缺口就一目了然了。

从客户端使用的解析器开始

在隧道启动期间，询问客户端向哪台服务器发起查询。点到站点配置文件会提供该地址；而不提供任何地址的配置文件，则让操作系统回退到适配器的默认设置。

公共解析器看不到专用区域，因此它们从互联网作答，而这正是它们的职责。所以第一项检查是正在使用的解析器地址，而不是隧道，也不是终结点。

看清答案到底是什么

解析服务名称并读取返回的地址。返回公共地址，说明查询到达了一台看不到该区域的服务器。若没有响应，则说明该名称只存在于专用环境中，而客户端能触及的任何地方都没有保存它。

这两种结果会产生相似的应用错误，却属于不同的责任方。一种是解析器选择问题，另一种是缺少区域关联。

hosts 条目能证明通路，随后就会撒谎

把终结点地址写进本地 hosts 文件，是证明隧道和服务防火墙已经生效的最快办法。如果带上这个条目请求成功，那么只有名称解析是坏的。它同时也是一台机器上的改动，而且只覆盖一个名称。

它帮不了第二个账户、第二个终结点，也帮不了同事；一旦终结点以新地址重建，它就会毫无预警地失效。

更糟的是，它让你的机器与所有人的行为都不一样，而解析器故障正是靠这一点熬过一整周的排查。用它确认通路，然后把它删掉并修复根因。

关联区域并下发解析器

必须同时满足两个条件。专用区域要关联到终结点所在的虚拟网络，客户端则要把查询发送给能够读取该区域的服务器。DNS Private Resolver 的入站终结点就能在网络内部提供这样一个地址，并应答经隧道到达的查询。把这个地址写入 VPN 配置文件，并加上客户端应当应用的专用后缀。

已有的本地解析器也可以通过指向该区域的条件转发器达到同样的效果。

解析器上的网络规则与路由同等重要。如果入站规则把 VPN 客户端网段排除在外，查询就会超时，而不是返回错误答案。正是这种超时把人送回到一张毫无问题的路由表前。

按顺序检查名称、端口和身份

按顺序推进：解析名称、确认返回的是专用地址、打开端口，然后发出经过身份验证的请求。每个阶段都有自己的责任方和各自的失败特征。

专用应答之后出现超时，指向路由或防火墙。公共应答指向解析器。连接已建立却返回身份错误，属于服务本身。

还有一类故障也属于这份清单。服务防火墙允许了某个客户端地址，但重连之后地址池把该地址分给了另一个会话，规则就不再匹配。要读服务记录的调用方地址，而不是客户端自认为拥有的地址。两者不一致的频率比人们预想的更高。Azure DNS Private Resolver 指南涵盖了区域关联与转发配置。