目標

• 瞭解 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 for simplictiy 中，針對 transit VPC 和 Spoke 0 描述單一區域。 請注意，CIDR 區塊不會重疊，VPC 都在每個區域中耗用 CIDR 區塊:

• 內部部署 CIDR 是 192.168.0.0/16。
• 此 多區域地區 中的區域為 10.*.0.0/16。 第二位數字：1、2、3 是區域編號（顯示為達拉斯/美國南部）：
  • 10.1.0.0/16，區域 1，達拉斯 1，us-south-1。
  • 10.2.0.0/16，區域 2，達拉斯 2，us-south-2。
  • 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- DNS Services 在第二部分中使用的位置應用裝置。
• vpe-在第二部分中使用了 VPE for VPC。
• fw-firewall-router VPC 實例 (僅在傳輸中)。

佈建 VPC 網路資源

1. 隨附的 GitHub 儲存庫 具有用來實作架構的原始檔。 在桌面 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 : :
   

   它看起來如下：

   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. 如果還沒有，請取得 Platform 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 及子網路。 已透過佈建的 Transit Gateway連接 Transit VPC 和輪輻 VPC。 在瀏覽器中開啟 虛擬私有雲。 開啟傳輸 VPC，並記下位址字首及子網路的 CIDR 區塊。 同時檢查企業和輪輻 VPC。 開啟 Transit Gateway，然後按一下 Transit Gateway 以查看 Transit 與輪輻 VPC 之間的連線。

建立測試實例

VPC 虛擬伺服器實例 (VSI) 會佈建以測試網路連線功能。 測試實例將新增至企業、傳輸及每一個輪輻中的每一個工作者子網路 (每個區域一個)。 如果使用 3 個區域和 2 個輪輻的預設配置，則會佈建 12 個實例。

1. 建立測試實例

   ./apply.sh test_instances_tf
   

在 IBM Cloud 主控台中探索每一個步驟所建立的資源可能會很有啟發。 選擇性地開啟 虛擬私有雲。 在左側按一下 虛擬伺服器實例，並注意已建立的實例。

測試

本指導教學將一次新增一層通訊路徑。 將使用 pytest 測試套組來詳細測試通訊路徑。 在指導教學結束時，所有測試都預期通過。

讀者不需要使用 pytest 來驗證結果。 遵循指導教學，套用層，並信任指導教學中說明的結果。 在建立 VSI、子網路及路由表之類的 VPC 資源之後，讀取器仍然可以探索它們。

每一個 pytest 測試都會透過 SSH 連接至其中一個實例，並執行某種類型的連線功能測試，例如對其中一個其他實例執行 curl 指令。 會使用預設 SSH 環境來登入實例。 如果您看到非預期的測試結果，請嘗試 pytest troubleshooting 區段。

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。 名稱的中間部分識別企業、運輸、spoke0、spoke1、... z1、z2... 識別區域。 測試將透過 SSH 連接至左側實例。 在左側實例上，會嘗試連接右側實例。 test_curl 會在左側實例與右側實例之間執行 curl 連線功能。

總而言之，測試 test_curl[l-enterprise-z1 -> r-transit-z1] 將:

1. 透過 SSH 登入企業區域 1 中的測試實例。
2. 執行 curl 至運輸區域 1。
3. 主張傳回字串包含要標示通過或失敗的運輸區域 1 ID。

隨附 GitHub 儲存庫 中的 README.md 具有更多詳細資料及原始碼。

透過 Direct Link 和 Transit Gateway 將企業連接至 Transit

使用 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 路由器

佈建防火牆路由器應用裝置。 Transit Gateway 的入口路由表已新增至傳輸 VPC，如點虛線所指示。 已在 Transit VPC 的每一個區域中建立子網路，以保留防火牆路由器。

