你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 虚拟 WAN 专用链接和 DNS 指南

Azure 专用链接

Azure DNS

Azure 防火墙

Azure 虚拟 WAN

Azure 专用链接使客户端能够直接从专用虚拟网络访问 Azure 平台即服务(PaaS)服务，无需使用公共 IP 寻址。对于每项服务，请配置专用终结点，该终结点使用来自网络的专用 IP 地址。然后，客户端可以使用该专用终结点以私密方式连接到服务。

客户端继续使用服务的完全限定的域名(FQDN)连接到该服务。在网络中配置 DNS，从而将服务的 FQDN 解析为专用终结点的专用 IP 地址。

网络设计（尤其是 DNS 配置）是支持专用终结点与服务连接的关键因素。本文是一系列文章之一，这些文章提供有关实现各种专用链接场景的指南。即使没有场景与你的情况完全匹配，也应该能够调整设计以满足需求。

起始网络拓扑

起始网络拓扑 是一种网络体系结构，用作本系列文章中所有场景的起点。该体系结构是使用 Azure 虚拟 WAN 的典型中心辐射型网络。

图 1：所有专用终结点和 DNS 场景的起始网络拓扑

下载此体系结构的 Visio 文件。 此拓扑具有以下特征：

它是使用 Azure 虚拟 WAN 实现的中心辐射型网络。
有两个区域，每个区域都有区域 Azure 防火墙安全虚拟中心。
每个安全区域虚拟中心均有以下 Azure 虚拟网络连接的安全设置：
- Internet 流量：受 Azure 防火墙保护 - 流向 Internet 的所有流量都流经区域中心防火墙。
- 专用流量：受Azure 防火墙保护 - 从分支到分支传输的所有流量都流经区域中心防火墙。
每个区域虚拟中心都使用 Azure 防火墙进行保护。区域中心防火墙具有以下设置：
- DNS 服务器：默认（Azure 提供） - 区域中心防火墙显式使用 Azure DNS 在规则集合中进行 FQDN 解析。
- DNS 代理：已启用 - 区域中心防火墙响应端口 53 上的 DNS 查询。它将未缓存值的查询转发到 Azure DNS。
- 防火墙将规则评估和 DNS 代理请求记录到同一区域的 Log Analytics 工作区中。记录这些事件是常见的网络安全日志记录要求。
对于每个连接的虚拟网络分支，其默认的 DNS 服务器配置为区域中心防火墙的专用 IP 地址。否则，FQDN 规则评估可能不同步。

多区域路由

如果有多个安全虚拟中心，安全虚拟 WAN 中心对中心间连接的支持有限。此限制会影响多中心、区域内和跨区域场景。因此，网络拓扑不会直接推动通过 Azure 防火墙筛选专用跨区域流量。使用虚拟 WAN 中心路由意向和路由策略提供对此功能的支持。此功能目前以预览版提供。

对于本系列文章，假设内部安全流量不会遍历多个中心。必须遍历多个中心的流量必须在并行拓扑上执行此操作，该拓扑不会通过安全虚拟中心筛选专用流量，但允许其通过。

添加分支网络

添加分支网络后，它们遵循起始网络拓扑中定义的约束。具体来说，每个分支网络都与其区域中心内的默认路由表关联，且防火墙配置为保护 Internet 和专用流量。以下屏幕截图显示了配置示例：

图 2：虚拟中心内虚拟网络连接的安全配置

主要挑战

起始网络拓扑给为专用终结点配置 DNS 带来了挑战。

虽然使用虚拟 WAN 可提供托管中心体验，但代价是影响虚拟中心配置或向虚拟中心添加更多组件的能力有限。使用传统的中心辐射型拓扑，可以在自托管中心共享常见网络服务（例如 DNS 记录）时隔离分支中的工作负载。通常，将专用 DNS 区域链接到中心网络，以便 Azure DNS 可以解析客户端的专用终结点 IP 地址。

但是，无法将专用 DNS 区域链接到虚拟 WAN 中心，因此在中心内发生的任何 DNS 解析都不知道专用区域。具体来说，这是 Azure 防火墙（为工作负载分支配置的 DNS 提供程序，它使用 DNS 进行 FQDN 解析）存在问题。

使用虚拟 WAN 中心时，将专用 DNS 区域链接到工作负载需要 DNS 解析的分支虚拟网络似乎很直观。但是，如体系结构中所述，DNS 代理在区域防火墙上启用，并且所有分支都应将其区域防火墙用作 DNS 源。 Azure DNS 从防火墙（而非工作负载的网络）调用，因此在解析中不使用工作负载网络上的任何专用 DNS 区域链接。

注意

要将区域防火墙配置为分支的 DNS 提供程序，请将分支虚拟网络上的自定义 DNS 服务器设置为指向防火墙的专用 IP（而非正常的 Azure DNS 值）。

鉴于在区域防火墙上启用 DNS 代理很复杂，我们来看看启用它的原因。

Azure 防火墙网络规则支持基于 FQDN 的限制，以便更精确地控制应用程序规则不处理的出口流量。此功能要求启用 DNS 代理。常见用途是限制网络时间协议 (NTP) 流量流向已知终结点，例如 time.windows.com。
安全团队可以从 DNS 请求日志记录中获益。 Azure 防火墙内置对 DNS 请求日志记录的支持，因此要求所有分支资源都将 Azure 防火墙用作其 DNS 提供程序可确保广泛的日志记录覆盖范围。

