Azure Firewall を使用してマルチハブとスポークのトポロジをルーティングする

ハブアンドスポーク トポロジは、ネットワーク リソースを統合し、ネットワーク サービスを一元化する Azure の一般的なネットワーク アーキテクチャ パターンです。 このトポロジは、異なるサブスクリプションまたはテナントにデプロイされた仮想ネットワークにネットワーク接続とセキュリティを提供します。

ハブアンドスポーク アーキテクチャは、次の 2 つの方法で実装できます。

• セルフマネージド ハブ アンド スポーク (従来): ハブ仮想ネットワークとルーティング構成を完全に制御します。
• Virtual WAN: Microsoft はハブ仮想ネットワークを管理し、 ルーティングの意図やルーティング ポリシーなどの機能を使用して管理を簡素化します。

この記事では、ハブ仮想ネットワークと Azure Firewall のデプロイを完全に可視化して制御できるセルフマネージド ハブ アンド スポーク トポロジに焦点を当てます。

Azure Virtual Network Manager (AVNM) を使用すると、セルフマネージド のハブ アンド スポーク実装の管理オーバーヘッドを削減できます。 AVNMはルートテーブルの設定を自動化できますが、全体の設計や技術は手動方式と比べて変わりません。 この記事の内容は、AVNM を使用するか、自己管理ハブ アンド スポーク トポロジを手動で構成するかに関係なく適用されます。

スポーク仮想ネットワークにおけるルートテーブルの代替手段として、Azure Route Serverでサブネットにルートを注入する方法があります。これは「スポーク仮想ネットワークにおけるデフォルトルート注入」に記載されています。 しかし、このパターンはAzure Route ServerとVPNやExpressRouteの仮想ネットワークゲートウェイ間のやり取りに伴う複雑さのため、あまり使われていません。

セルフマネージド のハブ アンド スポーク セットアップでは、次の手順を実行します。

• ハブ: VPN、ExpressRoute、または Software-Defined ワイド エリア ネットワーク (SD-WAN) を介してオンプレミス ネットワークへの中央接続ポイントとして機能する仮想ネットワーク。 ファイアウォールなどのネットワークセキュリティデバイスをハブ仮想ネットワークに展開します。
• スポーク: ハブとピアリングし、ワークロードをホストする仮想ネットワーク。

ワークロードが複数のリージョンに分散している場合は、通常、リージョンごとに 1 つのハブをデプロイして、そのリージョンのスポークからのトラフィックを集計します。 次の図は、各リージョンに 2 つのスポーク仮想ネットワークがある 2 リージョンのセルフマネージド ハブ アンド スポーク アーキテクチャを示しています。

単一リージョンのハブアンドスポーク アーキテクチャ

複数リージョンの設計を理解するには、まず単一リージョンの概念を理解する必要があります。 次の図は、最初のリージョンのルーティング テーブルの構成を示しています。

ユーザー定義のルート構成を理解するために、単一リージョン設計の潜在的なトラフィック フローごとにルーティング要件を検討します。

