目標

• すべての VPC 間トラフィックを管理するための VPC ベースのハブ・スポーク・モデルの背後にある概念を理解します。
• VPC の着信と発信のルーティングについて理解します。
• 非対称ルーティングの問題を特定し、オプションで解決します。
• 可用性の高いスケーラブルなファイアウォール・ルーターのためのネットワーク・ロード・バランサーの使用について説明します。
• DNS サービスのルーティングと転送の規則を使用して、体系的に健全な名前解決システムを構築します。

開始前に

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

• terraform: リソースをプロビジョンするコードとしてインフラストラクチャーを使用します。
• オプションで pytest コマンドを実行するには、 python
• ファイアウォール・ルーターを実装するには、 IP スプーフィング・チェックを有効にする 必要があります。

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

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

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

第 1 部の概要

このチュートリアルの パート 1 では、トランジット VPC とスポーク VPC のアドレス・スペースを慎重に計画しました。 ゾーン・ベースのアーキテクチャーを以下に示します。

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

これは、 Direct Link、 Transit Gateway 、および VPC ルーティングで実現されました。 すべてのゾーンは同様に構成され、以下の図はゾーン 1 の詳細を示しています。

CIDR 10.1.0.0/16 は輸送とスポークをカバーし、 Direct Link を経由して、広告経路として企業に渡されます。 同様に、CIDR 192.168.0.0/24 はエンタープライズをカバーし、 Transit Gateway を介してスポークに公示された経路として渡されます。

スポーク内の出口経路は、トラフィックを firewall-router に経路指定します。 Transit Route Enterprise <-> 内の Ingress 経路は、firewall-router を介してトラフィックを発信します。

すべての VPC 内トラフィックをファイアウォール・ルーター経由でルーティングする初期 VPC リソースをプロビジョンする

多くの場合、企業はファイアウォール・ルーターを使用してトラフィックをモニターするためにトランジット VPC を使用します。 パート 1 では、エンタープライズ <-> スポーク・トラフィックのみが中継ファイアウォール・ルーターを通過していました。 このセクションでは、すべての VPC から VPC へのトラフィックをファイアウォール・ルーターを介してルーティングする方法について説明します。

この図は、このステップで実装されるトラフィック・フローを示しています。

VPC 間のすべてのトラフィックが firewall-router を通過します。

• enterprise <-> スポーク。
• エンタープライズ <-> 輸送。
• transit <-> スポーク。
• スポーク <-> 異なる VPC でスポークされました。

VPC 内のトラフィックはファイアウォールを通過しません。

パート 1 から続行する場合は、 terraform.tfvars: all_firewall = true の構成を特にメモしてください。

ゾーン間ルーティングの修正

前述のように、ゾーン障害に対してシステムの回復力を高めるには、ゾーン間トラフィックを除去することをお勧めします。 ゾーン間サポートが必要な場合は、追加の出口経路を追加できます。 スポーク 0 からスポーク 1 へのトラフィックの問題を以下の図に示します。

緑色のパスは、発信元が 0 ゾーン 2 10.2.0.4 をスポーク 1 ゾーン 1 10.1.1.4にルーティングする例です。 一致する出口経路は以下のとおりです。

ゾーン	宛先	ネクスト・ホップ
Dallas10.0.0.0/810.2.15.196

図の中央ゾーン (ゾーン 2) のファイアウォール・ルーターを左から右に移動することが選択されています。 戻りパスで、ゾーン 1 が選択されます。

これを修正するには、より小さいゾーン番号の宛先が指定されている場合に、より高い番号のゾーンをより低いゾーン番号のファイアウォールに強制的に経路指定するために、より具体的な経路をいくつか追加する必要があります。 同じ番号のゾーンまたはそれ以上の番号のゾーンを参照する場合は、同じゾーン内のファイアウォールへのルーティングを続行します。

各スポークのデフォルトのイグレスルーティングテーブルのルート（Dallas/us-southを示す）：

ゾーン	宛先	ネクスト・ホップ
Dallas10.1.0.0/1610.1.15.196
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196

これらの経路は、同様の通過 < --> スポーク・ゾーン間非対称ルーティング問題も修正します。 トランジット・ワーカー 10.1.15.4-> スポーク・ワーカー 10.2.0.4を検討してください。 ゾーン 1 の中継ワーカーからのトラフィックは、ゾーン 1 (同じゾーン) のファイアウォール・ルーターを選択します。 ゾーン 2 (同じゾーン) の firewall-router の代わりにリターン・トリップでは、ゾーン 1 の firewall-router が使用されます。

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

   ./apply.sh all_firewall_asym_tf
   

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

   Your expected results are: 全てのテスト PASSED を並列に実行(-n 10)：

   pytest -n 10 -m curl
   

