<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] 在 AWS Cloud WAN 中启用第三方设备的带外管理
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
本解决方案针对AWS Cloud WAN中第三方安全设备的外部管理（Out-of-Band Management）挑战，提供方法以分离数据平面和管理流量。核心内容包括通过AWS Cloud WAN服务插入实现流量检查，同时确保管理访问安全。**AWS Cloud WAN** 旨在帮助组织构建和管理跨多个AWS区域的全球网络，解决的问题是第三方设备默认无法直接访问进行管理任务，如软件更新或配置变更。适用场景包括需要网络隔离的安全架构，特别是在多区域部署中，行业需求聚焦于云安全和网络管理的效率提升。背景信息显示，此方案基于**AWS Cloud WAN** 的构建块（如核心网络、段和网络功能组），结合**Gateway Load Balancer (GWLB)** 或**Multi-VPC ENI**，以提升整体灵活性。
## 实施步骤
1. **准备阶段**
- 确保熟悉**AWS Cloud WAN** 构建块、网络功能组和**GWLB** 架构。
- 在检查**VPC** 中部署第三方设备，确保数据平面**ENI** 用于流量检查，管理**ENI** 用于行政访问。
2. **方法选择和实施**
- **方法1（支持GWLB的设备）**：
- 创建两个**VPC**：一个检查**VPC** 附加到**NFG** 用于数据流量，另一个管理**VPC** 用于行政访问。
- 配置**GWLB** 端点在检查**VPC** 中转发数据流量，使用**PrivateLink** 和**GENEVE** 隧道隔离流量。
- 连接管理**VPC** 到特定段，确保管理路由自动传播。技术原理在于**GWLB** 通过隧道机制避免依赖**VPC** 路由，实现高效流量转向。
- **方法2（不支持GWLB的设备）**：
- 使用**Multi-VPC ENI** 特性，在同一AWS账户中为设备附加多个**ENI**。
- 检查**VPC** 托管数据平面**ENI**，管理**VPC** 托管管理**ENI**。
- 附加检查**VPC** 到**NFG**，管理**VPC** 到管理段，实现流量隔离。逻辑衔接是通过**ENI** 分离减少管理复杂度，避免数据平面干扰。
- **方法3（手动静态路由）**：
- 在同一**VPC** 中部署设备，并手动添加静态路由到检查**VPC** CIDR。
- 配置服务插入策略，确保段参与数据平面流量。
- 注意，此方法需手动维护路由，适用于简单场景，但不推荐。
3. **验证和迁移**
- 测试数据平面和管理流量流，确保无干扰。
- 对于迁移，支持从**AWS Transit Gateway** 到**AWS Cloud WAN**，通过保持防火墙部署一致性逐步切换。
## 方案客户价值
- **提升安全性和操作效率**：通过分离数据平面和管理流量，实现清晰的访问控制，减少管理风险，相比传统架构显著降低潜在的安全漏洞。
- **角色-based 管理**：允许安全团队管理防火墙**VPC**，网络团队管理检查端点，提高团队协作效率。
- **自动路由传播**：管理路由在相关段自动填充，_节省手动配置时间_，并支持多区域部署的扩展性。
- **迁移支持**：简化从**AWS Transit Gateway** 到**AWS Cloud WAN** 的迁移过程，减少中断，实现无缝过渡，与传统方案相比提升了灵活性。
- 在突发流量场景中，此方案通过**GWLB** 优化资源利用，但可能增加初始配置复杂度。
## 涉及的相关产品
- **AWS Cloud WAN**：用于构建全球网络和流量插入，提供核心网络和段管理，在方案中负责流量路由和服务插入。
- **AWS Gateway Load Balancer (GWLB)**：处理数据平面流量，通过端点和隧道机制实现高效检查，支持第三方设备集成。
- **Amazon EC2**：托管第三方安全设备实例，允许**ENI** 配置以分离数据和管理接口。
- **Multi-VPC ENI**：作为备选特性，用于不支持**GWLB** 的设备，实现跨**VPC** **ENI** 附加。
- **AWS Network Firewall**：可选组件，用于示例迁移，执行流量检查策略。
## 技术评估
本解决方案的技术先进性体现在通过**GWLB** 和**Multi-VPC ENI** 实现自动化路由和流量隔离，提升了云网络的可扩展性和安全性。可行性高，适用于多区域企业环境，优势包括高效的流量转向机制（如**GENEVE** 隧道减少路由依赖）和角色分离增强合规性。然而，可能的限制是方法3（手动路由）在规模化时增加管理负担，且不支持**GWLB** 的设备可能面临兼容性挑战。总体上，该方案在保持数据平面高效的同时，确保管理访问的可靠性，符合行业趋势向自动化网络管理转型，但在大规模组网中需关注路由配置的潜在复杂性。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 为 AWS Cloud WAN 中的第三方设备启用带外管理
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/enabling-out-of-band-management-for-third-party-appliances-in-aws-cloud-wan/](https://aws.amazon.com/blogs/networking-and-content-delivery/enabling-out-of-band-management-for-third-party-appliances-in-aws-cloud-wan/)
**发布时间:** 2025-05-28
**厂商:** AWS
**类型:** BLOG
---
## 引言
AWS Cloud WAN (AWS Cloud WAN) 使组织能够构建和管理跨多个 AWS 区域的全球网络。通过 AWS Cloud WAN 服务插入功能，您可以将安全设备集成到流量路径中，这些设备可以是 AWS 管理的（如 AWS Network Firewall），也可以是第三方解决方案，用于检查和控制网络段之间或出站到互联网的流量。
尽管 AWS Cloud WAN 简化了将安全设备插入流量路径的过程，但它也带来设计挑战：这些设备默认情况下无法直接访问，以进行管理任务如软件更新或配置更改。为解决此问题，许多部署需要带外 (Out-of-Band) 访问来管理设备。
本文探讨了为使用 AWS Cloud WAN 部署的第三方安全设备启用直接带外管理的方法，通过将数据平面与管理流量分离。
## 先决条件
在继续之前，您应熟悉以下概念：
- [AWS Cloud WAN](https://docs.aws.amazon.com/network-manager/latest/cloudwan/what-is-cloudwan.html) 构建块：核心网络、段、网络功能组 (Network Function Group) 和附件
- [AWS Cloud WAN 服务插入](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-policy-service-insertion.html)
- [AWS Gateway Load Balancer](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/) (GWLB) [检查架构](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-routing-enhancements-and-gwlb-deployment-patterns/)
## AWS Cloud WAN 和带外管理挑战
在 AWS 中部署第三方安全设备时，它们通常作为 [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2) 实例设置在检查 Amazon Virtual Private Cloud (Amazon VPC) 中。每个设备都有一个数据平面弹性网络接口 (Elastic Network Interface, ENI)，用于根据管理员配置的安全策略处理和检查流量。
出于管理目的，管理员使用协议如 SSH 或 HTTPS 连接到设备。这可以通过两种方式实现：
- 使用处理数据平面流量的同一 ENI。
- 使用专用于管理访问的单独管理 ENI。
然而，当托管设备的检查 VPC 附加到 AWS Cloud WAN 核心网络中的网络功能组 (NFG) 时，其 CIDR 范围不会自动在任何地方公布。这意味着两件事：
- 非直接指向检查 VPC 的数据平面流量可以穿过 VPC 进行检查（如在 AWS Cloud WAN 段之间或到互联网的流量）。
- 设备的管理接口（无论是在同一 ENI 或单独 ENI 上）无法从 VPC 外部自动访问，从而阻止直接管理访问。
图 1 显示了带有附加到 NFG 的检查 VPC 的 AWS Cloud WAN 架构。虽然数据平面流量正常工作，但 NFG 附件不会自动授予对设备管理接口的直接访问，因为检查 VPC 路由不存在于任何段中。
*图 1: 数据平面 ENI 和管理平面 ENI 在同一 VPC 中*
### 数据平面流量流程：
1. VPC A (10.1.0.0/16) 通过 AWS Cloud WAN 将流量发送到 VPC B (10.2.0.0/16)。
2. 在 AWS Cloud WAN 上启用了服务插入策略，以在段 A 和段 B 之间强制执行检查，通过将其发送到指定的检查 VPC。
- IP 数据包中的唯一源和目标是 VPC A 和 VPC B。检查 VPC 的 IP 范围 (172.16.0.0/16) 从未被使用。
3. 检查 VPC 托管所有 GWLB 基础架构，如端点和设备。要了解检查 VPC 中的流量流程，请参考上述先决条件参考。
### 管理流量流程：
4. VPC A (10.1.0.0/16) 尝试连接到第三方设备之一的管理接口 (172.16.0.0/16)。
- 来自 VPC 的流量可以到达 AWS Cloud WAN 核心网络，但段 A 没有到检查 VPC 的路由。附加到 NFG 的 VPC 的 CIDR 范围不会自动传播。
解决此挑战的最佳方式是将数据平面与管理流量分离。这种方法不仅提升了操作效率，还可以通过在不同 AWS 账户中托管设备来有效隔离它们，从而避免数据平面参与策略执行和检查。以下三种部署方法取决于设备的功能：
- **方法 1:** 支持 GWLB 的设备
- **方法 2:** 不支持 GWLB 的设备，使用 Multi-VPC ENI
- **方法 3:** 手动为检查 VPC 范围添加静态路由（包含以供完整性参考，但未分离数据平面和管理平面）
AWS 强烈推荐在可能时使用 GWLB 部署。
## 方法 1: 支持 GWLB 的设备架构
此方法实现了一个双 VPC 设计，将服务层和管理层分离。这种分离确保了在专用段中自动传播管理路由，同时保持高效的流量检查。图 2 显示了此方法：
### 检查 VPC:
- 附加到专用于流量检查的 AWS Cloud WAN NFG
- 使用 GWLB 端点进行数据平面流量引导
### 防火墙/管理 VPC:
- 托管 GWLB 并连接到 AWS Cloud WAN 段，用于安全设备的管理访问
- 托管 GWLB 和安全设备，从而为每个设备启用直接管理控制
*图 2: 使用 GWLB 与 AWS Cloud WAN 和服务插入部署带外管理*
### 数据平面流量流程：
1. VPC A (10.1.0.0/16) 通过 AWS Cloud WAN 将流量发送到 VPC B (10.2.0.0/16)。
2. 在 AWS Cloud WAN 上启用了服务插入策略，以在段 A 和段 B 之间强制执行检查，通过将其发送到指定的检查 VPC。
- IP 数据包中的唯一源和目标是 VPC A 和 VPC B。检查 VPC (172.16.0.0/16) 和管理 VPC (192.168.0.0/16) 的 IP 范围未在流量中使用。
3. 检查 VPC 仅托管 GWLB 端点，作为 GWLB 的数据平面扩展，并管理 VPC 中托管的设备。
4. GWLB 端点使用 AWS PrivateLink 转发数据平面流量到 GWLB。
- 从 GWLB 到第三方设备的数据平面流量位于 GENEVE 隧道中，从而不依赖于 VPC 路由。
### 管理流量流程：
5. VPC A (10.1.0.0/16) 尝试连接到第三方设备之一的管理接口 (192.168.0.0/16)。
6. 来自 VPC 的流量可以到达 AWS Cloud WAN 核心网络，并且段 A 有到管理 VPC 的路由。
7. 管理流量不会通过 GWLB。
段 A 用作示例，管理 VPC 可以连接到任何段。例如，您可以为带外管理创建专用段。
### 优势
- 在检查 (数据平面) 和管理访问之间实现清晰分离
- 启用基于角色的团队管理：安全团队管理防火墙 VPC，网络团队管理检查 VPC 端点
- 管理路由在相关段 (示例中的段 A) 中自动填充到所有 AWS 区域
### 额外优势: AWS Cloud WAN 迁移支持
此模型的另一个优势是简化了迁移到 AWS Cloud WAN 的过程。这可以通过使用纯 AWS Transit Gateway 模型或不带服务插入的 AWS Cloud WAN 来实现。
详细迁移过程记录在帖子 [迁移到 AWS Cloud WAN 多区域检查使用服务插入](https://aws.amazon.com/blogs/networking-and-content-delivery/migration-to-aws-cloud-wan-multi-region-inspection-using-service-insertion/) 中，使用 [AWS Network Firewall](https://aws.amazon.com/network-firewall/)。该帖子中记录的相同迁移步骤适用于第三方设备。在使用第三方解决方案时，保持单一防火墙部署，并将端点分布到各个检查 VPC。
图 3 显示了从 AWS Transit Gateway 到 AWS Cloud WAN 的迁移中间状态。中间阶段需要同时在 AWS Transit Gateway 和 AWS Cloud WAN 上提供检查。GWLB 使防火墙堆栈保持在单个 VPC 中，但可以将端点部署到不同的检查 VPC。
*图 3: AWS Transit Gateway 到 AWS Cloud WAN 迁移使用第三方设备: 中间状态*
检查 VPC 的 IP 范围可以重叠，因为它们未在数据平面转发中使用。这意味着您可以通过在检查 VPC 中使用相同范围来节省 IP 空间。GWLB 和 GWLB 端点会跟踪流量来源，以确保其返回相同路径。
## 方法 2: 不支持 GWLB 的设备
对于不支持 GWLB 的设备，[Multi-VPC ENI 附件](https://aws.amazon.com/about-aws/whats-new/2023/10/multi-vpc-eni-attachments/) 可以作为替代方案。此 AWS 功能允许您执行以下操作：
- 在一个 VPC 中为 EC2 实例启动主 ENI
- 在 **同一 AWS 账户** 中的另一个 VPC 中附加辅助 ENI
图 4 显示了此方法：
- 检查 VPC (附加到 AWS Cloud WAN NFG 段)：托管设备的数据平面 ENI 用于流量检查
- 管理 VPC (附加到管理段)：托管设备的管理 ENI，用于直接管理访问
此架构通过管理 ENI 分离管理访问，同时将数据平面流量隔离在检查 VPC 中，从而提升安全性。
*图 4: 使用 Multi-VPC ENI 无 GWLB 部署带外管理*
### 数据平面流量流程：
1. VPC A (10.1.0.0/16) 通过 AWS Cloud WAN 将流量发送到 VPC B (10.2.0.0/16)。
2. 在 AWS Cloud WAN 上启用了服务插入策略，以在段 A 和段 B 之间强制执行检查，通过将其发送到指定的检查 VPC。
- IP 数据包中的唯一源和目标是 VPC A 和 VPC B。检查 VPC (172.16.0.0/16) 和管理 VPC (192.168.0.0/16) 的 IP 范围未在流量中使用。
3. 检查 VPC 仅托管每个防火墙设备的数据平面 ENI。
### 管理流量流程：
4. VPC A (10.1.0.0/16) 尝试连接到第三方设备之一的管理接口 (192.168.0.0/16)。
5. 来自 VPC 的流量可以到达 AWS Cloud WAN 核心网络，并且段 A 有到管理 VPC 的路由。
我们仅显示单个防火墙设备。
此方法适合需要直接 ENI 管理但不支持 GWLB 集成的设备。
## 方法 3: 手动为检查 VPC 范围添加静态路由
这是最不推荐的方法，由于其缺点。我们包含它以供完整性参考。
如果您希望在同一 VPC 中使用数据平面流量和管理，同时使用 AWS Cloud WAN 的服务插入，则可以通过手动添加必要的静态路由来实现。
然而，这需要为每个托管第三方设备的检查 VPC 添加路由。它还不能提供数据平面和管理流量之间的清晰分离。
另一个缺点是它强制管理段也参与数据平面流量流程 (AWS Cloud WAN 服务插入策略)。如果没有此设置，则没有从 NFG 到管理段的返回路径。
图 5 显示了此设置的外观。
*图 5: 手动静态路由*
### 数据平面流量流程：
1. VPC A (10.1.0.0/16) 通过 AWS Cloud WAN 将流量发送到 VPC B (10.2.0.0/16)。
2. 在 AWS Cloud WAN 上启用了服务插入策略，以在段 A 和段 B 之间强制执行检查，通过将其发送到指定的检查 VPC。
- IP 数据包中的唯一源和目标是 VPC A 和 VPC B。检查 VPC (172.16.0.0/16) 的 IP 范围未在流量中使用。
3. 检查 VPC 接收流量并执行策略强制。
### 管理流量流程：
4. VPC A (10.1.0.0/16) 尝试连接到第三方设备之一的管理接口 (172.16.0.0/16)。
5. 来自 VPC 的流量可以到达 AWS Cloud WAN 核心网络，并且段 A 有到检查 VPC 的静态路由，该 VPC 也托管管理接口。
6. 返回流量仅在段 A 配置为使用服务插入进行其数据平面流程时有效。如果段 A 未在任何服务插入策略中配置，则没有返回路径，也没有办法在 NFG 中配置静态路由。
## 结论
网络检查是云安全架构的基本组成部分。本文概述了将第三方安全设备与 AWS Cloud WAN 集成的最佳实践，重点关注使用 [Gateway Load Balancer](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/) 或 [Multi-VPC ENI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/scenarios-enis.html) 的带外管理设计。这些解决方案有助于确保：
- 安全的管理平面访问
- 使用 GWLB 或 Multi-VPC ENI 的无缝数据平面集成
- 提高操作效率，同时保持安全态势
实施这些架构使组织能够自信地在 AWS Cloud WAN 环境中部署和管理第三方安全设备。
要了解更多关于此解决方案和 AWS Cloud WAN 的信息，请联系您的 AWS 账户团队。
## 作者介绍
### Joe Flanagan
Joe 是 Amazon Web Services 的资深网络专家解决方案架构师，支持全球账户。他利用超过 20 年的网络和安全经验，帮助客户设计可扩展、弹性且安全的 AWS 云环境。工作之外，他喜欢与家人一起在湖泊或海洋划船和露营。
### Tom Adamski
Tom 是专注于网络的首席解决方案架构师。他拥有超过 15 年的经验，在各种行业（如电信和互联网提供商到小型初创公司）构建网络和安全解决方案。他过去 6 年帮助 AWS 客户在 AWS 云中构建网络环境。在业余时间，Tom 喜欢在加利福尼亚海岸寻找冲浪波。
<!-- AI_TASK_END: AI全文翻译 -->