• スポーク間トラフィック: スポークは相互にピアリングされず、仮想ネットワーク ピアリングは推移的ではありません。 各スポークは、既定ではハブ仮想ネットワークにルーティングする方法を認識しますが、他のスポークにはルーティングしません。 すべてのスポーク サブネットに適用される 0.0.0.0/0 のルートは、スポーク間トラフィックを対象とします。
• スポーク・トゥ・インターネットトラフィック:スポークルートテーブルの0.0.0.0/0ルートは、公共インターネットのトラフィックをAzure Firewallに誘導します。 デフォルトでアウトバウンドアクセスを持つ非プライベートサブネットでは、ユーザー定義ルートがデフォルトのインターネットシステムルートを上書きします。 2026年3月31日以降にリリースされたAPIバージョンを使用して作成された新しい仮想ネットワークは、デフォルトでプライベートサブネットを使用し、明示的なアウトバウンド方式を必要とします。 この設計では、Azure Firewallは明示的なアウトバウンド接続を提供します。 詳細については、「Azure での既定の送信アクセス」を参照してください。
• インターネット間トラフィック: インターネットからスポークへのトラフィックは、通常、最初に Azure Firewall を経由します。 Azure Firewall には、送信元 IP アドレス (送信元ネットワーク アドレス変換または SNAT) も変換する宛先ネットワーク アドレス変換 (DNAT) 規則が構成されています。 スポーク ワークロードでは、トラフィックは Azure Firewall サブネットからのトラフィックと見なされます。 仮想ネットワーク ピアリングは、ハブ (10.1.0.0/24) へのシステム ルートを作成するため、スポークはリターン トラフィックをルーティングする方法を認識します。
• オンプレミスからスポークへのトラフィックとスポークからオンプレミスへのトラフィック: 各方向を個別に検討します。
  • オンプレミス間トラフィック: オンプレミス ネットワークから VPN または ExpressRoute ゲートウェイにトラフィックが到着します。 Azure の既定のルーティングでは、システム ルートが各スポークの GatewaySubnet (およびハブ仮想ネットワーク内の他のサブネット) に作成されます。 これらのシステム ルートをオーバーライドし、次ホップを Azure Firewall のプライベート IP アドレスに設定する必要があります。 この例では、ゲートウェイ サブネットに関連付けられたルート テーブルに 2 つのルートが必要です。1 つはスポークごとに 1 つ (10.1.1.0/24 と 10.1.2.0/24)。 すべてのスポーク仮想ネットワークを含む10.1.0.0/16などの概要を使用しても、正しく機能しません。というのは、ゲートウェイ サブネットの仮想ネットワーク ピアリングによって挿入されるシステム ルートの方が、/24に比べて/16の概要よりも具体的だからです。 このルート テーブルでは、[ゲートウェイ ルートの伝達] のトグルを有効にして (はいに設定して) おく必要があります。そうしないと、ゲートウェイルーティングが予測不可能になる可能性があります。
  • スポークとオンプレミス間のトラフィック: ハブとスポークの間の仮想ネットワーク ピアリングでは、ハブ側で ゲートウェイトランジットを許可 し、スポーク側で リモートゲートウェイの使用 を有効にする必要があります。 これらの設定は、VPN ゲートウェイと ExpressRoute ゲートウェイが、Border Gateway Protocol (BGP) 経由でオンプレミス ネットワークにスポーク プレフィックスをアドバタイズするために必要です。 これらの設定により、オンプレミスから Azure に既定でアドバタイズされたプレフィックスもスポークで学習されます。 オンプレミスのプレフィックスはスポークルートテーブルのユーザー定義ルート 0.0.0.0/0 よりも具体的であるため、スポークからオンプレミスへのトラフィックはデフォルトでファイアウォールを回避します。 この状況を防ぐために、スポークルートテーブルで Propagateゲートウェイルートの トグルを 「No 」に設定し、オンプレミスのプレフィックスが学習されず、オンプレミスへのトラフィックに 0.0.0.0/0 ルートが使用されます。

Azure Virtual Network Managerを使うことで、スポークサブネットに関連付けられたルートテーブルとゲートウェイサブネットに関連付けられたルートテーブルの両方を管理でき、管理上の負担を軽減できます。 詳細については、「 次ホップとして Azure Firewall を使用する」を参照してください。

ハブ仮想ネットワークのワークロード

Active Directoryドメインコントローラー、DNSサーバー、その他の共有インフラストラクチャなどのワークロードをハブ仮想ネットワークに展開すると、ハブ・アンド・スポーク設計の複雑さが増します。 ハブに作業負荷を置くのは避けましょう。 代わりに、共有サービス専用のスポークに配置してください。

このセクションでは、この複雑さが要件に許容できるかどうかを評価できるように、ハブ ワークロードに必要な構成について説明します。 また、非対称トラフィックとパケット ドロップの原因となる可能性がある一般的な間違いについても説明します。

次の図は、ハブ仮想ネットワーク内のワークロード サブネットを使用した単一リージョンの設計を示しています。

重要な詳細は、ゲートウェイ サブネットとスポーク サブネットの両方で構成されたユーザー定義ルートが、 ハブ仮想ネットワーク プレフィックス全体ではなく、特定のワークロード サブネットに対して定義されていることです。

• ゲートウェイ サブネットの構成: ハブ仮想ネットワーク全体 (この例では10.1.0.0/24 ) のゲートウェイ サブネット内のルートを構成すると、ハブ仮想ネットワークのシステム ルートがオーバーライドされます。 これにより、VPN または ExpressRoute ゲートウェイ間のサブネット内制御トラフィックがファイアウォールに送信され、ゲートウェイ操作が中断される可能性があります。
• スポーク サブネットの構成: ハブ仮想ネットワーク全体 (この例では10.1.0.0/24 ) のスポーク サブネット内のルートを構成すると、ハブ仮想ネットワークとのピアリングによって作成されたシステム ルートがオーバーライドされます。 ハブに送信されるすべてのトラフィックは、ソース ネットワーク アドレス変換 (SNAT) を経由するインターネット間トラフィックなど、Azure Firewall 自体から送信されたトラフィックを含む Azure Firewall に送信されます。 この構成では、非対称トラフィックが導入され、パケットのドロップが発生します。

サブネット間トラフィック検査