VPC 間のすべてのトラフィックは、ファイアウォール・ルーターを介してルーティングされるようになりました。

高性能高可用性 (HA) ファイアウォール-ルーター

ファイアウォール・ルーターがパフォーマンス・ボトルネックまたは Single Point of Failure にならないようにするために、VPC ネットワーク・ロード・バランサーを追加して、ゾーン・ファイアウォール・ルーターにトラフィックを分散させ、高可用性、HA、ファイアウォール・ルーターを作成することができます。 ご使用のファイアウォール・ルーターの資料を調べて、このアーキテクチャーがサポートされていることを確認してください。

この図は、2 つのファイアウォール・ルーターを接続する 経路モード でネットワーク・ロード・バランサー (NLB) が構成された単一ゾーンを示しています。 この構成を確認するには、構成を変更して再度適用する必要があります。

1. config_tf/terraform.tfvars: 内の以下の 2 つの変数を変更します。

   firewall_nlb                 = true
   number_of_firewalls_per_zone = 2
   

   この変更により、firewall-router の IP アドレスが、以前に使用された firewall-router インスタンスから NLB の IP アドレスに変更されます。 IP アドレスの変更は、中継 VPC およびスポーク VPC 内のいくつかの VPC 経路テーブルに適用する必要があります。 以前に適用したすべてのレイヤーを適用することをお勧めします。

2. all_firewall_asym_tf レイヤーを介してすべてのレイヤーを適用します。

   ./apply.sh : all_firewall_asym_tf
   

行われた変更を監視します。

1. 「VPC のロード・バランサー」 を開きます。
2. Select the load balancer in zone 1 (Dallas 1/us-south-1) it has the suffix fw-z1-s3.
3. プライベート IP に注意してください。

プライベート IP を、転送 VPC Ingress 経路テーブル内のものと比較します。

1. 「仮想プライベート・クラウド」 を開きます。
2. 中継 VPC を選択します。
3. 「ルーティング・テーブルの管理」 をクリックします。
4. tgw-ingress ルーティング・テーブルをクリックします。 ネクスト・ホップ IP アドレスが、NLB プライベート IP の 1 つと一致していることに注意してください。

回復力の検証:

1. スポーク 0 ゾーン 1 テストを実行します。

   pytest -k r-spoke0-z1 -m curl
   

2. VPC の仮想サーバー・インスタンス を開きます。
3. インバウンド・ポート 80 を許可しないセキュリティー・グループを指定して、 0 ファイアウォール・インスタンスへのトラフィックを停止します。 接尾部が fw-z1-s3-0 のインスタンスを見つけ、詳細ビューを開きます。
   1. スクロールダウンして、 「ネットワーク・インターフェース」 の横の鉛筆編集を押します。
   2. x-fw-inall-outall のチェック・マークを外す
   3. x-fw-in22-outall をチェックします。
   4. 保存 をクリックします。
4. もう一度 **pytest ** を実行します。 これは失敗を示します。 NLB が応答しないインスタンスへのトラフィックのルーティングを停止するのに数分かかります。その時点で、すべてのテストが合格します。 すべてのテストが成功するまで待機し、 pytest を実行し続けます。

NLB ファイアウォールは不要になりました。 NLB ファイアウォールを削除します。

1. config_tf/terraform.tfvars: 内の以下の 2 つの変数を変更します。

   firewall_nlb                 = false
   number_of_firewalls_per_zone = 1
   

2. all_firewall_asym_tf レイヤーを介してすべてのレイヤーを適用します。

   ./apply.sh : all_firewall_asym_tf
   

ルーティング・モードで構成された NLB に関する注意

NLB 経路指定モードでは、経路テーブル項目が再書き込みされます。フェイルオーバー時には、常にアクティブな NLB アプライアンス IP アドレスが経路テーブルに保持されます。 ただし、これは NLB を含むトランジット VPC 内の経路に対してのみ行われます。 スポークには、NLB アプライアンス IP の 1 つで初期化された出口経路があります。 スポーク・ネクスト・ホップは NLB アプライアンスのフェイルオーバー時に更新されません。

アクティブ・アプライアンスを反映するために NLB によって再書き込みされる通過 VPC 内の入口経路を維持する必要があります。 スポーク出口経路は、パケットを通過 VPC の正しいゾーンに送信します。 中継 VPC ゾーン内でルーティングすると、アクティブ・アプライアンスを含む一致する Ingress ルールが検出されます。

以下は、前述の中継 VPC Ingress 経路テーブルです。 ネクスト・ホップは、アクティブな NLB アプライアンスで最新の状態に保たれます。 Dallas 3には、アクティブなアプライアンスを反映するために、NLBルートモードサービスによって変更が書き込まれていることに注意してください。

