本文介绍如何通过专用终结点向单个区域中的特定工作负载公开 PaaS 资源。 在此方案中，网络拓扑是中心辐射型，中心是 Azure 虚拟 WAN 中心。
重要
本文是介绍虚拟 WAN 中的 Azure 专用链接和 Azure DNS 的一系列文章的一部分，基于方案指南中定义的网络拓扑编写。 请先阅读概述页面，了解基本网络体系结构和面临的主要挑战。
方案
图 1：面向使用专用链接和 Azure DNS 的虚拟 WAN 的单区域方案 - 面临的挑战
下载此体系结构的 Visio 文件。 该部分对此方案进行了定义，并重新定义了此方案面临的挑战（此挑战与概述页面中的非工作示例相同）。 初始方案体系结构建立在概述指南中定义的起始网络拓扑之上。 新增内容和更改如下：
- 只有一个区域，它有一个虚拟中心。
- 区域中有一个 Azure 存储帐户，它禁用了公用网络访问。 在此方案中，假设只有一个工作负载访问该存储帐户。
- 最初有一个虚拟网络连接到该虚拟中心。
- 该虚拟网络具有一个工作负载子网，其中包含虚拟机 (VM) 客户端。
- 该虚拟网络包含一个专用终结点子网，其中有用于存储帐户的专用终结点。
达到的效果
Azure 虚拟机客户端可通过同一虚拟网络中的存储帐户专用终结点连接到 Azure 存储帐户，并且阻止对存储帐户的所有其他访问。
障碍
DNS 流中需要一条 DNS 记录，该记录能够将存储帐户的完全限定的域名 (FQDN) 解析回专用终结点的专用 IP 地址。 如概述中所述，该方案面临着双重挑战：
- 无法将维护存储帐户所需 DNS 记录的专用 DNS 区域链接到虚拟中心。
- 可以将专用 DNS 区域链接到工作负载网络，因此你可能会认为能够这样做。 遗憾的是，基线体系结构规定，每个连接的虚拟网络都有 DNS 服务器配置为指向使用 Azure 防火墙 DNS 代理。
由于无法将专用 DNS 区域链接到虚拟中心，并且虚拟网络配置为使用 Azure 防火墙 DNS 代理，因此 Azure DNS 服务器没有任何机制来将存储帐户的 FQDN 解析为专用终结点的专用 IP 地址。 结果是客户端收到错误的 DNS 响应。
DNS 和 HTTP 流
让我们查看此工作负载的 DNS 和生成的 HTTP 请求流。 查看可帮助我们直观了解前面描述的障碍。
图 2：面向使用专用链接和 Azure DNS 的虚拟 WAN 的单区域方案 - 面临的挑战
下载此体系结构的 Visio 文件。
DNS 流
- 从客户端对
stgworkload00.blob.core.windows.net进行的 DNS 查询将发送到所配置的 DNS 服务器，该服务器是对等互连区域中心的 Azure 防火墙。 - Azure 防火墙通过代理将请求发送到 Azure DNS。 由于无法将专用 DNS 区域链接到虚拟中心，因此 Azure DNS 不知道如何将 FQDN 解析为专用终结点的专用 IP 地址。 它知道如何将 FQDN 解析为存储帐户的公共 IP 地址，因此它会返回存储帐户的公共 IP 地址。
HTTP 流
- 有了 DNS 结果（即存储帐户的公共 IP 地址），客户端会向
stgworkload00.blob.core.windows.net发出 HTTP 请求。 - 该请求将发送到存储帐户的公共 IP 地址。 此请求失败的原因有很多：
- 工作负载子网上的 NSG 可能不允许这种 Internet 绑定流量。
- 正在筛选 Internet 绑定出口流量的 Azure 防火墙可能没有应用程序规则来支持此流。
- 即使 NSG 和 Azure 防火墙都允许此请求流，存储帐户也配置为阻止所有公用网络访问。 尝试的操作最终违反了仅允许通过专用终结点访问存储帐户这一目标。
解决方案 - 为 DNS 建立虚拟中心扩展
针对该挑战的解决方案是，让企业网络团队为 DNS 实现虚拟中心扩展。 DNS 虚拟中心扩展的唯一责任是，在此起始虚拟 WAN 中心拓扑中支持需要在其体系结构中使用专用 DNS 区域的工作负载团队。
DNS 扩展被实现为一个虚拟网络分支，它对等互连到其区域虚拟中心。 可以将专用 DNS 区域链接到此虚拟网络。 虚拟网络还包含一个 Azure DNS 专用解析程序；通过它，此虚拟网络外部的服务（例如 Azure 防火墙）能够查询和接收来自所有链接的专用 DNS 区域的值。 下面是用于 DNS 的典型虚拟中心扩展的组件，还有一些必需的配置更改：
- 一个与区域的虚拟中心对等互连的新分支虚拟网络。 此分支的配置与任何其他分支一样，这意味着默认 DNS 服务器和路由规则强制在区域中心使用 Azure 防火墙。
- DNS 专用解析程序资源在分支虚拟网络中使用入站终结点进行部署。
- 会创建一个名为
privatelink.blob.core.windows.net的专用 DNS 区域资源。- 此区域包含一条
A记录，该记录从存储帐户 FQDN 名称映射到存储帐户专用终结点的专用 IP 地址。 - 专用 DNS 区域链接到分支虚拟网络。
- 如果基于角色的访问控制 (RBAC) 允许，你可使用自动注册或服务托管条目来维护这些 DNS 记录。 如果没有，可以手动维护这些记录。
- 此区域包含一条
- 在区域中心，Azure 防火墙的 DNS 服务器更改为指向 DNS 专用解析程序的入站终结点。
下图演示了体系结构，还演示了 DNS 流和 HTTP 流。
图 3：面向使用专用链接和 DNS 的虚拟 WAN 的单区域方案的有效解决方案
下载此体系结构的 Visio 文件。
用于为 DNS 建立虚拟中心扩展的 DNS 流
从客户端对
stgworkload00.blob.core.windows.net进行的 DNS 查询发送到所配置的 DNS 服务器，该服务器是对等互连区域中心的 Azure 防火墙（在本例中，该中心是 10.100.0.132）。
图 4：工作负载虚拟网络的 DNS 服务器配置Azure 防火墙通过代理将请求发送到中心扩展中的区域 Azure DNS 专用解析程序 - 在本例中，是 10.200.1.4，它是 DNS 专用解析程序入站终结点的专用 IP 地址。
图 5：Azure 防火墙策略中的 DNS 配置
DNS 专用解析程序通过代理将请求发送到 Azure DNS。 由于专用 DNS 区域链接到包含入站终结点的虚拟网络，因此 Azure DNS 可使用这些链接的专用 DNS 区域中的记录。
图 6：专用 DNS 区域虚拟网络链接Azure DNS 查询链接的专用 DNS 区域，并将 FQDN
stgworkload00.blob.core.windows.net解析为 10.1.2.4，这是存储帐户专用终结点的 IP 地址。 此响应提供给 Azure 防火墙 DNS，后者随后将存储帐户的专用 IP 地址返回给客户端。
图 7：具有存储帐户专用终结点的 A 记录的专用 DNS 区域
HTTP 流
- 有了 DNS 结果（即存储帐户的专用 IP 地址），客户端会向
stgworkload00.blob.core.windows.net发出 HTTP 请求。 - 该请求将发送到存储帐户的专用 IP 地址 (10.1.2.4)。 此请求成功路由，假设客户端子网或专用终结点子网上的本地网络安全组中没有存在冲突的限制。 请务必了解，即使 Azure 防火墙保护专用流量，也不会通过 Azure 防火墙路由请求，因为专用终结点与客户端位于同一虚拟网络中。 这意味着无需针对此方案设置 Azure 防火墙允许情况。
- 与存储帐户的专用连接是通过专用链接服务建立的。 存储帐户仅允许专用网络访问，并接受 HTTP 请求。
用于 DNS 的虚拟中心扩展的注意事项
为企业实现扩展时，请考虑以下准则。
- 部署 DNS 扩展不是工作负载团队的任务。 此任务是一项企业联网功能，应该是与这些个人一起做出的实现决策。
- 在添加要为其配置专用终结点 DNS 记录的任何 PaaS 服务之前，必须存在 DNS 扩展和专用 DNS 区域。
- 虚拟中心扩展是一个区域资源，它可避免跨区域流量，并在每个期望进行专用终结点 DNS 解析的区域中心建立一个中心扩展。
辐射虚拟网络
- DNS 扩展的虚拟网络遵循单一责任原则，它应该仅包含 DNS 解析所需的资源，并且不得与其他资源共享。
- DNS 扩展的虚拟网络应遵循添加分支网络下的相同配置准则。
Azure DNS 专用解析程序
每个区域都应有一个虚拟中心 DNS 扩展，该扩展有一个 DNS 专用解析程序。
对于此方案，DNS 专用解析程序只需要入站终结点，不需要出站终结点。 入站终结点的专用 IP 是在 Azure 防火墙策略中为自定义 DNS 服务设置的 IP（请参阅图 5）。
为了提高复原能力和处理增加的负载，可通过使用多个 IP 地址配置的 Azure DNS 代理部署多个 DNS 专用解析程序实例来通过代理进行解析。
图 8：DNS 专用解析程序的入站终结点遵循 DNS 专用解析程序的虚拟网络限制。
DNS 专用解析程序入站终结点子网中的网络安全组应仅允许从其区域中心流向端口 53 的 UDP 流量。 应阻止所有其他的入站和出站流量。
专用 DNS 区域
由于 Azure DNS 专用解析程序通过 Azure DNS 解析 DNS，因此 Azure DNS 能够选取链接到其入站子网虚拟网络的任何专用 DNS 区域。
- 将专用 DNS 区域链接到 DNS 虚拟网络的虚拟中心扩展。
- 遵循有关管理专用终结点的专用 DNS 区域的指南。
- 如果希望 PaaS 资源所有者管理他们自己的条目，请相应地配置 RBAC，或者实现解决方案，例如大规模专用链接和 DNS 集成中的解决方案。
方案注意事项
有了一个管理良好的虚拟中心 DNS 扩展，让我们回到工作负载并解决其他一些问题，来帮助实现此方案中达到的效果目标。
存储帐户
- 设置公用网络访问：在网络连接下禁用，以确保只能通过专用终结点访问存储帐户。
- 将专用终结点添加到工作负载虚拟网络中专门的专用终结点子网。
- 将 Azure 诊断发送到工作负载 Log Analytics 工作区。 可以使用访问日志来帮助排查配置问题。
专用终结点安全性
此解决方案的一项要求是限制此存储帐户的公开。 移除对 PaaS 资源的公共 Internet 访问后，应解决专用网络安全问题。
当 Azure 防火墙在虚拟 WAN 中心辐射型拓扑中保护专用流量时，Azure 防火墙默认为拒绝分支到分支的连接。 此默认设置阻止其他分支网络中的工作负载访问工作负载虚拟网络中的专用终结点（和其他资源）。 完全在虚拟网络中的流量不通过 Azure 防火墙进行路由。 若要控制虚拟网络中的访问并添加更精细的保护，请考虑以下网络安全组 (NSG) 建议。
- 创建应用程序安全组 (ASG)，对具有类似的入站或出站访问需求的资源进行分组。 在此方案中，将一个 ASG 用于需要访问存储的客户端 VM，并将一个 ASG 用于被访问的存储帐户。 请参阅使用专用终结点配置应用程序安全组 (ASG)。
- 确保包含工作负载 VM 的子网具有 NSG。
- 确保包含专用终结点的子网具有 NSG。
针对包含工作负载 VM 的子网的 NSG 规则
除了工作负载所需的任何其他网络规则外，还请配置以下规则。
- 出站规则：
- 允许计算 ASG 访问存储帐户 ASG。
- 允许计算 ASG 访问区域中心 Azure 防火墙的专用 IP，在端口 53 上实现 UDP。
*图 9：针对工作负载子网的 NSG 规则
针对包含专用终结点的子网的 NSG 规则
最佳做法是在正在使用的虚拟网络中的小型专用子网上公开专用终结点。 一个原因是你可以为专用终结点应用用户定义的路由和网络安全组网络策略，来增加流量控制和安全性。
在此方案中，可应用高度受限的网络安全组。
- 入站规则：
- 允许计算 ASG 访问存储帐户 ASG
- 拒绝所有其他流量
- 出站规则：
- 拒绝所有流量
*图 10：针对专用终结点子网的 NSG 规则
专用终结点安全性的运用情况
下图演示了按照所概述的注意事项操作如何提供深层防御安全性。 此图显示了第二个分支虚拟网络，它有第二个 VM。 该工作负载无法访问专用终结点。
图 11：面向使用专用链接和 DNS 的虚拟 WAN 的单区域方案的有效解决方案
下载此体系结构的 Visio 文件。
DNS 流
DNS 流与解决方案流中的完全相同。
需要强调的是，FQDN 解析为专用 IP 地址，而不是公共 IP 地址。 这样解析意味着所有分支始终接收此服务的专用 IP 地址。 另一个方案介绍了如何采用此方法在多个正在使用的工作负载之间共享 PaaS 服务。 对于这个单工作负载方案，这不构成问题。
HTTP 流
- 有了 DNS 结果（即存储帐户的专用 IP 地址），客户端会向
stgworkload00.blob.core.windows.net发出 HTTP 请求。 - 该请求将发送到存储帐户的专用 IP 地址。 此请求因多种原因而失败：
- Azure 防火墙配置为保护专用流量，因此它会处理请求。 除非 Azure 防火墙有允许流的网络或应用程序规则，否则 Azure 防火墙会阻止该请求。
- 无需在中心使用 Azure 防火墙来保护专用流量。 例如，如果你的网络支持专用跨区域流量，那么专用终结点子网上的 NSG 仍然配置为阻止托管工作负载的虚拟网络中的所有流量（计算 ASG 源除外）。
摘要
本文介绍了这样一种方案：VM 客户端通过存储帐户的专用终结点连接到 Azure 存储帐户。 终结点与客户端位于同一虚拟网络中。 对存储帐户的所有其他访问都会被阻止。 此方案要求 DNS 流中有一条 DNS 记录，该记录能够将存储帐户的完全限定的域名 (FQDN) 解析回专用终结点的专用 IP 地址。
此方案的起始网络拓扑引入了两项挑战：
- 无法将带有存储帐户所需 DNS 记录的专用 DNS 区域链接到虚拟中心。
- 无法将专用 DNS 区域链接到工作负载子网。 起始网络拓扑要求默认 DNS 服务器和路由规则强制在区域中心使用 Azure 防火墙。
建议的解决方案是，让企业网络团队为 DNS 实现虚拟中心扩展。 通过此扩展，企业网络团队可以向需要共享 DNS 服务的工作负载分支公开这些服务。