從企業到輪輻的連線功能是透過傳輸 VPC 中的「網路功能虛擬化」( NFV) 防火牆路由器實例來達成。 在正式作業中，您可以從型錄中選擇一個，或自行使用。 此示範將使用 Ubuntu 庫存映像檔，並將核心 iptables 設定為將所有封包從來源轉遞至目的地。 在本指導教學中，不會執行防火牆檢驗。

Terraform 配置將使用 allow_ip_spoofing 來配置防火牆路由器實例。 您必須先 啟用 IP 盜用檢查，才能繼續進行。

1. 套用 firewall_tf 層:

   ./apply.sh firewall_tf
   

2. 執行測試套組。

   您預期的結果如下: Connectivity within a VPC, enterprise -> transit, enterprise <-> spoke same zone pass. 但所有 transit-> spoke、all transit-> enterprise 因非對稱遞送問題而失敗。

   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 測試實例的資料流量透過 Transit Gateway，然後透過入口遞送回到防火牆路由器沒有幫助。 此連線會停留在防火牆路由器 (3)，且不會如下面的紅色所示轉遞回工作者節點。 交通傳輸-> 企業及傳輸-> 分支失敗。

一個可能的解決方案是停止將傳送至 Transit VPC 的資料流量傳送至防火牆路由器。 傳輸的寬進入路徑目前正在將資料流量遞送至防火牆路由器。 可以針對傳送至 委派 的預設行為新增更具體的路徑-直接傳送至預期的目的地，而不是防火牆路由器。

此圖顯示此步驟所需的交通流。 Only the enterprise <-> spoke is passing through the firewall:

1. enterprise <-> transit
2. spoke <-> transit
3. spoke <-> spoke
4. 企業<--transit防火牆-路由器--> 輻條

透過將這些路由新增至運輸入口路由表，可以實現此路由:

1. 若要觀察入口路由表的現行值，請造訪 IBM Cloud 主控台中的 VPC 的路由表。 從下拉清單中選取 transit VPC，然後選取 tgw-ingress 路由表。

2. 套用 transit_ingress 層，對遞送表進行變更:

./apply.sh transit_ingress_tf

1. 重新整理遞送表的瀏覽器顯示畫面，以觀察新的路徑。

2. 執行測試套組。

   您的預期結果為: 所有測試都會導致 通過。

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

值得注意的是，在配置中，跨區域資料流量如何在企業與輪輻之間流動。 企業透過 Transit VPC 中的 Ingress 遞送，將資料流量傳送至正確區域並透過防火牆路由器。 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 中建立一組子網路。 您已在每一個區域中建立 Transit VPC 防火牆路由器，以轉遞資料流量。 已使用測試實例來驗證連線功能並識別潛在問題。 已使用遞送表路由來識別所需的資料流量路徑。

移除資源

如果您計劃繼續進行本指導教學的第二部分，則不需要移除資源。

使用 ./apply.sh 指令，以相反順序在所有目錄中執行 terraform destroy :

./apply.sh -d : spokes_egress_tf

擴展指導教學

建議您繼續進行本指導教學的 第二部分，其中所有跨 VPC 資料流量都透過防火牆路由器遞送，並檢查 VPE for VPC 及 DNS。

您的架構可能不同於所呈現的架構，但可能是根據這裡所討論的基本元件來建構。 展開本指導教學的構想:

• 使用 IBM Cloud® Internet Services 整合送入的公用網際網路存取。
• 在運輸中新增 流程日誌擷取。
• 將每一個輪輻放入 企業 中的個別帳戶。
• 強制部分輪輻資料流量通過防火牆，部分輪輻資料流量未通過防火牆。
• 將工作者 VSI 取代為 Red Hat OpenShift on IBM Cloud 及 VPC 負載平衡器。
• 強制所有出埠資料流量通過 Transit VPC 中的防火牆並透過 公用閘道。

相關內容

• IBM Cloud for Financial Services
• 如何跨多個位置和地區部署隔離的工作負載
• Virtual Private Cloud 中的公用前端及專用後端，
• 網路功能虛擬化
• 具有透通 VNF 及輪輻對輪輻資料流量的專用中心及輪輻