次の方法で共有

スポーク仮想ネットワークでの既定のルート インジェクション

  • [アーティクル]

Azure で最も一般的なアーキテクチャの 1 つはハブ アンド スポーク設計で、スポーク仮想ネットワーク (VNet) にデプロイされたワークロードは、ハブ VNet に存在する共有ネットワーク デバイスを介してトラフィックを送信します。 通常、ハブ内のセキュリティ デバイスに向けてトラフィックを管理するには、ユーザー定義ルート (UDR) をスポーク VNet で構成する必要があります。 ただし、この設計では、管理者はこれらのルートを多数のスポーク間で管理する必要があります。

Azure Route Server は、ネットワーク仮想アプライアンス (NVA) がスポーク VNet に挿入するルートを公開できる一元化されたポイントを提供します。 これにより、管理者はスポーク VNet でルート テーブルを作成および更新する必要はありません。

トポロジ

次の図は、ハブ VNet と 2 つのスポーク VNet を使用した単純なハブとスポークの設計を示しています。 ハブには、ネットワーク仮想アプライアンスと Route Server がデプロイされています。 Route Server がない場合は、すべてのスポークでユーザー定義ルートを構成する必要があります。 通常、これらの UDR には、スポーク VNet から NVA 経由ですべてのトラフィックを送信する 0.0.0.0/0 の既定のルートが含まれます。 このシナリオは、たとえば、セキュリティ上の目的でトラフィックを検査するために使用できます。

基本ハブ アンド スポーク トポロジを示す図。

ハブ VNet 内に Route Server がある場合、ユーザー定義ルートを使用する必要はありません。 NVA はネットワーク プレフィックスを Route Server に公開し、これがこれらを挿入することで、[リモート仮想ネットワークのゲートウェイまたは Route Server を使用する] 設定で、ハブ VNet とピアリングされたスポーク VNet またはハブ VNet にデプロイされた仮想マシンの有効なルートとして表示されます。

NVA を介したオンプレミスへの接続

NVA を使用して、IPsec VPN または SD-WAN テクノロジを介したオンプレミス ネットワークへの接続を提供する場合は、同じメカニズムを使用して、スポークから NVA へのトラフィックを引き付けます。 さらに、NVA は Azure Route Server から Azure プレフィックスを動的に学習し、動的ルーティング プロトコルを使用してオンプレミスにアドバタイズできます。 次の図は、このセットアップを説明しています。

NVA 経由でのオンプレミス接続がある基本ハブ アンド スポーク トポロジを示す図。

NVA を介したプライベート トラフィックの検査

前のセクションでは、ネットワーク仮想アプライアンス (NVA) から Route Server に 0.0.0.0/0 の既定のルートを挿入することで、NVA によって検査されるトラフィックを示しています。 ただし、NVA を介したスポーク対スポークとスポーク対オンプレミスのトラフィックのみを検査する場合は、NVA から学習した仮想ネットワーク アドレス空間と同じまたは長いプレフィックスであるルートを Azure Route Server が公開しないことを検討する必要があります。 言い換えると、Azure Route Server は、これらのプレフィックスを仮想ネットワークに挿入せず、ハブまたはスポークの VNet 内の仮想マシンの NIC でプログラムされません。

ただし、Azure Route Server では、NVA から学習した VNet アドレス空間よりも大きなサブネットが公開されます。 NVA から、仮想ネットワーク内にあるもののスーパーネットを公開することができます。 たとえば、仮想ネットワークで RFC 1918 アドレス空間 10.0.0.0/16が使用されている場合、NVA では 10.0.0.0/8 を Azure Route Server に公開でき、これらのプレフィックスはハブとスポークの VNet に挿入されます。 この VNet の動作については、「VPN Gateway を使用した BGP の概要」を参照してください。

Azure Route Server と NVA を介したプライベート プレフィックスの挿入を示す図。

重要

同じ長さのプレフィックスが ExpressRoute と NVA から公開されるシナリオでは、Azure は ExpressRoute から学習したルートを優先してプログラムします。 詳細については、次のセクションを参照してください。

仮想ネットワーク ゲートウェイを使用したオンプレミスへの接続

VPN または ExpressRoute ゲートウェイが、オンプレミス ネットワークへの接続を提供するために Route Server および NVA と同じ仮想ネットワークに存在する場合、これらのゲートウェイによって学習されたルートはスポーク VNet でもプログラミングされます。 これらのルートは、より具体的 (より長いネットワーク マスク) であるため、Route Server によって挿入される既定のルート (0.0.0.0/0) をオーバーライドします。 次の図は、ExpressRoute ゲートウェイが追加された前の設計を示しています。

