通过

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

防止 Azure 中的 IPv4 耗尽

企业网络通常使用由请求注释 (RFC) 1918定义的专用 IPv4 地址范围中的地址空间，例如 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。 在本地环境中，这些范围提供足够的 IP 地址，甚至满足最大网络的要求。 因此，许多组织制定了地址管理做法，这些做法优先考虑简单的路由配置和 IP 地址分配的敏捷流程。 它们通常不会优先考虑高效使用 IPv4 地址空间。

在云中，大型网络易于构建。 某些常见的体系结构模式（如微服务或容器化）可能会导致 IPv4 地址消耗增加。 因此，必须采用更保守的地址管理做法，并将 IPv4 地址视为有限的资源。

注释

建议在 Azure 虚拟网络中使用 RFC 1918 定义的地址块。 有关详细信息，请参阅 虚拟网络的地址范围。

本文介绍在 Azure 中生成大型网络时最大程度地减少 IPv4 地址空间消耗的两种方法。 这些方法依赖于在多个虚拟网络或登陆区域中重复使用相同 IPv4 地址块的网络拓扑。

  • 方法 1：使用 IPv4 子网对等互连将一个或多个子网从登陆区域的分支虚拟网络和中心虚拟网络之间的对等互连中排除。 可以将相同的非路由 IP 地址范围分配给所有登陆区域中对等关系中排除的子网。 这些 IP 地址范围不能与其他可路由的 IP 地址范围重叠。

  • 方法 2： 在未连接到登陆区域的虚拟网络的独立虚拟网络中部署应用程序。 将其终结点与 Azure 专用链接服务相关联。 在登陆区域的分支虚拟网络中，创建与专用链接服务关联的专用终结点。 隔离的虚拟网络可以使用任何 IPv4 地址空间，即使它与公司网络的可路由地址空间重叠。

方法 1 最适合传统企业环境，其中多个系统和应用程序相互依赖。 方法 2 在独立运行的应用程序的松散耦合环境中效果最佳。

Azure 登陆区域对齐

本文中的建议适用于基于 Azure 登陆区域体系结构的网络拓扑：

  • 托管 Azure 资源的每个区域都有一个中心辐射型网络。

  • 不同区域的中心辐射型网络通过全局虚拟网络对等互连进行连接。

  • 中心辐射型网络通过 Azure ExpressRoute 线路或站点到站点 VPN 连接到本地站点。

在 Azure 登陆区体系结构中，每个应用程序在其自己的分支虚拟网络中运行。 每个分支虚拟网络在整个公司网络中使用唯一的 IPv4 地址空间。

登陆区域中的所有资源都可以通过以下方式进行连接：

  • 使用他们的 IP 地址建立与企业网络中任何其他资源的连接

  • 通过 IP 地址接收来自整个公司网络的直接连接

但是，资源并不总是需要整个企业网络的可访问性。 例如，在包含三层 Web 应用程序的登陆区域中，例如 HTTP 前端、业务逻辑和数据层，只有 HTTP 前端才能从登陆区域外部访问。 其他层必须相互连接和前端，但它们不需要接受来自客户端的连接。 此示例建议通过将以下组件分配给每个登陆区域来最大程度地减少 IPv4 地址消耗：

  • 整个企业网络中独一无二的地址空间。 只有必须从其登陆区域外部访问的资源才使用此地址空间。 本文将此地址空间称为登陆区域的 可路由地址空间。

  • 仅需要与自己的登陆区域内的其他资源进行通信的资源的内部地址空间。 此地址空间不需要从企业网络直接访问。 本文将此地址空间称为登陆区域的 非路由地址空间。

在以下部分中， 前端组件 是指必须从整个企业网络访问的应用程序组件。 后端组件 是指一个应用程序组件，该组件不公开企业网络中的终结点，并且只需在其自己的登陆区域中才能访问。

方法 1：分支虚拟网络中不可路由的子网

可以使用 IPv4 子网对等互连 将两个虚拟网络之间的对等互连关系限制为特定子网。 只有对等互连配置中包含的子网才能相互路由流量。 从对等互连配置中排除的子网在对等虚拟网络中仍然不可见且无法访问。