現在の構成では、ファイアウォールがスポーク間のトラフィックを処理しますが、スポーク内のトラフィックはスポーク仮想ネットワーク内に留まり、 ネットワークセキュリティグループを使って制御します。 この設計では、仮想ネットワークはセキュリティ境界と見なされます。ファイアウォールは、仮想ネットワークを終了または入力するトラフィックのみを検査します。

同じスポーク仮想ネットワーク内のサブネット間のトラフィックを検査するには、次の図に示すように、スポーク サブネットに関連付けられているルート テーブルを変更します。

前の図では、各スポーク仮想ネットワークに 2 つのスポーク サブネットが導入され、仮想ネットワーク A2 のスポークのルート テーブルが説明されています。 サブネット間トラフィックをファイアウォールに送信するには、各サブネットにインストールするルートが異なるため、すべてのサブネットに個別のルート テーブルが必要です。

サブネット A21 の場合は、次の 2 つの追加ルートが必要です。

• 10.1.2.0/24へのルート: 仮想ネットワーク内トラフィックのシステム ルートをオーバーライドします。 他のルートがない場合、すべての仮想ネットワーク内トラフィックは、同じサブネット内の仮想マシン間のトラフィックであっても、Azure Firewall に送信されます。
• 次ホップ10.1.2.0/26を使用してへのルート: 前のルートの例外であるため、この特定のサブネット内のトラフィックはファイアウォールに送信されず、仮想ネットワーク内でローカルにルーティングされます。 このルートは各サブネットに固有であるため、サブネットごとに個別のルート テーブルが必要です。

SD-WANネットワーク仮想アプライアンス

VPN または ExpressRoute ゲートウェイの代わりに SD-WAN ネットワーク仮想アプライアンス (NVA) を使用する場合、次の図に示すように、設計は似ています。

Azure で SD-WAN NVA を統合するには、さまざまな方法があります。 詳細については、 Azure ハブ アンド スポーク ネットワーク トポロジとのSD-WAN 統合に関するページを参照してください。 この記事では、Azure Route Serverを用いる統合を示しています。は、トラフィックを SD-WAN ネットワークにルーティングする最も一般的な方法の一つです。 SD-WAN NVA は、BGP を介してオンプレミスのプレフィックスを Azure Route Server にアドバタイズします。 Azure Route Server は、Azure Firewall サブネットにこれらのプレフィックスを挿入して、Azure Firewall がオンプレミス ネットワークのルーティング情報を持つようにします。 スポーク ルート テーブルで [ゲートウェイ ルートの伝達] オプションが無効になっているため、スポークはオンプレミスのプレフィックスを学習しません。

NVA サブネットに関連付けられているルート テーブルで各スポーク仮想ネットワークのプレフィックスを構成しない場合は、専用仮想ネットワークに SD-WAN NVA を配置できます。 NVA 仮想ネットワークでは、スポーク プレフィックスは直接ピアリングされていないため学習されず、次の図に示すように概要ルートが可能です。

複数リージョンのハブアンドスポーク アーキテクチャ

単一のハブ アンド スポーク リージョン内でのトラフィックのしくみを理解したら、設計を複数リージョンのアーキテクチャに拡張するのは簡単です。 次の図は、2 つのリージョン (A と B) のハブを使用した更新されたネットワーク設計を示しています。

構成の唯一の追加は、各リージョンの Azure Firewall サブネットに関連付けられているルート テーブルです。 各ハブ仮想ネットワークは、直接ピアリングされた仮想ネットワークのプレフィックスのみを認識するため、リモート スポークのプレフィックスのルーティングはありません。 各リージョンのトラフィックが対応する Azure Firewall にルーティングされるように、各 Azure Firewall サブネットのユーザー定義ルートを追加します。

この例では、各リージョンを簡単に要約できます。

• リージョン A にプレフィックスが含まれている 10.1.0.0/16
• リージョン B にプレフィックスが含まれている 10.2.0.0/16

各リージョンで簡単に要約できる IP アドレスを定義すると、ルーティング構成が簡単になります。 それ以外の場合は、リモート スポークごとに 1 つのルートを作成する必要があります。

ファイアウォールが VPN および ExpressRoute ゲートウェイからオンプレミスのルートを学習できるように、Azure Firewall サブネット ルート テーブルでゲートウェイ ルートを 伝達 するを有効にします。

複数リージョン環境でのユーザー定義ルートの管理を簡略化するために、Azure Virtual Network Manager を使用できます。 詳細については、「AVNM を使用した 複数のハブ アンド スポーク トポロジ間のユーザー定義ルートの管理」を参照してください。

次の手順

• Azure Firewall のデプロイおよび構成方法について説明します。