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

2025-09-29

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

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

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

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

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

スポーク仮想ネットワーク内の Azure ルートテーブルの代わりに、「スポーク仮想ネットワークでの既定のルート挿入」に記載されているように、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 での既定の送信アクセス」を参照してください。
インターネット間トラフィック: インターネットからスポークへのトラフィックは、通常、最初に 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 よりも具体的であるため、スポークからオンプレミスへのトラフィックは、既定でファイアウォールをバイパスします。このような状況を回避するには、スポークルートテーブルで [ ゲートウェイルートの伝達 ] トグルを [いいえ ] に設定して、オンプレミスのプレフィックスが学習されず、 0.0.0.0/0 ルートがオンプレミスへのトラフィックに使用されるようにします。

注

ネットワークの概要ではなく、ゲートウェイサブネットに関連付けられているルートテーブル内の正確なスポーク仮想ネットワーク IP プレフィックスを使用します。仮想ネットワークピアリングによってスポークと共に導入されたシステムルートは、より具体的であるため、ユーザー定義ルートをオーバーライドします。

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 に送信されます。この構成では、非対称トラフィックが導入され、パケットのドロップが発生します。

注

ハブ仮想ネットワークにワークロードをデプロイする場合は、ユーザー定義ルートで仮想ネットワーク IP プレフィックス全体を使用しないでください。

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

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

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

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

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

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

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

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

SD-WAN NVA を Azure に統合するには、さまざまな方法があります。詳細については、 Azure ハブアンドスポークネットワークトポロジとのSD-WAN 統合に関するページを参照してください。この記事では、トラフィックを SD-WAN ネットワークにルーティングする最も一般的な方法の 1 つである Azure Route Server を使用した統合について説明します。 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 サブネットルートテーブルでゲートウェイルートを伝達するを有効にします。

注

管理 NIC なしで Azure Firewall をデプロイする場合、Azure Firewall サブネットには、前に説明したように、より具体的なルートを追加するために、次ホップ "インターネット" を持つ既定のルートが必要です。

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

次の手順

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

フィードバック

このページはお役に立ちましたか?

次の方法で共有