NVA および ExpressRoute 経由でのオンプレミス接続がある基本ハブ アンド スポーク トポロジを示す図。

スポーク VNet 内のサブネットは、Azure Route Server からのルートのみを学習するように構成できません。 サブネットに関連付けられているルート テーブルで "ゲートウェイ ルートの伝達" を無効にすると、両方の種類のルート (仮想ネットワーク ゲートウェイからのルートと Azure Route Server からのルート) が、そのサブネット内の NIC に挿入されることが防止されます。

既定では、Route Server は NVA から学習したすべてのプレフィックスを ExpressRoute にも公開します。 これは、たとえば ExpressRoute または Route Server 自体のルート制限のために、望ましくない場合があります。 その場合、NVA は BGP コミュニティ no-advertise (値は 65535:65282) を含めて Route Server にルートをアナウンスできます。 Route Server は、この BGP コミュニティを含むルートを受信すると、それらをサブネットに挿入しますが、他の BGP ピア (ExpressRoute、VPN ゲートウェイ、他の NVA など) には公開しません。

ExpressRoute および Azure Firewall との SDWAN の共存

以前の設計の特定のケースは、ExpressRoute または SD-WAN/VPN アプライアンスを経由してオンプレミス ネットワークに向かうすべてのトラフィックを検査するために、顧客がトラフィック フローに Azure Firewall を挿入する場合です。 次の図に示すように、この状況では、スポークが ExpressRoute または Route Server からのルートを学習しないようにするルート テーブルと、Azure Firewall がネクスト ホップである既定のルート (0.0.0.0/0) がすべてのスポーク サブネットにあります。

Azure Firewall によってブレークアウトが行われる、VPN の NVA および ExpressRoute 経由でのオンプレミス接続があるハブ アンド スポーク トポロジを示す図。

Azure Firewall サブネットは、ExpressRoute と VPN/SDWAN NVA の両方からのルートを学習し、トラフィックをどちらの方向に送信するかを決定します。 前のセクションで説明したように、200 を超えるルートを NVA アプライアンスが Route Server に公開する場合は、BGP コミュニティ no-advertise でマークされた BGP ルートを送信する必要があります。 このように、SDWAN プレフィックスが ExpressRoute 経由で再びオンプレミスに挿入されることはありません。

トラフィックの対称性

回復性やスケーラビリティを向上するためにアクティブ/アクティブなシナリオで複数の NVA インスタンスを使用するとき、NVA が接続の状態を維持する必要がある場合は、トラフィックの対称性は要件です。 たとえば、次世代ファイアウォールの場合です。

  • Azure 仮想マシンからパブリック インターネットへの接続の場合、NVA は送信元ネットワーク アドレス変換 (SNAT) を使用して、エグレス トラフィックが NVA のパブリック IP アドレスから送信され、トラフィックの対称性が実現されます。
  • インターネットから仮想マシンで実行されているワークロードへの受信トラフィックの場合、NVA は、宛先ネットワーク アドレス変換 (DNAT) に加え、最初のパケットを処理したのと同じ NVA インスタンスに仮想マシンからの受信ラフィックが確実に送信されるのを確認するために、ソース ネットワーク アドレス変換 (SNAT) を実行する必要があります。
  • Azure 間の接続では、送信元の仮想マシンが送信先とは無関係に経路決定を行うため、トラフィックの対称性を実現するために、現在では SNAT が必要です。

アクティブ/パッシブ セットアップでも、複数の NVA インスタンスをデプロイできます。たとえば、そのうちの 1 つが (AS パスが長い) 悪いルートをアドバタイズする場合などです。 この場合、Azure Route Server は VNet 仮想マシンに優先ルートのみを挿入し、優先されるルートは、プライマリ NVA インスタンスが BGP 経由でのアドバタイズを停止した場合にのみ使用されます。

仮想ネットワーク ゲートウェイと VNet にルートをアドバタイズする各種ルート サーバー

前のセクションで示したように、Azure Route Server には次の 2 つのロールがあります。

  • 仮想ネットワーク ゲートウェイ (VPN と ExpressRoute) との間のルートを学習してアドバタイズする
  • 学習したルートを VNet 上および直接ピアリングされた VNet 上で構成する