在中心辐射型拓扑中，如果从对等互连配置中排除每个辐射中的一个或多个子网，则这些子网对于中心以及通过其他对等互连、ExpressRoute 连接或 VPN 连接连接到中心的任何远程网络而言均不可见且不可访问。 因此，可以将相同的地址范围分配给所有分支虚拟网络中从对等互连配置中排除的所有子网。 该范围必须定义为 非路由 ，并且不能在企业网络中的任何其他位置使用。

下图包括以下组件：

  • 该范围 10.57.0.0/16 充当非路由地址空间。

  • 中心虚拟网络和每个登陆区域分支虚拟网络使用唯一的可路由 IP 地址范围（10.0.0.0/24、10.1.0.0/24 和 10.2.0.0/24）。

  • 每个登陆区域分支虚拟网络还包含非路由范围 10.57.0.0/16 内的一个或多个非路由子网。 Azure 虚拟网络的地址空间可以包含多个 IP 地址范围。

  • 这些子网被排除在与中心的对等互连关系之外。 因此，不同登陆区域分支中的非路由子网可以在 10.57.0.0/16 内具有相同或重叠的地址范围。

显示了如何将子网对等互连用于具有可路由和不可路由地址空间的登陆区域的示意图。

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

这种方法保留了登陆区域分支虚拟网络内的完整连接。 无论它们是位于可路由的子网段还是不可路由的子网段，同一个发散虚拟网络中的所有资源都可以相互连接。 但是，只有可路由子网中的资源可以连接到其自身登陆区域之外的资源。

将应用程序部署到登陆区域

在使用子网对等互连来构建具有非路由子网的登陆区域时，可以应用不同的模式在可路由和不可路由子网之间分布应用程序的前端和后端组件。 以下注意事项适用于从使用单个完全可路由的地址空间的传统登陆区域迁移的新构建应用程序和应用程序。

  • 通过第 7 层应用程序传送控制器公开的应用程序： 这些应用程序传送控制器包括 Azure 应用程序网关或非Microsoft网络虚拟设备（NVA）。 仅应用程序传送控制器的终结点必须能够从登陆区域外的客户端访问。 因此，应用程序传递控制器是唯一必须驻留在可路由子网中的前端组件。

  • 通过 Azure 负载均衡器公开的应用程序： 如果应用程序使用内部 Azure 负载均衡器，负载均衡器后端池中的虚拟机必须驻留在可路由的子网中。 可以将所有其他组件部署到非路由子网。

下图显示了这些模式：

  • 登陆区域 A 托管通过应用程序传送控制器公开的三层 Web 应用程序，这是可路由子网中唯一的组件。

  • 登陆区域 B 托管通过内部 Azure 负载均衡器公开的三层应用程序。

显示了如何在具有可路由和不可路由地址空间的登陆区域中部署应用程序的示意图。

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

出站依赖项

应用程序的后端组件不需要接受来自公司网络的入站连接。 但是，他们可能需要建立与其登陆区域外部节点的连接。 典型示例包括域名系统（DNS）解析、与 Active Directory 域服务（AD DS）域控制器的交互，以及访问其他登陆区域或共享服务（例如日志管理或备份系统）中的应用程序。

当非路由子网中的资源需要发起与其登陆区域外的终结点的连接时，这些连接必须使用可路由 IP 地址后面的源 NAT (SNAT)。 因此，必须在每个登陆区域的可路由子网中部署支持 NAT 的 NVA。 下图显示了此配置。

此图显示了自定义路由表如何将流量转发到 SNAT 设备。

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

不可路由子网 必须使用自定义路由表，该表将发往登陆区域外部的所有流量转发到支持 NAT 的 NVA。 在上图中，范围 10.57.0.0/16 是非路由的，而其中 10.0.0.0/8 的其他范围是可路由的。 每个非路由子网的自定义路由表必须包含以下用户定义的路由（UDR）。

目的地 下一跳类型 下一跃点 IP 地址
10.0.0.0/8 VirtualNetworkAppliance <支持 NAT 的分支 NVA IP 地址>

虚拟网络的系统路由表已经包含针对不可路由10.57.0.0/16范围内目标的系统路由。 无需为该范围内的流量定义 UDR。

可路由子网（包括承载支持 NAT 功能的 NVA 的子网）必须使用自定义路由表，以将流量转发到落地区域之外，通常转发到中心虚拟网络中的 NVA。 这些 NVA 在分支之间路由流量。 这些中心 NVA 不执行 NAT 操作。 在上图中，每个可路由子网的自定义路由表必须包含以下 UDR。

