目标

• 了解基于 VPC 的中心和辐射模型背后的概念。
• 了解防火墙路由器和传输 VPC 环境的实现。
• 了解 VPC 入口和出口路由。
• 确定并 (可选) 解决非对称路由问题。
• 通过 Transit Gateway连接 VPC。

准备工作

本教程需要:

• terraform 以使用基础结构作为代码来供应资源，
• python 以 (可选) 运行 pytest 命令，
• 实现防火墙路由器将要求您 启用 IP 电子欺骗检查，
• 用于连接虚拟服务器的SSH密钥。 如果您没有 SSH 密钥，请遵循 指示信息 为 VPC 创建密钥。

请参阅 先决条件 以获取一些选项，包括用于轻松创建先决条件环境的 Dockerfile。

此外：

• 检查用户许可权。 请确保您的用户帐户具有足够的许可权来创建和管理本教程中的所有资源。 请参阅以下列表:
  • VPC 必需的许可权。
  • 创建 Transit Gateway 所需的许可权。
  • IP 电子欺骗检查所需的许可权。

IP 地址和子网布局

在此步骤中，您将供应 VPC 网络资源。 通过 设计 VPC 的寻址计划 进行精心规划，并使用非重叠的 CIDR 块。

首先由 VPC 划分 CIDR 空间是很有诱惑力的，但这会使路由变得复杂。 而是将可用性区域视为单个 CIDR 块，并将每个 VPC 视为使用其中的一片。

此图仅显示区域 1 的更详细信息。 其他区域中的子网大小和布局相同:

企业上方位于左侧，右侧为 IBM Cloud。 在 IBM Cloud 中，为简单的传输 VPC 和 Spoke 0 描述了单个专区。 请注意，CIDR 块不重叠，并且 VPC 都在每个专区中使用一个 CIDR 块:

• 本地 CIDR 为 192.168.0.0/16。
• 此 多专区区域 中的专区为 10.*.0.0/16。 第二个数字：1、2、3 是区域编号（显示为达拉斯/美国南部）：
  • 10.10.1.0.0/16、1 区、▓1、us-south-1。
  • 10.10.2.0.0/16、2 区、▓2、us-south-2。
  • 10.10.3.0.0/16、3 区、▓3、us-south-3。
• 传输 VPC 使用 CIDR 10.*.15.0/24:
  • 10.1.15.0/24，区域 1。
  • 10.2.15.0/24，区域 2。
  • 10.3.15.0/24，区域 3。
• 辐射 0 使用 10.*.0.0/24 或 CIDR:
  • 10.1.0.0/24，区域 1。
  • 10.2.0.0/24，区域 2。
  • 10.3.0.0/24，区域 3。
• 子网 CIDR 将 /24 进一步划分为 /26。

传输和辐射中的子网适用于不同的资源类型:

• 工作程序网络可访问的计算资源 VPC 实例，负载均衡器，Red Hat OpenShift等。 本教程演示了 VPC 实例。
• dns-第 2 部分中使用的 DNS Services 位置设备。
• vpe-在第二部分中使用的 VPE for VPC。
• fw-firewall-router VPC 实例 (仅传输中)。

供应 VPC 网络资源

1. 配套 GitHub Repository 具有用于实现体系结构的源文件。 在桌面 shell 中，克隆存储库:

   git clone https://github.com/IBM-Cloud/vpc-transit
   cd vpc-transit
   

2. config_tf 目录包含需要配置的配置变量。

   cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
   

3. 编辑 config_tf/terraform.tfvars，并使用该文件中的注释作为指南。

4. 由于按正确顺序安装每个层非常重要，并且本教程中的某些步骤将安装多个层，因此提供了 shell 命令 。/apply.sh。 以下内容将显示帮助:

   ./apply.sh
   

5. 您可以应用通过执行 ./apply.sh : :配置的所有层。 这些冒号是第一个 (或 config_tf) 和最后一个 (power_tf) 的速记。 -p 打印层:

   ./apply.sh -p : :
   

   此 URL 将类似于以下内容：

   directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
   

6. 如果您还没有，请获取 一个平台API密钥，并导出API密钥供Terraform使用：

   export IBMCLOUD_API_KEY=YourAPIKEy
   

7. 在此第一步中，适用于 config_tf，enterprise_tf，transit_tf，代言人 tf 和 transit_spoke_tgw_tf:

   ./apply.sh : transit_spoke_tgw_tf
   

已创建 VPC 和子网。 传输 VPC 和辐射 VPC 已通过供应的 Transit Gateway进行连接。 在浏览器中打开 虚拟私有云。 打开传输 VPC 并记下地址前缀和子网的 CIDR 块。 检查企业并对 VPC 进行讲话。 打开 Transit Gateway，然后单击 Transit Gateway 以查看 Transit 与辐射 VPC 之间的连接。

创建测试实例

供应 VPC 虚拟服务器实例 VSI 以测试网络连接。 测试实例将添加到企业中的每个工作程序子网 (每个专区一个)，传输和每个辐射。 如果使用 3 区域和 2 辐射的缺省配置，那么将供应 12 个实例。

1. 创建测试实例

   ./apply.sh test_instances_tf
   