多くの場合、この 2 つの機能は興味深いですが、場合によっては、特定の要件に悪影響を与える可能性があります。 たとえば、NVA が 0.0.0.0/0 ルートをアドバタイズし、ExpressRoute ゲートウェイがオンプレミスからプレフィクスをアドバタイズする VNet に Route Server を配置した場合、その VNet 内および直接ピアリングされた VNet 内にある仮想マシンにすべてのルート (NVA からの 0.0.0.0/0 とオンプレミスのプレフィクスの両方) が構成されることになります。 その結果、オンプレミスのプレフィックスは 0.0.0.0/0 よりも具体的になるため、オンプレミスと Azure の間のトラフィックは NVA をバイパスします。 これが望ましくない場合は、この記事の前のセクションに示されている、VM サブネットでの BGP 伝達を無効にして UDR を構成する方法を参照してください。

ただし、これとは別に、より動的なアプローチがあります。 さまざまな機能に合わせて異なる Azure Route Server を使用できます。そのうちの 1 つは、仮想ネットワーク ゲートウェイと連携し、もう 1 つは仮想ネットワーク ルーティングと連携する役割を担います。 次の図は、考えられるデザインを示しています。

ExpressRoute および 2 つの Route Server 経由でのオンプレミス接続がある基本ハブ アンド スポーク トポロジを示す図。

ハブ内の Route Server 1 を使用して、SDWAN から ExpressRoute にプレフィックスを挿入します。 スポーク VNet は、[リモート仮想ネットワークのゲートウェイまたはルート サーバーを使用する] (スポーク VNet ピアリング内) および [この仮想ネットワークのゲートウェイまたはルート サーバーを使用する] (ハブ VNet ピアリング内のゲートウェイ転送) なしでハブ VNet とピアリングされているため、スポーク VNet はこれらのルート (SDWAN プレフィックスも ExpressRoute プレフィックスも) を学習しません。

スポーク VNet にルートを伝達するために、NVA は新しい補助 VNet に配置された Route Server 2 を使用します。 NVA は、この Route Server 2 への 1 つの 0.0.0.0/0 ルートのみを伝達します。 スポーク VNet は、[リモート仮想ネットワークのゲートウェイまたはルート サーバーを使用する] (スポーク VNet ピアリング内) および [この仮想ネットワークのゲートウェイまたはルート サーバーを使用する] (ハブ VNet ピアリング内のゲートウェイ転送) を使用して、この補助 VNet とピアリングされるため、0.0.0.0/0 ルートはスポーク内のすべての仮想マシンによって学習されます。

この 0.0.0.0/0 ルートのネクスト ホップは NVA であるため、スポーク VNet を引き続きハブ VNet にピアリングする必要があります。 注意すべきもう 1 つの重要な側面は、Route Server 2 が配置されている VNet にハブ VNet をピアリングする必要があるということです。そうしないと、BGP 隣接性を作成できなくなります。

ExpressRoute からスポーク VNet へのトラフィックが検査のためにファイアウォール NVA に送信される場合にも、GatewaySubnet のルート テーブルが必要です。それがない場合、VNet ピアリングから学習したルートを使用して、ExpressRoute 仮想ネットワーク ゲートウェイから仮想マシンにパケットが送信されます。 このルート テーブルのルートはスポークのプレフィックスと一致する必要があります。また、ネクスト ホップはファイアウォール NVA (または冗長性のためにファイアウォール NVA の前にあるロード バランサー) の IP アドレスである必要があります。 ファイアウォール NVA は、上の図の SDWAN NVA と同じにすることができます。また、Azure Firewall などの別のデバイスにすることもできます。これは、SDWAN NVA が他の IP アドレスを指すネクストホップを使ってルートをアドバタイズできるためです。 この設計に Azure Firewall を追加したものが次の図です。

Note

プライベート エンドポイント宛てのオンプレミスからのトラフィックの場合、このトラフィックはハブ内の Firewall NVA または Azure Firewall をバイパスします。 ただし、これにより、プライベート エンドポイントがオンプレミスのトラフィックをファイアウォールに転送するため、非対称ルーティング (このためにオンプレミスとプライベート エンドポイント間の接続が失われる可能性があります) が発生します。 ルーティングの対称性を確保するには、プライベート エンドポイントがデプロイされているサブネット上でプライベート エンドポイントのルート テーブル ネットワーク ポリシーを有効にします。

ExpressRoute、Azure Firewall、2 つの Route Server を経由するオンプレミス接続がある基本ハブ アンド スポーク トポロジを示す図。

このような設計にすると、ExpressRoute、VPN、または SDWAN 環境から学習した他のルートから干渉を受けることなく、スポーク VNet に自動的にルートを挿入し、トラフィック検査用のファイアウォール NVA を追加できます。

関連するコンテンツ