目的地 下一跳类型 下一跃点 IP 地址
10.0.0.0/8 VirtualNetworkAppliance <中心路由器/防火墙 IP 地址>
10.0.0.0/24 VirtualNetworkAppliance <中心路由器/防火墙 IP 地址>

目标为 10.0.0.0/24 的第二个 UDR 可确保连接到枢纽虚拟网络中的资源时，通过枢纽防火墙进行路由。 某些应用程序可能需要更多 UDR。 如果登陆区域中的虚拟机需要通过通常托管在中心的 NVA 进行 Internet 访问，则还必须定义默认路由。0.0.0.0/0

注释

支持通过 NAT 进行 Client-to-AD DS 域控制器的通信。 通过 NAT 进行域控制器到域控制器的通信尚未经过测试，并且不受支持。 有关详细信息，请参阅 Windows Server Active Directory 通过 NAT 的支持边界。 建议将 Windows Server Active Directory 域控制器部署到可路由的子网。

可以使用 Azure 防火墙或非Microsoft NVA 作为支持 NAT 的设备。 以下部分介绍这两个选项。 无法使用 Azure NAT 网关，因为它仅支持对面向互联网的流量进行 SNAT。

通过 Azure 防火墙实现 SNAT

需要确定低复杂性和最低管理优先级时，Azure 防火墙提供了最佳解决方案，为源自非路由子网的连接实现 SNAT。 Azure 防火墙提供以下优势：

  • 完全托管的生命周期
  • 内置的高可用性
  • 根据流量自动缩放

使用 Azure 防火墙时，请考虑以下因素：

  • 在自己的名为 AzureFirewallSubnet 的保留子网中部署 Azure 防火墙，该子网必须使用可路由的地址空间。

  • 某些 Azure 防火墙 SKU 或配置可能需要第二个保留子网进行防火墙管理。 管理子网不需要可路由的地址空间。

  • Azure 防火墙具有三个不同的 SKU。 SNAT 不是资源密集型的，因此请从基本 SKU 开始。 对于从非路由子网生成大量出站流量的登陆区域，请考虑使用标准 SKU。

  • 配置 Azure 防火墙，并将“ 执行 SNAT ”选项设置为 “始终”。 每个实例都将其非特权端口用于 SNAT。 若要配置 Azure 防火墙以在所有接收的连接上实现 SNAT，请执行 SNAT 配置步骤。

  • 将所有非路由子网与自定义路由表相关联，该表将发往登陆区域外部的所有流量转发到防火墙的专用 IP 地址。

下图显示了一个中心辐射型网络，其中每个分支使用 Azure 防火墙为来自非路由子网的连接提供 SNAT。

显示 SNAT 实现如何使用 Azure 防火墙的图表。

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

通过非Microsoft NVA 实现 SNAT

可以在 Azure 市场中找到具有 NAT 功能的非Microsoft NVA。 如果要求超过 Azure 防火墙可以支持的内容，请考虑使用非Microsoft NVA。 例如，可能需要以下功能：

  • 对 NAT 池的精细控制

  • 自定义 NAT 策略，例如，可能需要对不同的连接使用不同的 NAT 地址

  • 对横向缩减和横向扩展的精细控制

使用非Microsoft NVA 时，请考虑以下因素：

  • 部署至少具有两个 NVA 的群集，以确保高可用性。

  • 使用标准 SKU Azure 负载均衡器将非路由分支虚拟网络的连接分配到 NVA。 无论目标端口如何，所有连接都必须使用 SNAT，因此应使用 高可用性负载均衡规则，也称为 任何端口负载均衡规则。

  • 在支持 NAT 的 NVA 的单臂和双臂配置之间进行选择。 单臂配置更为简单，通常推荐使用。

下图显示了如何使用非 Microsoft NVA 在中心辐射型网络拓扑中实现 SNAT。

显示了使用非 Microsoft NVA 实现的 SNAT 的示意图。

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

将方法 1 与 Azure 虚拟 WAN 配合使用