为了说明挑战，以下部分介绍了两种配置。简单的示例起作用，更复杂的示例不起作用，但它的失败具有指导性。

工作场景

以下示例是基本的专用终结点配置。虚拟网络包含需要通过专用终结点使用 PAAS 服务的客户端。链接到虚拟网络的专用 DNS 区域具有 A 记录，用于将服务的 FQDN 解析为专用终结点的专用 IP 地址。下图说明了该流程。

图 3：专用终结点的基本 DNS 配置

下载此体系结构的 Visio 文件。

客户端向 stgworkload00.blob.core.windows.net 发出请求。
查询 Azure DNS（为虚拟网络配置的 DNS 服务器）以获取 stgworkload00.blob.core.windows.net 的 IP 地址。

从虚拟机(VM)运行以下命令表明 VM 配置为将 Azure DNS (168.63.129.16)用作 DNS 提供程序。
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
专用 DNS 区域 privatelink.blob.core.windows.net 链接到工作负载 VNet，因此 Azure DNS 在其响应中合并了来自工作负载 VNet 的记录。
由于专用 DNS 区域中存在一条 A 记录，将 FQDN stgworkload00.privatelink.blob.core.windows.net 映射到专用终结点的专用 IP，因此返回专用 IP 地址 10.1.2.4。

从 VM 运行以下命令会将存储帐户的 FQDN 解析为专用终结点的专用 IP 地址。
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
向专用终结点的专用 IP 地址（在本例中为 10.1.2.4）发出请求。
请求通过专用链接路由到存储帐户。

设计之所以起作用，是因为 Azure DNS：

是为虚拟网络配置的 DNS 服务器。
知道链接的专用 DNS 区域。
使用区域的值解析 DNS 查询。

非工作场景

以下示例是在起始网络拓扑中使用专用终结点的朴素尝试。无法将专用 DNS 区域链接到虚拟 WAN 中心。因此，当客户端配置为将防火墙用作其 DNS 服务器时，DNS 请求会从虚拟中心内转发到 Azure DNS，该虚拟中心没有链接的专用 DNS 区域。除了提供默认值（即公共 IP 地址）之外，Azure DNS 不知道如何解析查询。

图 4：在起始网络拓扑中使用专用终结点的朴素尝试

下载此体系结构的 Visio 文件。

客户端向 stgworkload00.blob.core.windows.net 发出请求。

从 VM 运行以下命令表明 VM 配置为将虚拟中心防火墙用作 DNS 提供程序。
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
防火墙已启用 DNS 代理，默认设置为将请求转发到 Azure DNS。请求会转发到 Azure DNS。
Azure DNS 无法将 stgworkload00.blob.core.windows.net 解析为专用终结点的专用 IP 地址，原因如下：
1. 专用 DNS 区域无法链接到虚拟 WAN 中心。
2. Azure DNS 不知道链接到工作负载虚拟网络的专用 DNS 区域，因为为工作负载虚拟网络配置的 DNS 服务器是 Azure 防火墙。 Azure DNS 使用存储帐户的公共 IP 地址进行响应。
从 VM 运行以下命令会将存储帐户的 FQDN 解析为存储帐户的公共 IP。
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
由于 Azure 防火墙正在代理 DNS 查询，因此我们能够记录它们。下面是 Azure 防火墙 DNS 代理日志示例。
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
客户端不会接收专用链接终结点的专用 IP 地址，并且无法与存储帐户建立专用连接。

上述行为是预期行为。这是该场景要解决的问题。

方案

虽然此问题的各解决方案类似，但演练常见工作负载场景展示了解决方案如何满足各种情况的要求。大多数场景包括通过专用终结点访问一个或多个 PaaS 服务的客户端。它们遵循起始网络拓扑，但工作负载要求不同。这些场景从访问单个区域 PaaS 服务的客户端开始。它们变得越来越复杂，增加了更多的网络可见性、区域和 PaaS 服务。

在大多数情况下，客户端实现为 VM，且客户端访问的 PaaS 服务是存储帐户。对于具有虚拟网络上公开的 NIC 的任何 Azure 资源（例如虚拟机规模集、Azure Kubernetes 服务节点或以类似方式路由的任何其他服务），应将 VM 视为备用资源。

重要

Azure 存储帐户的专用链接实现可能与其他 PaaS 服务在细微方面不同，但在许多方面，它确实非常一致。例如，一些服务在通过专用链接公开时会删除 FQDN 记录，这可能会导致不同的行为，但此类差异通常不是这些场景的解决方案中的因素。

每个场景都从所需的结束状态开始，并详细说明了从起始网络拓扑到所需结束状态所需的配置。每个场景的解决方案都利用了虚拟中心扩展模式。此模式解决了如何以隔离和安全的方式公开共享服务，作为区域中心的概念扩展。下表包含指向虚拟中心扩展模式和场景的链接。

指南	说明
单个区域，专用 PaaS	单个区域中的工作负载访问一个专用 PaaS 资源。

后续步骤

读取单个区域专用 PaaS 资源场景

通过

Azure 虚拟 WAN 专用链接和 DNS 指南