目標

• VPC ベースのハブ・アンド・スポーク・モデルの背後にある概念を理解します。
• ファイアウォール・ルーターおよび中継 VPC 環境の実装について理解します。
• VPC の着信と発信のルーティングについて理解します。
• 非対称ルーティングの問題を特定し、オプションで解決します。
• Transit Gatewayを介して VPC を接続します。

開始前に

このチュートリアルでは、以下が必要です。

• terraform: リソースをプロビジョンするコードとしてインフラストラクチャーを使用します。
• オプションで pytest コマンドを実行するには、 python
• ファイアウォール・ルーターを実装するには、 IP スプーフィング・チェックを有効にする 必要があります。
• 仮想サーバーに接続するためのSSHキー。 SSH 鍵をお持ちでない場合は、VPC 用の鍵作成 手順 に従ってください。

前提条件環境を簡単に作成するための Dockerfile を含むいくつかのオプションについては、 前提条件 を参照してください。

さらに、以下を行います。

• ユーザー許可があるか確認してください。 ご使用のユーザー・アカウントに、このチュートリアルのすべてのリソースを作成および管理するための十分な権限があることを確認してください。 以下のリストを参照してください。
  • VPC に必要な権限。
  • Transit Gatewayを作成するために必要な権限。
  • IP スプーフィング・チェックに必要な許可。

IP アドレスとサブネットのレイアウト

このステップでは、VPC ネットワーク・リソースをプロビジョンします。 VPC のアドレス指定計画を設計 して慎重に計画し、重複しない CIDR ブロックを使用してください。

最初に CIDR スペースを VPC で分割したくなりますが、これによりルーティングが複雑になります。 代わりに、アベイラビリティー・ゾーンは単一の CIDR ブロックと見なされ、各 VPC はそのスライスを消費するものと見なされます。

この図は、ゾーン 1 の詳細を示しています。 サブネットのサイズとレイアウトは、他のゾーンでも同じです。

エンタープライズの上は左側にあり、 IBM Cloud は右側にあります。 IBM Cloud では、トランジット VPC とスポーク 0 に対して単一ゾーンが描画されます。 CIDR ブロックはオーバーラップせず、VPC はすべて、各ゾーンの CIDR ブロックを消費することに注意してください。

• オンプレミス CIDR は 192.168.0.0/16です。
• この マルチゾーン・リージョン のゾーンは 10.*.0.0/16です。 2桁目：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。
• Transit 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-パート 2 で使用される VPE for VPC。
• fw-firewall-router VPC インスタンス (転送中のみ)。

VPC ネットワーク・リソースのプロビジョン

1. コンパニオン GitHub Repository には、アーキテクチャーを実装するためのソース・ファイルがあります。 デスクトップ・シェルで、リポジトリーを複製します。

   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. 各レイヤーが正しい順序でインストールされ、このチュートリアルのいくつかのステップでは複数のレイヤーがインストールされるため、シェル・コマンド ./apply.sh が提供されます。 以下のようにすると、ヘルプが表示されます。

   ./apply.sh
   

