fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net has address 10.1.2.3
有两个明显的区别。 首先，名称解析为专用 IP 地址。 该地址必须是在本文相应部分找到的 IP 地址。 其次，privatelink 别名后面没有其他别名。 出现这种情况的原因是，虚拟网络 DNS 服务器会截获别名链，并直接从名称 fabrikam.privatelink.vaultcore.azure.net 返回专用 IP 地址。 该条目实际上是专用 DNS 区域中的 A 记录。 稍后会详述这一点。
上述结果仅发生在一台虚拟机上，该虚拟机已连接到在其中创建了专用终结点的虚拟网络。 如果没有在包含专用终结点的虚拟网络中部署 VM，请部署一台并通过远程方式连接到该 VM，然后执行上面的 nslookup 命令 (Windows) 或 host 命令 (Linux)。
如果在连接到创建了专用终结点的虚拟网络的虚拟机上运行这些命令，但它们未显示密钥保管库专用 IP 地址，则可参阅下一部分，了解如何解决此问题。
6.验证专用 DNS 区域
如果 DNS 解析未按上一部分所述方式进行，则专用 DNS 区域可能存在问题，可参阅此部分来解决它。 如果 DNS 解析显示了正确的密钥保管库专用 IP 地址，则专用 DNS 区域可能是正确的。 你可以跳过这整个部分。
确认所需的专用 DNS 区域资源存在
Azure 订阅必须有专用 DNS 区域资源，该资源必须有以下确切名称：
privatelink.vaultcore.azure.net
可以通过转到门户中的订阅页并选择左侧菜单中的“资源”来检查该资源是否存在。 资源名称必须是 privatelink.vaultcore.azure.net，资源类型必须是“专用 DNS 区域”。
通常情况下，当你使用通用过程创建专用终结点时，系统会自动创建该资源。 但在某些情况下，系统不会自动创建该资源，你必须手动创建它。 该资源也可能已被意外删除。
如果没有该资源，请在订阅中创建新的专用 DNS 区域资源。 请记住，名称必须与 privatelink.vaultcore.azure.net 完全一致，不包含空格或其他点。 如果指定的名称不正确，则本文所述的名称解析将不起作用。 若要详细了解如何创建此资源，请参阅使用 Azure 门户创建 Azure 专用 DNS 区域。 如果按该页的要求操作，则可以跳过虚拟网络创建操作，因为你此时应该已经有一个虚拟网络。 还可以跳过通过虚拟机进行的验证过程。
确认专用 DNS 区域已链接到虚拟网络
单纯有一个专用 DNS 区域还不够。 还必须将它链接到包含专用终结点的虚拟网络。 如果专用 DNS 区域未链接到正确的虚拟网络，则从该虚拟网络进行的任何 DNS 解析都会忽略专用 DNS 区域。
打开专用 DNS 区域资源，然后单击左侧菜单中的“虚拟网络链接”选项。 此时会显示一个链接列表，每个链接都有一个订阅中的虚拟网络的名称。 包含专用终结点资源的虚拟网络必须在此处列出。 如果它不存在，请添加它。 有关详细步骤，请参阅链接虚拟网络。 可以让“启用自动注册”保持取消选中状态，该功能与专用链接无关。
专用 DNS 区域链接到虚拟网络后，源自虚拟网络的 DNS 请求会在专用 DNS 区域中查找名称。 这是在虚拟机上执行正确的地址解析所需的，这些虚拟机已连接到在其中创建了专用终结点的虚拟网络。
如果你刚刚保存了该链接，则此操作可能需要一段时间才能生效，即使在门户指示操作完成后也是如此。 可能还需要重启用于测试 DNS 解析的 VM。
确认专用 DNS 区域包含正确的 A 记录
请使用门户打开名为 privatelink.vaultcore.azure.net 的专用 DNS 区域。 “概述”页会显示所有记录。 默认情况下，会有一条名称为 @ 且类型 SOA 的记录，这表示“起始授权机构”。 请勿对其执行任何操作。
若要使密钥保管库名称解析生效，必须有一个 A 记录，该记录使用简单的保管库名称，不含后缀或点。 例如，如果主机名为 fabrikam.vault.azure.net，则必须存在名称为 fabrikam 且不含任何后缀或点的 A 记录。
此外，A 记录（IP 地址）的值必须是密钥保管库专用 IP 地址。 如果找到 A 记录，但其中包含错误的 IP 地址，则必须删除错误的 IP 地址并添加新的 IP 地址。 建议删除整个 A 记录并添加一个新记录。
删除或修改 A 记录时，计算机仍可能会解析为旧 IP 地址，因为 TTL（生存时间）值可能尚未过期。 建议始终将 TTL 值指定为不小于 10 秒且不大于 600 秒（10 分钟）。 如果指定的值太大，则客户端可能需要很长时间才能从中断中恢复。
针对多个虚拟网络的 DNS 解析
如果有多个虚拟网络，每个虚拟网络都通过其自己的专用终结点资源来引用同一密钥保管库，则密钥保管库主机名需要根据网络解析为不同的专用 IP 地址。 这意味着还需要多个专用 DNS 区域，每个区域链接到不同的虚拟网络，并在 A 记录中使用不同的 IP 地址。
在更高级的方案中，虚拟网络可能已启用对等互连。 在这种情况下，只有一个虚拟网络需要专用终结点资源，尽管这两个虚拟网络都可能需要链接到专用 DNS 区域资源。 本文档不直接介绍这种情况。
明白你可以控制 DNS 解析
如上一部分所述，具有专用链接的密钥保管库在其公共注册中的别名为 {vaultname}.privatelink.vaultcore.azure.net。 虚拟网络所用的 DNS 服务器使用公共注册，但会检查每个别名是否有专用注册，在找到专用注册的情况下不再遵循在公共注册中定义的别名。
此逻辑意味着，如果虚拟网络链接到名为 privatelink.vaultcore.azure.net 的专用 DNS 区域，并且密钥保管库的公共 DNS 注册别名为 fabrikam.privatelink.vaultcore.azure.net（注意，密钥保管库主机名后缀与专用 DNS 区域名称精确匹配），则 DNS 查询会在专用 DNS 区域中查找名称为 fabrikam 的 A 记录。 如果找到 A 记录，则会在 DNS 查询中返回其 IP 地址，不再在公共 DNS 注册中进一步查找。
可以看到，你可以控制名称解析。 之所以进行此设计，根本原因是：
你可能有一个复杂的方案，该方案涉及自定义 DNS 服务器以及与本地网络的集成。 在这种情况下，需要控制将名称转换为 IP 地址的方式。
你可能需要访问没有专用链接的密钥保管库。 在这种情况下，从虚拟网络解析主机名时必须返回公共 IP 地址，这是因为没有专用链接的密钥保管库在名称注册中没有 privatelink 别名。
7.验证对密钥保管库的请求是否使用专用链接
查询密钥保管库的 /healthstatus 终结点
密钥保管库提供可用于诊断的 /healthstatus 终结点。 响应头包含源 IP 地址，就像密钥保管库服务所看到的那样。 可以使用以下命令调用该终结点（请记得使用密钥保管库主机名）：
Windows (PowerShell)：
PS C:\> $(Invoke-WebRequest -UseBasicParsing -Uri https://fabrikam.vault.azure.net/healthstatus).Headers
Key Value
--- -----
Pragma no-cache
x-ms-request-id 3729ddde-eb6d-4060-af2b-aac08661d2ec
x-ms-keyvault-service-version 1.2.27.0
x-ms-keyvault-network-info addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security max-age=31536000;includeSubDomains
Content-Length 4
Cache-Control no-cache
Content-Type application/json; charset=utf-8
Linux 或最新版本的 Windows 10，其中包含 curl：
joe@MyUbuntu:~$ curl -i https://fabrikam.vault.azure.net/healthstatus
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
x-ms-request-id: 6c090c46-0a1c-48ab-b740-3442ce17e75e
x-ms-keyvault-service-version: 1.2.27.0
x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security: max-age=31536000;includeSubDomains
Content-Length: 4
如果未获得类似于这样的输出，或者出现网络错误，则意味着无法通过指定的主机名（在示例中为 fabrikam.vault.azure.net）访问密钥保管库。 主机名未解析为正确的 IP 地址，或者在传输层出现连接性问题。 这可能是由路由问题、包删除和其他原因造成的。 需要进一步调查。
响应必须包含 x-ms-keyvault-network-info 头：
x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;
x-ms-keyvault-network-info 头中的 addr 字段显示请求源的 IP 地址。 此 IP 地址可能是以下地址之一：
进行请求的计算机的专用 IP 地址。 这表明请求使用的是专用链接或服务终结点。 这是专用链接的预期结果。
某个其他的专用 IP 地址，不是来自进行请求的计算机。 这表明某个自定义路由有效。 这仍然表明请求使用的是专用链接或服务终结点。
某个公共 IP 地址。 这表明请求将通过网关 (NAT) 设备路由到 Internet。 这表明请求未使用专用链接，某些问题需要修复。 这种情况的常见原因是：1) 专用终结点未处于“已批准”和“已成功”状态；2) 主机名未解析为密钥保管库的专用 IP 地址。 本文包括这两种情况下的故障排除操作。
如果向 /healthstatus 发出的请求有效，但缺少 x-ms-keyvault-network-info 头，则终结点可能不是由密钥保管库提供服务的。 由于上述命令也验证 HTTPS 证书，缺少头可能表明存在篡改操作。
直接查询密钥保管库 IP 地址
不经过 HTTPS 证书验证就访问密钥保管库是危险的，只能用于学习目的。 如果没有进行此客户端验证，则生产代码不得访问密钥保管库。 即使你只是诊断问题，但如果你经常在对密钥保管库发出的请求中禁用 HTTPS 证书验证，则也可能会受到那些不会显示的篡改尝试的攻击。
如果安装了 PowerShell 的最新版本，则可使用 -SkipCertificateCheck 跳过 HTTPS 证书检查，然后直接将密钥保管库 IP 地址设定为目标：
PS C:\> $(Invoke-WebRequest -SkipCertificateCheck -Uri https://10.1.2.3/healthstatus).Headers
如果使用 curl，则可使用 -k 参数执行相同操作：
joe@MyUbuntu:~$ curl -i -k https://10.1.2.3/healthstatus
响应必须与上一部分的相同，这意味着它必须包含具有相同值的 x-ms-keyvault-network-info 头。 /healthstatus 终结点不“在意”你使用的是密钥保管库主机名还是 IP 地址。
如果你看到 x-ms-keyvault-network-info 针对使用密钥保管库主机名的请求返回一个值，针对使用 IP 地址的请求返回另一个值，则表明每个请求针对的是不同的终结点。 请参阅上一部分中来自 x-ms-keyvault-network-info 的 addr 字段的说明，以确定哪种情况是错误的，需要修复。
8.造成影响的其他更改和自定义
以下各项并非详尽的调查操作。 这些操作会告知你查找其他问题的位置，但你必须具备高级网络知识才能修复这些方案中的问题。
在虚拟网络中诊断自定义 DNS 服务器
在门户中，打开虚拟网络资源。 在左侧菜单中，打开“DNS 服务器”。 如果使用的是“自定义”，则 DNS 解析可能不符合本文档所述。 必须对 DNS 服务器解析密钥保管库主机名的方式进行诊断。
如果使用的是 Azure 提供的默认 DNS 服务器，则这整个文档都适用。
在虚拟机上诊断 hosts 重写或自定义 DNS 服务器
许多操作系统允许按主机名设置显式的固定 IP 地址，这通常通过更改 hosts 文件来实现。 这些系统可能还允许重写 DNS 服务器。 如果你使用这些方案之一，则请使用特定于系统的诊断选项。
混合代理（Fiddler 等）
除非明确指出，否则本文中的诊断选项仅适用于环境中不存在混合代理的情况。 尽管这些代理通常以独占方式安装在所诊断的计算机中（Fiddler 是最常见的例子），但高级管理员可以覆盖根证书颁发机构 (CA)，并在为网络中的多台计算机提供服务的网关设备中安装混合代理。 这些代理可能会显著影响安全性和可靠性。 Microsoft 不支持那些使用此类产品的配置。
可能影响连接性的其他因素
这是可以在高级或复杂方案中找到的项的不完整列表：
防火墙设置，不管是连接到虚拟网络的 Azure 防火墙，还是在虚拟网络或计算机中部署的自定义防火墙解决方案。
网络对等互连，这可能会对使用哪些 DNS 服务器以及如何路由流量造成影响。
自定义网关 (NAT) 解决方案，这可能会影响流量（包括来自 DNS 查询的流量）的路由方式。
