Azure虚拟网络路由最佳实践

联蔚盘云

已于 2024-04-19 15:04:52 修改

阅读量599

点赞数 24

文章标签： azure 网络安全

于 2024-04-18 16:54:09 首次发布

本文链接：https://blog.csdn.net/weixin_42196283/article/details/137927931

版权

在今天的企业网络架构设计中，连接云端和地面网络常采用ExpressRoute或VPN等技术。为了保障网络安全，我们通常需要让所有的网络流量通过防火墙。这样做不仅可以对流量进行严格的审查，确保安全，还可以进行SSL解密等操作，以便深入监控和管理网络流量。此外，根据不同的业务需求，我们还需要为不同的云端子网和地面网络设计精细的路由策略。本文档将通过分析不同的网络布局场景，帮助我们设计出既安全又高效的网络路由方案，从而降低维护成本，确保业务流畅运行。

具体应用场景如下：

场景1：在Hub-Spoke架构中，同一Spoke虚拟网络的同一子网内的虚拟机（VM）互相访问时，不需要通过Hub的防火墙进行审计。但如果是不同子网内的VM互相访问，则必须通过防火墙进行审计。
场景2：同样在Hub-Spoke架构中，虽然同一子网内的VM互访不需防火墙审计，但不同Spoke虚拟网络间的多数子网内VM互访需要通过防火墙，少数互访可不经过防火墙，这样做可以减少网络延迟。
场景3：在Hub-Spoke结合本地数据中心（IDC）的架构中，除了保持前两个场景的规则外，来自不同Spoke虚拟网络子网的VM与本地IDC间的互访也遵循同样原则，即大多数情况需经过防火墙审计。
场景4：当所有Spoke间的VM互访都需要经过防火墙时，我们还需确保这种设置不会影响到VM之间正常的出站访问，尤其是当涉及到必须通过固定出站地址以满足第三方服务的白名单要求时。

主要依赖的网络服务：

Vnet — 虚拟网络
Subnet — 虚拟网络子网
UDR — User Define Routings用户自定义路由
NVA FW — 防火墙(Ingress = 10.0.1.1)
ER — ExpressRoute专线
ER GW — ExpressRoute虚拟网络网关
RT — Route Table路由表
IDC — On-prem本地网络(172.16.0.0/16，172.17.0.0/16)
Peerings — 虚拟网络对等互联
Hub — 中心网络区域
Spoken — 业务网络区域
Load Balance — 四层标准内部负载均衡
NAT GW — NAT网关

====场景1：

背景需求： 在同一虚拟网络 (VNet) 内，需要实现不同子网间的流量通过防火墙 (FW) 路由，而同一子网内的流量则不通过防火墙直接交互。这样的配置旨在强化安全性同时优化网络流量管理。

配置方案示例： 以 Vnet1/Subnet1 的路由表 RT 11 为例，我们对地址范围 10.1.0.0/16 设置用户定义路由 (UDR)，指向防火墙的入口接口。此路由优先级高于默认虚拟网络路由，将原本指向虚拟网络的流量导向防火墙，从而覆盖并使默认的 10.1.0.0/16 路由失效。此外，针对每个子网，我们分别设置以下路由以实现细粒度的流量控制：

跨子网访问（通过防火墙）：地址前缀 10.1.0.0/16，下一跳类型为网络虚拟设备 (NVA)，下一跳 IP 为防火墙 IP。
同子网内部访问（不经过防火墙）：地址前缀 10.1.1.0/24，下一跳类型为虚拟网络。

优势： 该配置极大简化了大规模虚拟网络环境中的路由管理。在含有多个子网的环境下，传统需为每个子网间互相配置复杂的过防火墙路由。本方案通过设定三条基本路由规则，即可实现全网络的高效流量控制，显著降低运维成本。

No.	Source	State	Address Prefixes	Next Hop Type	Next Hop IP Address	User Defined Route Name
1	Default	Invalid	10.1.0.0/16	Virtual network
2	User	Active	10.1.0.0/16	Virtual appliance	10.0.1.1	RT_InsideVnet1
3	User	Active	10.1.0.0/24	Virtual network		RT_Local

====场景2：

背景需求： 在两个通过 peering 关系连接的虚拟网络之间，大部分子网间通信需要通过防火墙 (FW) 进行安全过滤，以确保网络交互的安全性。然而，某些特定子网间，如 Vnet1 的 Subnet1 与 Vnet2 的 Subnet1，需要不经过防火墙，直接通过peering（system routing）通信