NLB では、NLB が VPC に書き込むことができる IAM 許可を作成する必要があります。 この権限は、 apply.sh スクリプトによって作成されました。 スクリプトによって実行された構成について詳しくは、 ルーティング・モードでのネットワーク・ロード・バランサーの作成 を参照してください。

経路モード NLB プールは、 「セッション・パーシスタンス・タイプ」 をヌルに設定して構成する必要があります。

DNS

IBM Cloud DNS Services サービスは、名前を IP アドレスに変換するために使用されます。 この例では、クラウド内に DNS サービスが作成されます。 DNS ゾーン cloud.example.com が作成され、中継 VPC が許可ネットワークとして追加されます。 クラウド・インスタンスの DNS レコードが cloud.example.comに追加されます。 例えば、ゾーン 1 のスポーク 0 ワーカーに対して、フルネーム spoke0-z1-worker.cloud.example.comを持つレコードが作成されます。

VPE ゲートウェイの DNS 共有について を参照してください。 中継 VPC は DNS ハブとして有効になります。 各スポーク VPC は、中継 VPC ハブに DNS 解決バインディングを使用して構成されます。 これにより、DNS サーバーのスポーク VPC DHCP 設定が中継 VPC カスタム・リゾルバーとして構成されます。

./apply.sh dns_tf

pytest -n 10 -m dns

仮想プライベート・エンドポイント・ゲートウェイ

VPC では、 Virtual Private Endpoint (VPE) for VPC を介した IBM Cloud サービスへのプライベート・アクセスが許可されます。 VPE ゲートウェイでは、標準の IBM Cloud VPC 制御を使用して詳細なネットワーク・アクセス制御を行うことができます。

• Security Groups.
• VPC ネットワーク・アクセス制御リスト。
• ルーティング・テーブルと経路。

VPC VPE ゲートウェイごとに DNS ゾーンが作成されます。 DNS ゾーンは、VPC に関連付けられているプライベート DNS サービスに自動的に追加されます。 各スポーク VPC には、中継 VPC に対する DNS 構成 bound があります。 これにより、スポーク VPE DNS ゾーンを中継 VPC と共有できるようになります。

1. IBM Cloud Databases for PostgreSQL インスタンスを作成し、vpe_transit_tf 層とvpe_会談層を適用して、トランジット VPC とスポーク VPC ごとに VPE を作成します。

   ./apply.sh vpe_transit_tf vpe_spokes_tf
   

2. vpe テストと vpedns テストのセットは、pytest スクリプトで使用できます。 vpedns テストは、 Databases for PostgreSQL インスタンスの DNS 名が、エンクロージング VPC のプライベート CIDR ブロック内にあることを検証します。 vpe テストは、リモート側で Databases for PostgreSQL インスタンスにアクセスするために psql コマンドを実行します。 スポーク 0 ゾーン 1 から vpe および vpedns をテストします。

   • すべてのテストが成功すると予想される結果

   pytest -m 'vpe or vpedns' -k spoke0-z1
   

これで、このチュートリアルのすべてのテストが成功するはずです。 かなりの数があります。 それらを並列で実行します。

pytest -n 10

生産上の注意と結論

IBM Cloud for Financial Services の VPC リファレンス・アーキテクチャー には、 IBM Cloudでのワークロードの保護に関する詳細が記載されています。

いくつかの明白な変更を行う必要があります。

• 明瞭さと説明しやすいように、CIDR ブロックが選択されました。 マルチゾーン・リージョンのアベイラビリティー・ゾーンは、アドレス・スペースを節約するために、 10.1.0.0/10、 10.64.0.0/10、 10.128.0.0/10 にすることができます。 同様に、ワーカー・ノードのアドレス・スペースは、ファイアウォール、DNS、および VPE スペースを犠牲にして拡張することができます。
• ワーカー VSI、仮想プライベート・エンドポイント・ゲートウェイ、DNS ロケーション、およびファイアウォールの各ネットワーク・インターフェースのセキュリティー・グループは、すべて慎重に検討する必要があります。
• 各サブネットのネットワーク・アクセス制御リストは慎重に検討する必要があります。
• SSH を介した接続テストをサポートするために、すべてのテスト・インスタンスに浮動 IP が付加されました。 これは、実動環境では必須ではなく、望ましいものでもありません。
• コンテキスト・ベースの制限を実装 して、すべてのリソースへのアクセスをさらに制御します。

このチュートリアルでは、ハブ VPC とスポーク VPC のセットを作成しました。 すべての VPC 間トラフィックを通過 VPC ファイアウォール・ルーターを介してルーティングしました。 トランジット VPC ハブ用に DNS サービスが作成され、各スポーク VPC はトランジット VPC に DNS バインドされていました。

リソースを削除する

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

./apply.sh -d : :

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

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

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

関連コンテンツ

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