Azure 虚拟 WAN 不支持子网对等互连。 因此，无法在基于虚拟 WAN 的中心辐射型网络中创建具有非路由子网的登陆区域虚拟网络。 但是，对于每个登陆区域，仍可使用两个对等互连的虚拟网络来应用方法 1 的基本原则。

  • 将可路由地址空间分配给第一个虚拟网络，并将其连接到虚拟 WAN 中心。

  • 为第二个虚拟网络分配一个非路由地址空间，并将其与可路由虚拟网络对等互连。

下图显示了生成的拓扑。

展示使用两个对等互连虚拟网络的实现方案的示意图。

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

此方法不会限制登陆区域中的连接。 登陆区域中的两个虚拟网络是直接对等互连的，因此，无论资源是驻留在可路由虚拟网络还是非路由虚拟网络中，都可以相互连接。 但是，只有可路由虚拟网络中的资源才能连接到登陆区域外部的资源。

从路由的角度来看，以下配置没有区别：

  • 同一虚拟网络中的可路由子网和非路由子网（在上一部分介绍了传统中心辐射网络）

  • 直接对等互连的虚拟网络（本部分介绍基于虚拟 WAN 的中心辐射型网络）

因此，在基于虚拟 WAN 的网络中，以下指南适用：

  • 可以使用前面部分所述的相同注意事项跨可路由和非路由子网分发应用程序组件。

  • 可以使用支持 NAT 的 NVA 在可路由子网中管理出站依赖项。

专用链接 使虚拟网络中的客户端能够使用不同的虚拟网络中的应用程序，而无需配置第 3 层连接，例如虚拟网络对等互连或虚拟网络到虚拟网络 VPN。 这两个虚拟网络可以使用重叠的 IP 地址范围。 Azure 以透明方式处理所需的 NAT 逻辑。 此方法适用于传统的中心辐射型网络和基于虚拟 WAN 的网络。

若要通过专用链接公开应用程序，请执行以下步骤：

  1. 使用标准 SKU 将应用程序的终结点添加到内部 Azure 负载均衡器的后端池。

  2. 将负载均衡器的前端 IP 地址与 专用链接服务资源相关联。

  3. 在客户端上，创建 专用终结点资源 并将其与服务器端专用链接服务相关联。

若要使用应用程序，客户端连接到专用终结点。 Azure 以透明方式将连接路由到与相应专用链接服务关联的负载均衡器前端 IP 地址。

可以使用专用链接通过将两个虚拟网络分配到每个登陆区域来帮助缓解 IPv4 耗尽：

  • 具有可路由地址空间的虚拟网络，连接到企业网络

  • 一个独立虚拟网络，该虚拟网络具有任意选择的地址空间，甚至可能与公司网络的地址空间重叠

部署在隔离虚拟网络中公开其终结点的应用程序和专用链接服务。 在可路由的虚拟网络中部署连接到这些服务的专用终结点。

下图显示了两个使用大型地址空间 10.0.0.0/16的登陆区域，这些空间与企业网络的地址空间重叠。 每个登陆区域将此空间分配给隔离的虚拟网络。 应用程序部署在独立分支虚拟网络中并与专用链接服务相关联。

此图显示了使用专用链接服务公开在隔离虚拟网络中部署的应用程序的登陆区域拓扑。

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

企业网络中的客户端（包括其他登陆区域中的客户端）通过与专用链接服务关联的专用终结点使用应用程序。 下图显示了如何建立这些连接。

此图显示了使用专用链接服务公开在隔离虚拟网络中部署的应用程序的登陆区域拓扑，并演示如何建立连接。

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

隔离虚拟网络中的应用程序无法启动与企业网络中终结点的连接。 因此，方法 2 最适合不同登陆区域中的应用程序独立运行且不依赖于企业网络中的系统的方案。 但是，当隔离虚拟网络中的应用程序需要访问其登陆区域之外的特定终结点时，仍可以应用此方法。

下图显示了专用链接服务如何使登陆区域 A 中隔离虚拟网络中的应用程序能够同时使用中心虚拟网络中的共享服务，以及登陆区域 B 中的应用程序终结点。

显示使用专用链接服务的外部依赖的体系结构示意图。

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

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

  • 费德里科·盖里尼 |高级云解决方案架构师 EMEA 技术主管 Azure 网络
  • Khush Kaviraj | 云解决方案架构师
  • Jack Tracey | 高级云解决方案架构师

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