配置方案示例(无法实现)：

Vnet1/Subnet1 的路由配置 (RT 11)：
- 针对 Vnet2 的整体流量安全管理：将地址前缀 10.2.0.0/16 的流量指定下一跳为网络虚拟设备 (NVA) 防火墙。这一配置覆盖了默认路由（如路由表 RT 1 中第四条默认路由），使其变为无效，从而增强了跨网络的安全控制。
- 对 Vnet2/Subnet1 的无防火墙访问：无法通过更精细的用户定义路由 (UDR) 实现，如 RT 1 中第六条路由所示，虽然/24 子网掩码的具体性高于 /16，但路由表下一条中是没有Vnet peering这个选项，只有Virtual Network，如果配置了Vnet，实际路由表里体现出的下一条是None，也就是Virtual Vnet这个service tag在此场景只包含本Vnet，不包含Peering Vnet，固无法实现
Vnet2/Subnet1 的路由配置 (RT 21)：
- 针对 Vnet1 的整体流量安全管理：设置地址前缀 10.1.0.0/16 的路由，下一跳指向 NVA 防火墙，以确保数据流的全面安全。
- 对 Vnet1/Subnet1 的无防火墙访问：同理可得无法实现

RT 1

No.	Source	State	Address Prefixes	Next Hop Type	Next Hop IP Address	User Defined Route Name
1	Default	Invalid	10.1.0.0/16	Virtual network
2	User	Active	10.1.0.0/16	Virtual appliance	10.0.1.1	RT_InsideVnet1
3	User	Active	10.1.0.0/24	Virtual network		RT_Local
4	Default	Invalid	10.2.0.0/16	Virtual peering
5	User	Active	10.2.0.0/16	Virtual appliance	10.0.1.1	RT_PeeredVnet2
6	User	Active	10.2.1.0/24	Virtual Network（下一条会变成None） Virtual peering(无法配置)

RT 2

No.	Source	State	Address Prefixes	Next Hop Type	Next Hop IP Address	User Defined Route Name
1	Default	Invalid	10.2.0.0/16	Virtual network
2	User	Active	10.2.0.0/16	Virtual appliance	10.0.1.1	RT_InsideVnet2
3	User	Active	10.2.1.0/24	Virtual network		RT_Local
4	Default	Invalid	10.1.0.0/16	Virtual peering
5	User	Active	10.1.0.0/16	Virtual appliance	10.0.1.1	RT_PeeredVnet1
6	User	Active	10.1.1.0/24	Virtual Network（下一条会变成None） Virtual peering(无法配置)

配置方案示例(可以实现)：

Vnet1/Subnet1 的路由配置 (RT 11)：
- 针对 Vnet2 的整体流量安全管理：将地址前缀 10.2.0.0/16 的流量指定下一跳为网络虚拟设备 (NVA) 防火墙，需拆分Vnet1不同子网到Vnet2不同子网分别做指向NVA FW路由
- 若Vnet1/Subnet1到Vnet2/Subnet1不需要经过NVA FW，则不需要做指向NVA FW的路由，依靠Default Vnet Peering系统路由即可通信
Vnet2/Subnet1 的路由配置 (RT 21)：
- 针对 Vnet1 的整体流量安全管理：设置地址前缀 10.1.0.0/16 的路由，需拆分Vnet2不同子网到Vnet1不同子网分别做指向NVA FW路由，作为回包路由
- Vnet2/Subnet1到Vnet1/Subnet1不需要经过NVA FW，依靠系统路由回包即可

结论：通常情况下，我们会要求两个不同spoken vnet之间（子网之间）都经过Hub NVA FW通信，但此场景只能两个Vnet之间1对1的subnet之间做指向NVA FW的路由，无法做缺省配置，因为UDR路由表中只能定义Virtual Network作为下一条，无法定义Vnet peering，但配置了Virtual Network作为下一条后，路由表实际显示是None，无法与peering vnet通信，所以无法实现此场景，但可以用缺省配置实现大部分Vnet之间子网通过Vnet Peering互访，极少部分Subent之间通过NVA FW互访。

====场景3：

需求1：云上与本地IDC之间访问的时候，大多数虚拟网络子网访问IDC网络经过FW再经过ExpressRoute，个别有某个子网访问特定的IDC网段不经过FW，只经过ExpressRoute访问，假设Vnet1/subnet1访问IDC 1网段不经过FW，访问IDC 2网段经过FW，其余网段互访都需要经过FW

