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 代理导致的复杂性，让我们回顾一下启用 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 记录， stgworkload00.privatelink.blob.core.windows.net该记录将 FQDN 映射到专用终结点的专用 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 区域。 Azure DNS 不知道如何通过提供默认地址（即公共 IP 地址）来解析查询。

图 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 服务是存储帐户。应将 VM 视为虚拟网络上公开的 NIC 的任何 Azure 资源的备用 VM，例如虚拟机规模集、Azure Kubernetes 服务节点或任何其他以类似方式路由的服务。

重要

Azure 存储帐户的专用链接实现可能与其他 PaaS 服务不同，但对于许多服务而言，它确实与许多服务保持一致。例如，某些服务通过专用链接公开时删除 FQDN 记录，这可能会导致不同的行为，但此类差异通常不是这些方案的解决方案的一个因素。

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

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

后续步骤

读取单个区域专用 PaaS 资源方案

通过