📚 课程目录第3章生产环境网络拓扑规划与实施

3. 生产环境网络拓扑规划与实施

生产环境的网络拓扑不是把几个 VNet 连起来就算完成，它决定了后续所有安全策略、路由行为和 DNS 解析的边界。在 Azure 中，主流做法有两种：Hub-Spoke 拓扑与 Virtual WAN 拓扑。Hub-Spoke 由客户自建 Hub VNet，把 Azure Firewall、网关、DNS 转发器等共享服务集中部署，各业务 Spoke VNet 通过 VNet Peering 接入 Hub；Virtual WAN 则由微软托管的虚拟枢纽承担中转，适合多区域、多分支、大规模互联场景。本节以 Hub-Spoke 为主线展开，因为它的路由、NSG、UDR 与 DNS 控制点最直观，也最容易在生产中落地。

一、地址空间与子网规划

规划的第一步是确定不重叠的地址空间。假设企业本地数据中心使用 10.0.0.0/16，那么 Azure 侧应避开该段。示例规划如下：Hub VNet 使用 10.10.0.0/16，其中 GatewaySubnet 取 10.10.0.0/27（专供 VPN/ExpressRoute 网关），AzureFirewallSubnet 取 10.10.1.0/26（Azure Firewall 强制要求 /26 或更大），AzureFirewallManagementSubnet 取 10.10.2.0/26（用于强制隧道模式下的管理流量），共享服务子网取 10.10.3.0/24，DNS 转发器子网取 10.10.4.0/28。业务 Spoke 分别使用 10.20.0.0/16、10.30.0.0/16，每个 Spoke 内再按应用层、数据层划分 10.20.1.0/24、10.20.2.0/24 等。

子网划分要预留增长空间，避免后期因地址不足而重建 VNet。GatewaySubnet 与 AzureFirewallSubnet 是 Azure 保留名称，不能改名，也不能把其他资源部署进去。Private Endpoint 建议单独划分子网，例如 10.20.3.0/24，便于用 NSG 统一控制对 PaaS 服务的访问。

二、NSG 与 UDR 的配合

NSG 控制“谁能访问谁”，UDR 控制“流量往哪里走”，两者必须配合。生产环境常见做法是：在 Spoke 子网上关联 NSG，只允许来自 Hub 共享服务或特定应用层的入站；同时在 Spoke 子网上关联路由表，把 0.0.0.0/0 以及 Spoke 间互访流量指向 Hub 的 Azure Firewall 私网 IP（示例为 10.10.1.4）。这样东西向流量也会经过防火墙检查，而不是在 Spoke 之间直接放行。

需要注意，VNet Peering 默认允许流量直连，UDR 的下一跳类型应选择 VirtualAppliance 并填写防火墙私网 IP。若使用网关传输，Spoke 到本地的流量可经 Hub 网关转发，但 Spoke 之间仍建议显式配置 UDR，避免绕过安全设备。NSG 规则要遵循最小权限，例如应用层子网只开放 443 到数据层，管理端口仅允许来自跳板机子网。

三、Azure Firewall 与 Private Endpoint

Azure Firewall 部署在 Hub 的 AzureFirewallSubnet 中，通过 DNAT 规则对外发布服务，通过网络规则和应用程序规则控制出站。生产环境通常启用策略模式，把规则集中到 Firewall Policy，便于跨订阅复用。Private Endpoint 则把 PaaS 服务（如 Storage、SQL、Key Vault）映射到 VNet 内的私网 IP，使流量不经过公网。创建 Private Endpoint 时选择目标子网，并绑定 Private DNS Zone，例如 privatelink.blob.core.windows.net，这样名称解析才会返回私网地址。

四、跨订阅安全网络连通实战

假设 Hub 在订阅 A，Spoke 在订阅 B，需要完成以下关键操作。首先在订阅 A 创建 Hub VNet 及子网，部署 Azure Firewall 和 DNS 转发器。然后在订阅 B 创建 Spoke VNet，并在 Hub 与 Spoke 之间建立双向 Peering。跨订阅 Peering 需要双方都有权限，且状态必须为 Connected。

# 示例：在 Spoke 子网关联路由表，强制流量经防火墙
az network route-table create -g rg-spoke-b -n rt-spoke-b
az network route-table route create -g rg-spoke-b --route-table-name rt-spoke-b \
  -n default-to-fw --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance --next-hop-ip-address 10.10.1.4
az network vnet subnet update -g rg-spoke-b --vnet-name vnet-spoke-b \
  -n app-subnet --route-table rt-spoke-b

接着在 Spoke 子网关联 NSG，放行来自 Hub 共享服务子网的流量。随后创建 Private Endpoint，并把它关联到 Hub 中的 Private DNS Zone。最后从 Spoke 内的一台 VM 测试：解析存储账户名称应返回 10.20.3.x 的私网地址，访问本地数据中心应经过防火墙并命中日志。判断连通是否成功，可以观察 Azure Firewall 的网络规则日志、NSG 的流日志以及 DNS 解析结果三处是否一致。

跨订阅 Peering 时，若一方使用经典网络或不同租户，需要确认订阅权限和资源提供程序已注册。Private DNS Zone 建议集中放在 Hub 订阅，通过跨订阅关联让各 Spoke 复用，避免每个 Spoke 各建一套导致解析不一致。

不要为了省事把 Spoke 子网的 UDR 指向 Internet 或直接放行所有端口。生产环境中，绕过防火墙的东西向流量往往是最难排查的安全隐患。所有跨 Spoke、跨本地和出公网的流量，都应经过 Hub 的统一检查点。

完成上述规划与实施后，网络拓扑应达到三个可验证的结果：地址空间无重叠且预留增长；Spoke 间与出站流量均经过 Azure Firewall；Private Endpoint 的 DNS 解析返回私网地址。这三条同时成立，才说明生产网络的基础连通与安全边界已经建立。