（开启Propagate gateway routes时) 配置方案：
- Vnet1/subnet1 路由表RT 11：
  - 访问IDC地址段1不经过FW: 无需额外配置，BGP Default路由自动宣告到Vnet 1，靠宣告路由即可到达ExpressRoute GW而不去FW
  - 访问IDC地址段2经过FW: 172.17.0.0/16 Next Hop: NVA FW
- Vnet1/subnet2以及Vnet2所有subnets 路由表：
  - 访问IDC两个地址段：172.16.0.0/16 和 172.17.0.0/16 Next Hop: NVA FW
- Gateway Subnet 路由表RT GW：
  - - IDC地址段1回包Vnet1/subnet1：无需额外配置，靠Vnet Peering可回包
    - IDC地址段2回包Vnet1/subnet1：此条无法实现，因为Azure路由表无法针对原地址筛选路由流量，如配置去往Vnet1/subnet1的回包经过FW，会影响第一条，即Vnet/subnet1无法从GW直接收到回包，回包会变为从GW发回，异步路由导致无法通信
    - IDC地址段2回包Vnet1/subnet2以及Vnet2所有subnets：无需额外配置，靠Vnet Peering可回包
（关闭Propagate gateway routes时) 配置方案：同理可得，也无法实现

结论：Spoke跟IDC之间，无法实现一个subnet跟特定IDC网段之间是否经过FW（原因是路由表上无法配置源地址，从IDC回来的数据包在GW路由表上无法按IDC网段区分）

需求2：云上与本地IDC之间访问的时候，大多数虚拟网络子网访问IDC网络经过FW再经过ExpressRoute，个别有某个子网访问特定的IDC网段不经过FW，只经过ExpressRoute访问，假设Vnet1/subnet1访问所有IDC网段都不经过FW，其余网段互访都需要经过FW
（开启Propagate gateway routes时) 配置方案：
- Vnet1/subnet1 路由表RT 11：
  - 访问IDC所有地址段：无需额外配置，BGP路由自动宣告给Vnet/subnet1
- Vnet1/subnet2以及Vnet2所有subnets 路由表：
  - 访问IDC所有地址段：172.16.0.0/16 和 172.17.0.0/16 Next Hop: NVA FW
- IDC所有网段路由表：无需额外配置，开启PGR时Azure会自动宣告BGP Vnet网段到本地IDC
- Gateway Subnet 路由表RT GW：
  - IDC所有地址段回包Vnet1/subnet1：无需额外配置，靠Vnet Peering可回包
  - IDC所有地址段回包Vnet1/subnet2以及Vnet2所有subnets：Next Hop: NVA FW，之后由FW回包

（关闭Propagate gateway routes时) 配置方案：
- Vnet1/subnet1 路由表RT 11：
  - 访问IDC所有地址段：172.16.0.0/16 和 172.17.0.0/16 Next Hop: VirtualNetwork GW
- Vnet1/subnet2以及Vnet2所有subnets 路由表：
  - 访问IDC所有地址段：172.16.0.0/16 和 172.17.0.0/16 Next Hop: NVA FW
- IDC所有网段路由表：
  - 访问Vnet1和Vnet2所有地址段： Next Hop: IDC Edge Route （本地需配置往Azure网段路由发往ExpressRoute Private Peering Tunnel即可）
- Gateway Subnet 路由表RT GW：
  - IDC所有地址段回包Vnet1/subnet1：无需额外配置，靠Vnet Peering可回包
  - IDC所有地址段回包Vnet1/subnet2以及Vnet2所有subnets：Next Hop: NVA FW，之后由FW回包

结论：可以实现，因为只有Vnet1/subnet1与本地IDC网段之间只经过ExpressRoute，而不经过FW，其余网段互访，去包回包都可通过UDR改变流量指向，使其经过FW通信，不会产生异步路由

====场景4：

需求1：在所有Spoken Vnet虚拟网络之间无对等链接的情况下，确保所有出站流量通过指定的固定防火墙IP进行，同时根据业务需求防止Spoken虚拟网络之间的互相访问。

配置方案：
- Vnet1/subnet1 路由表RT 11：
  - 访问Internet时经过FW: 0.0.0.0/0 Next Hop: Load Balance Front-end IP
- Vnet2/subnet1 路由表RT 21：LB配置：后端为Hub NVA FW
  - 访问Internet时经过FW: 0.0.0.0/0 Next Hop: Load Balance Front-end IP