5. ./apply.sh : : を実行することで、構成されたすべてのレイヤーを適用できます。 コロンは、first (または config_tf) および last (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. まだお持ちでない場合は、 プラットフォームAPIキー を取得し、Terraformで使用するためにAPIキーをエクスポートします

   export IBMCLOUD_API_KEY=YourAPIKEy
   

7. この最初のステップでは、config_tf、enterprise_tf、transit_tf、報道官 _tf、およびtransit_スポーク _tgw_tf に以下を適用します。

   ./apply.sh : transit_spoke_tgw_tf
   

VPC とサブネットが作成されました。 トランジット VPC とスポーク VPC は、プロビジョンされた Transit Gatewayを介して接続されています。 ブラウザーで 仮想プライベート・クラウド を開きます。 中継 VPC を開き、アドレス接頭部とサブネットの CIDR ブロックをメモします。 エンタープライズ VPC とスポーク VPC も調べてください。 Transit Gateway を開き、中継ゲートウェイをクリックして、中継 VPC とスポーク VPC の間の接続を表示します。

テスト・インスタンスの作成

VPC 仮想サーバー・インスタンス、VSI は、ネットワーク接続をテストするためにプロビジョンされます。 テスト・インスタンスは、エンタープライズ内の各ワーカー・サブネット (ゾーンごとに 1 つ)、トランジット・スポーク、および各スポークに追加されます。 3 つのゾーンと 2 つのスポークのデフォルト構成が使用されている場合、12 個のインスタンスがプロビジョンされます。

1. テスト・インスタンスの作成

   ./apply.sh test_instances_tf
   

IBM Cloud コンソールの各ステップで作成されたリソースを探索することができます。 オプションで、 「仮想プライベート・クラウド」 を開きます。 左側で 「仮想サーバー・インスタンス」 をクリックし、作成されたインスタンスを確認します。

テスト

このチュートリアルでは、一度に 1 層ずつ通信パスを追加します。 pytest テスト・スイートは、通信パスを徹底的にテストするために使用されます。 チュートリアルの終わりまでに、すべてのテストが成功することが予想されます。

リーダーが pytest を使用して結果を検証する必要はありません。 チュートリアルを進め、レイヤーを適用し、チュートリアルで説明されている結果を信頼します。 リーダーは、VSI、サブネット、経路テーブルなどの VPC リソースを作成後も探索できます。

各 pytest テストは、インスタンスの 1 つに SSH で接続し、他のインスタンスの 1 つに対して curl コマンドを実行するなど、タイプの接続テストを実行します。 インスタンスへのログインには、デフォルトの SSH 環境が使用されます。 予期しないテスト結果が表示された場合は、 pytest troubleshooting セクションを試してください。

1. -m (マーカー) フラグを使用して、スイート内のゾーン 1 curl テストを実行します。 curl、 lz1 (左ゾーン 1)、および rz1 (右ゾーン 1) のマークが付いたテストを選択します。

   期待される結果: エンタープライズ <-> エンタープライズなどの VPC 内の接続は 成功します。 輸送とスポークの間の接続は 「通過」 になります。 企業からのクロス 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. エンタープライズ・ゾーン 1 のテスト・インスタンスに SSH で接続します。
2. 輸送ゾーン 1 に対して curl を実行します。
3. 戻りストリングに、合格または不合格のマークを付けるための通過ゾーン 1 の ID が含まれていることを表明します。

詳細とソース・コードについては、コンパニオン GitHub Repository の README.md を参照してください。

Direct Link および Transit Gateway を介してエンタープライズを Transit に接続します

Transit Gatewayを使用して IBM Cloud® Direct Link をプロビジョンします。

IBM Cloud® Direct Link は、エンタープライズを IBM Cloudに接続するための高速セキュア・データ・パスです。 このチュートリアルでは、 Transit Gateway が配布に使用されます。 Transit Gateway の使用は、オンプレミス接続ではオプションです。

このチュートリアルの企業は、別の VPC でシミュレートされています。 このシミュレートされたエンタープライズ (実際には別の VPC) を Transit Gateway を介して接続することで、 Direct Linkで経験する内容に非常に近いエクスペリエンスが得られます。

1. enterprise_link_tf レイヤーを適用します。

   ./apply.sh enterprise_link_tf
   

2. -m (マーカー) フラグを使用して、スイート内のゾーン 1 curl テストを実行します。 curl、 lz1 (左ゾーン 1)、および rz1 (右ゾーン 1) のマークが付いたテストを選択します。

   予期される結果: VPC 内の接続、中継 <-> スポーク (s)、エンタープライズ <-> 中継、スポーク (s) <-> スポーク (s) は成功しましたが、エンタープライズ <-> スポーク (s) は失敗しました。

   pytest -m "curl and lz1 and rz1"
   

Transit NFV Firewall-Router を介してエンタープライズをスポークに接続

エンタープライズ <-> クラウド・トラフィックのトランジット VPC のインセンティブは、通常、ネットワーク・トラフィックをルーティング、検査、モニター、およびログに記録することです。 このステップでは、中継 VPC の各ゾーンにファイアウォール・ルーター・アプライアンスがインストールされます。

NFV ルーター

ファイアウォール・ルーター・アプライアンスをプロビジョンします。 Transit Gateway の Ingress 経路テーブルが、点線で示されているようにトランジット VPC に追加されました。 中継 VPC の各ゾーンに、ファイアウォール・ルーターを保持するためのサブネットが作成されました。

企業からスポークへの接続は、中継 VPC のネットワーク機能仮想化、 NFV、ファイアウォール・ルーター・インスタンスを介して実現されます。 実動では、カタログから 1 つ選択することも、独自のカタログを持ち込むこともできます。 このデモンストレーションでは、すべてのパケットをソースから宛先に転送するために、カーネル iptables がセットアップされた Ubuntu ストック・イメージを使用します。 このチュートリアルでは、ファイアウォール検査は実行されません。

Terraform 構成では、 allow_ip_spoofing を使用して firewall-router インスタンスを構成します。 続行する前に、 IP スプーフィング・チェックを有効にする 必要があります。

1. firewall_tf レイヤーを適用します。

   ./apply.sh firewall_tf
   

2. テスト・スイートを実行します。

   予期される結果: VPC 内の接続、エンタープライズ-> 中継、エンタープライズ <-> 同じゾーン・パスをスポークします。 しかし、すべてのトランジット-> スポーク、すべてのトランジット-> エンタープライズは、非対称ルーティングの問題が原因で失敗します。

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

   このチュートリアルの パート 2 では、すべての VPC <-> 異なる VPC トラフィックを firewall-router を介してルーティングし、これらの問題を解決します。 まず、何が起きているのかを知ることが重要です。

Transit Destination トラフィック用のファイアウォールの削除

IBM Cloud VPC は、セキュア TCP 接続トラッキングのために業界標準の状態ベースのルーティングを使用します。 これは、途中で TCP 接続が使用するパスが、途中で使用するパスと同じであることを必要とします。 1 つの例外は、 Network Load Balancers のようなルーターによって使用される Direct Server Return です。 これにより、企業からの着信接続がファイアウォールを通過して中継テスト・インスタンスに入り、発信元に直接戻ることができます。

これは、 Transit Gateway を通過し、その後ファイアウォール・ルーターへの Ingress ルーティングを通過する転送テスト・インスタンスからのトラフィックには役立ちません。 この接続はファイアウォール・ルーター (3) で停止し、以下に示すようにワーカーには転送されません。 交通輸送-> 企業と輸送-> スポークに障害が発生しています。

考えられる解決策の 1 つは、中継 VPC 宛てのトラフィックを firewall-router に送信するのを停止することです。 転送のための幅広い ingress 経路は、現在、ファイアウォール・ルーターにトラフィックをルーティングしています。 「代行 (Delegate)」 への転送用に、より具体的な経路をデフォルトの動作に追加することができます。つまり、ファイアウォール・ルーターではなく、目的の宛先に直接送信します。

この図は、このステップに必要なトラフィック・フローを示しています。 ファイアウォールを通過するのは、エンタープライズ <-> スポークのみです。

1. エンタープライズ <-> 輸送
2. スポーク <-> 中継
3. スポーク <-> スポーク
4. エンタープライズ<--transitファイアウォールルーター-->スポーク

このルーティングは、以下の経路を中継入口経路テーブルに追加することによって実現できます。

1. 入口経路テーブルの現行値を監視するには、 IBM Cloud コンソールの VPC のルーティング・テーブル にアクセスしてください。 ドロップダウンから transit VPC を選択してから、 tgw-ingress ルーティング・テーブルを選択します。

2. transit_ingress レイヤーを適用して、ルーティング・テーブルに変更を加えます。

./apply.sh transit_ingress_tf

1. ルーティング・テーブルのブラウザー表示を最新表示して、新しい経路を監視します。

2. テスト・スイートを実行します。

   予期される結果: すべてのテストの結果は PASSED になります。

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

企業と構成内のスポークとの間でクロスゾーン・トラフィックがどのように流れるかに注目する必要があります。 エンタープライズは、正しいゾーンにトラフィックを送信し、中継 VPC の入口ルーティングを介してファイアウォール・ルーターを介してトラフィックを送信します。 Transit Gateway は、すべてのゾーンで 192.168.0.0/16 が使用可能であることを確認し、以下の図に示すように、スポークと同じゾーン内の公示されたエンタープライズ経路を使用してトランジット VPC にルーティングします。

ルーティング・サマリー

基本ルーティングが完了しました:

• エンタープライズ <-> 輸送
• トランジット <-> スポーク
• エンタープライズ < -- (中継ファイアウォール-ルーター)--> スポーク

生産上の注意と結論

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 ロケーション、およびファイアウォールの各ネットワーク・インターフェースのセキュリティー・グループは、すべて慎重に検討する必要があります。
• 各サブネットのネットワーク・アクセス制御リストは慎重に検討する必要があります。

SSH を介した接続テストをサポートするために、すべてのテスト・インスタンスに浮動 IP が付加されました。 これは、実動環境では必須ではなく、望ましいものでもありません。

コンテキスト・ベースの制限を実装 して、すべてのリソースへのアクセスをさらに制御します。

このチュートリアルでは、ハブ VPC とスポーク VPC のセットを作成しました。 アーキテクチャーに必要なアベイラビリティー・ゾーンを特定し、VPC に一連のサブネットを作成しました。 トラフィックを転送するために、各ゾーンに中継 VPC ファイアウォール・ルーターを作成しました。 テスト・インスタンスは、接続を検証し、潜在的な問題を識別するために使用されました。 必要なトラフィック・パスを識別するためにルーティング・テーブル経路が使用されました。

リソースを削除する

このチュートリアルの 2 番目の部分を続行する予定の場合は、リソースを削除する必要はありません。

./apply.sh コマンドを使用して、すべてのディレクトリーで terraform destroy を逆順に実行します。

./apply.sh -d : spokes_egress_tf

チュートリアルを発展させる

このチュートリアルの パート 2 に進むことをお勧めします。ここでは、すべての VPC 間トラフィックが firewall-router、 VPE for VPC 、および DNS を経由してルーティングされます。

ご使用のアーキテクチャーは、提示されているものとは異なる可能性がありますが、ここで説明する基本コンポーネントから構成される可能性があります。 このチュートリアルを展開するためのアイデア:

• IBM Cloud® Internet Services を使用して着信パブリック・インターネット・アクセスを統合します。
• 転送中に フロー・ログ・キャプチャー を追加します。
• 各スポークを エンタープライズ 内の別個のアカウントに配置します。
• 一部のスポーク・トラフィックがファイアウォールを通過するように強制し、一部はファイアウォールを通過しないように強制します。
• ワーカー VSI を Red Hat OpenShift on IBM Cloud および VPC ロード・バランサー に置き換えます。
• すべてのアウトバウンド・トラフィックを、中継 VPC のファイアウォールを経由し、 パブリック・ゲートウェイ を経由するように強制します。

関連コンテンツ

• 金融サービス向け IBM Cloud
• 複数のロケーションとリージョンにまたがって分離されたワークロードをデプロイする方法
• 仮想プライベート・クラウド内のパブリック・フロントエンドとプライベート・バックエンド、
• ネットワーク機能の仮想化
• 透過的な VNF およびスポーク間トラフィックを使用したプライベート・ハブおよびスポーク・スポーク・トラフィック