可以启发您探索在 IBM Cloud 控制台中的每个步骤中创建的资源。 (可选) 打开 虚拟专用云。 在左侧单击 虚拟服务器实例，并注意到已创建的实例。

测试

本教程将一次添加一层通信路径。 pytest 测试套件将用于详尽测试通信路径。 到教程结束时，所有测试都将通过。

读者不需要使用 pytest 来验证结果。 遵循教程中的步骤，应用层，并信任教程中描述的结果。 创建 VPC 资源 (例如 VSI，子网和路由表) 后，读者仍可对其进行浏览。

每个 pytest 测试都将通过 SSH 连接到其中一个实例，并执行某种类型的连接测试，例如对其中一个其他实例执行 curl 命令。 缺省 SSH 环境用于登录到实例。 如果看到意外的测试结果，请尝试 pytest 故障诊断 部分。

1. 使用 -m (标记) 标志在套件中运行区域 1 curl 测试。 选择标有 curl，lz1 (左区域 1) 和 rz1 (右区域 1) 的测试。

   您的预期结果为: Connectivity within a VPC, like enterprise <-> enterprise will be 已通过. 运输和轮辐之间的连接将 通过。 来自企业的跨 VPC-> 传输或辐条将为 FAILED。

   pytest -m "curl and lz1 and rz1"
   

   以下是输出示例：

   root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1"
   ===================================================== test session starts ======================================================
   platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python
   cachedir: .pytest_cache
   rootdir: /usr/src/app
   configfile: pytest.ini
   testpaths: py
   plugins: xdist-3.5.0
   collected 36 items / 20 deselected / 16 selected
   
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                                   [  6%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED                                      [ 12%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED                                       [ 18%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED                                       [ 25%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED                                      [ 31%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                                         [ 37%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED                                          [ 43%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED                                          [ 50%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 56%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED                                          [ 62%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 68%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED                                           [ 75%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 81%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED                                          [ 87%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 93%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED                                           [100%]
   
   =================================================== short test summary info ====================================================
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False
   ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
   

对网络配置的更改可能需要几次测试运行才能使底层 VPC 网络系统保持一致。 如果您最初未看到预期结果，请准备再次运行测试几次。

r- 和 l- 代表 r ight 和 l eft。 名称的中间部分标识 enterprise，Transit，spoke0，spoke1，... z1，z2... 标识区域。 测试将通过 SSH 连接到左侧实例。 在左侧实例上，尝试连接到右侧实例。 test_curl 在左侧实例上执行到右侧实例的 curl 连接。

总之，测试 test_curl[l-enterprise-z1 -> r-transit-z1] 将:

1. 通过 SSH 连接到企业区域 1 中的测试实例。
2. 执行 curl 到传输区域 1。
3. 断言返回字符串包含用于标记通过或失败的传输区域 1 的标识。

配套 GitHub Repository 中的 README.md 具有更多详细信息和源代码。

通过 Direct Link 和 Transit Gateway 将企业连接到运输

使用 Transit Gateway供应 IBM Cloud® Direct Link。

IBM Cloud® Direct Link 是用于将企业连接到 IBM Cloud的高速安全数据路径。 在本教程中，Transit Gateway 用于分发。 对于本地连接，可选择使用 Transit Gateway。

本教程中的企业是使用另一个 VPC 模拟的。 通过 Transit Gateway 连接此模拟企业 (实际上是另一个 VPC) 将确保体验非常接近使用 Direct Link时的体验。

1. 应用 enterprise_link_tf 层:

   ./apply.sh enterprise_link_tf
   

2. 使用 -m (标记) 标志在我的套件中运行区域 1 curl 测试。 选择标有 curl，lz1 (左区域 1) 和 rz1 (右区域 1) 的测试。

   您的预期结果为: Connectivity within a VPC, transit <-> spoke(s), enterprise <-> transit, spoke(s) <-> spoke(s) pass but enterprise <-> spoke(s) fail.

   pytest -m "curl and lz1 and rz1"
   

通过 Transit NFV Firewall-Router 将企业连接到辐射

The incentive for a transit VPC for enterprise <-> cloud traffic is typically to route, inspect, monitor and log network traffic. 在此步骤中，将在传输 VPC 的每个区域中安装防火墙路由器设备。

NFV 路由器

供应防火墙路由器设备。 已向传输 VPC 添加 Transit Gateway 的入口路由表，如虚线所示。 已在传输 VPC 的每个专区中创建子网以存放防火墙路由器。

从企业到辐射的连接是通过传输 VPC 中的网络功能虚拟化 NFV 防火墙路由器实例实现的。 在生产中，您可以从目录中选择一个或自带一个。 此演示将使用设置了内核 iptables 的 Ubuntu 股票映像，以将所有包从源转发到目标。 在本教程中，不会执行防火墙检查。

Terraform 配置将使用 allow_ip_spo构面 配置防火墙路由器实例。 在继续之前，必须 启用 IP 电子欺骗检查。

1. 应用 firewall_tf 层:

   ./apply.sh firewall_tf
   

2. 运行测试套件。

   您的预期结果为: Connectivity within a VPC, enterprise -> transit, enterprise <-> spoke same zone pass. 但所有中转-> 发言，所有中转-> 企业由于非对称路由问题而失败。

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

   第二部分 of this tutorial will route all VPC <-> different VPC traffic through the firewall-router and resolve these issues. 但首先要了解正在发生的事情。

除去传输目标流量的防火墙

IBM Cloud VPC 使用基于业界标准状态的路由来进行安全 TCP 连接跟踪。 它要求 TCP 连接在作为出路的路上使用相同的路径。 一个例外是 Network Load Balancers 之类的路由器使用的直接服务器返回。 它允许来自企业的入局连接通过防火墙传递到传输测试实例，然后直接返回到发起方。

这无助于源自传输测试实例的流量通过 Transit Gateway，然后通过入口路由返回到防火墙路由器。 此连接卡在防火墙路由器 (3) 上，不会被转发回工作程序，如下红色所示。 交通运输-> 企业和运输-> 辐射失败。

一种可能的解决方案是停止将发送到传输 VPC 的流量发送到防火墙路由器。 传输的宽入口路由当前正在将流量路由到防火墙路由器。 可以将更具体的路由添加到 Delegate 传输到缺省行为-直接发送到预期目标，而不是防火墙路由器。

此图显示此步骤所需的交通流。 Only the enterprise <-> spoke is passing through the firewall:

1. enterprise <-> transit
2. spoke <-> transit
3. spoke <-> spoke
4. enterprise <--transit firewall-router--> spoke

可以通过将这些路由添加到中转入口路由表来实现此路由:

1. 要观察入口路由表的当前值，请访问 IBM Cloud 控制台中的 VPC 的路由表。 从下拉列表中选择 传输 VPC，然后选择 tgw-ingress 路由表。

2. 通过应用 transit_ingress 层对路由表进行更改:

./apply.sh transit_ingress_tf

1. 刷新路由表的浏览器显示以观察新路由。

2. 运行测试套件。

   您期望的结果为: 所有测试都将生成 已通过。

   pytest -m "curl and lz1 and (rz1 or rz2)"
   

值得注意的是，在配置中，企业与辐射之间的跨区域流量如何流动。 企业通过传输 VPC 中的入口路由将流量发送到正确的区域并通过防火墙路由器。 Transit Gateway 已了解到 192.168.0.0/16 在所有专区中都可用，并且将使用与辐射相同的专区中的广告企业路径来路由到运输 VPC，如下图所示:

路由摘要

基本路由已完成:

• enterprise <-> transit
• transit <-> spoke(s)
• enterprise <--(transit firewall-router)--> spoke

生产说明和结论

IBM Cloud for Financial Services 的 VPC 参考体系结构 提供了有关保护 IBM Cloud中工作负载的更多详细信息。

要进行的一些明显更改:

• 选择 CIDR 块是为了澄清和便于解释。 多专区区域中的可用性专区可以是 10.0.0.0/10，10.64.0.0/10，10.128.0.0/10 以节省地址空间。 工作程序节点的地址空间可以以防火墙，DNS 和 VPE 空间为代价进行扩展。
• 应该仔细考虑工作程序 VSI，虚拟专用端点网关，DNS 位置和防火墙的每个网络接口的安全组。
• 应仔细考虑每个子网的网络访问控制表。

浮动 IP 已连接到所有测试实例，以支持通过 SSH 进行的连接测试。 这在生产中是不需要的或不可取的。

实施基于上下文的限制 规则以进一步控制对所有资源的访问。

在本教程中，您创建了一个中心 VPC 和一组辐射 VPC。 您确定了体系结构所需的可用性区域，并在 VPC 中创建了一组子网。 您在每个专区中创建了传输 VPC 防火墙路由器以转发流量。 测试实例用于验证连接并确定潜在问题。 路由表路径用于标识所需的流量路径。

除去资源

如果计划继续本教程的第二部分，那么不需要除去资源。

使用 ./apply.sh 命令以逆向顺序在所有目录中执行 terraform destroy :

./apply.sh -d : spokes_egress_tf

扩展教程

建议您继续使用本教程的 第二部分，其中将通过防火墙路由器，VPE for VPC 和 DNS 来路由所有跨 VPC 流量。

您的体系结构可能与所呈现的体系结构不同，但可能是从此处讨论的基本组件构造的。 展开本教程的构想:

• 使用 IBM Cloud® Internet Services 集成入局公共因特网访问。
• 在传输中添加 流日志捕获。
• 将每个辐条放在 企业 中的单独帐户中。
• 强制某些辐条通过防火墙的辐条流量，而某些辐条不通过防火墙的辐条流量。
• 将工作程序 VSI 替换为 Red Hat OpenShift on IBM Cloud 和 VPC 负载均衡器。
• 强制通过传输 VPC 中的防火墙和 公共网关 的所有出站流量。

相关内容

• IBM Cloud for Financial Services
• 如何跨多个位置和区域部署隔离的工作负载
• 虚拟私有云中的公共前端和私有后端，
• 网络功能虚拟化
• 使用透明 VNF 和辐射到辐射流量的专用中心和辐射