- NVA FW 路由表：0.0.0.0 Next Hop：Virtual Network

假设Vnet1/subnet1里VM1访问Vnet2/subnet2里VM2,此时流量：

VM1 >> (Subnet1 Gateway) >> LB Front-end >> LB Back-end(Hub NVA FW) >> (Subnet2 Gateway) >> VM2 >> (Subnet2 Gateway) >> LB Front-end >> LB Back-end(Hub NVA FW) >> (Subnet1 Gateway) >> VM1

异步路由导致回包异常，无法访问，从而阻断VM1与VM2之间访问，同理可得虚拟网络Vnet1与虚拟网络Vnet2之间所有VM均无法互访

需求2：在所有Spoken Vnet虚拟网络之间无对等链接的前提下，除确保固定防火墙出站IP访问外，还需实现对应业务之间的相互访问能力。

配置方案：
- Vnet1/subnet1 路由表RT 11：
  - 访问Internet时经过FW: 0.0.0.0/0 Next Hop: NVA FW
- Vnet2/subnet1 路由表RT 21：LB配置：后端为Hub NVA FW
  - 访问Internet时经过FW: 0.0.0.0/0 Next Hop: NVA FW
- NVA FW 路由表：0.0.0.0 Next Hop：Virtual Network

假设Vnet1/subnet1里VM1访问Vnet2/subnet2里VM2,此时流量：

VM1 >> (Subnet1 Gateway) >> Hub NVA FW >> (Subnet2 Gateway) >> VM2 >> (Subnet2 Gateway) >> Hub NVA FW >> (Subnet1 Gateway) >> VM1

去包回包是相同设备发出，不会产生异步路由，所以可以互访，在这个基础上，如要实现不同业务虚拟网络Vnet访问，部分子网过NVA FW互访，部分子网基于虚拟网络对等peering互访，请参考场景2

需求3：在所有Spoken Vnet虚拟网络之间没有任何peering对等链接的情况下，既保证所有虚拟网络Vnet业务VM固定防火墙出站IP访问，又可以让部分特殊子网可以访问其他子网，但其他子网无法访问特殊子网，如Vnet1/subnet1为Application Web子网，Vnet2/subnet2为Application DB子网，我们只允许Web子网主动访问DB子网，但不允许DB子网主动访问Web子网。

配置方案：
- Vnet1/subnet1 路由表RT 11：
  - 访问Internet时经过FW: 0.0.0.0/0 Next Hop: NVA FW
- Vnet2/subnet1 路由表RT 21：
  - 访问Internet时经过FW: 0.0.0.0/0 Next Hop: Load Balance Front-end IP
- LB配置：后端为Hub NVA FW
- NVA FW 路由表：0.0.0.0 Next Hop：Virtual Network

假设Vnet1/subnet1里VM1访问Vnet2/subnet2里VM2,此时流量：

Web子网到DB子网：VM1 >> (Subnet1 Gateway) >> Hub NVA FW >> (Subnet2 Gateway) >> VM2 >> (Subnet2 Gateway) >>LB Front-end >> LB Back-end(Hub NVA FW) >> (Subnet1 Gateway) >> VM1

DB子网到Web子网：VM2 >> (Subnet2 Gateway) >> LB Front-end >> LB Back-end(Hub NVA FW) >> (Subnet1 Gateway) >> VM1 >> (Subnet1 Gateway) >> Hub NVA FW >> (Subnet2 Gateway) >> VM2

后者异步路由，无法主动发起访问，因为DB子网发起的数据包无法从LB回给Web子网，但前者可以访问，因为Web子网发包到DB子网，Next Hop是NVA FW，经过一系列网路，数据包最后也是从NVA FW回给Web子网的，所以可以访问。

联蔚盘云

关注

24
点赞
踩
14

收藏

觉得还不错? 一键收藏
2
评论
Azure虚拟网络路由最佳实践

后者异步路由，无法主动发起访问，因为DB子网发起的数据包无法从LB回给Web子网，但前者可以访问，因为Web子网发包到DB子网，Next Hop是NVA FW，经过一系列网路，数据包最后也是从NVA FW回给Web子网的，所以可以访问。在含有多个子网的环境下，传统需为每个子网间互相配置复杂的过防火墙路由。去包回包是相同设备发出，不会产生异步路由，所以可以互访，在这个基础上，如要实现不同业务虚拟网络Vnet访问，部分子网过NVA FW互访，部分子网基于虚拟网络对等peering互访，请参考场景2。
复制链接

扫一扫