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 内のルート サーバーを使用するこのシナリオでは、ユーザー定義ルートを使用する必要はありません。 NVA はネットワーク プレフィックスを Route Server に公開し、これがこれらを挿入することで、[リモート仮想ネットワークのゲートウェイまたは Route Server を使用する] 設定で、ハブ VNet とピアリングされたスポーク VNet またはハブ VNet にデプロイされた仮想マシンの有効なルートとして表示されます。
NVA を介したオンプレミスへの接続
NVA を使用して、IPsec VPN または SD-WAN テクノロジを介したオンプレミス ネットワークへの接続を提供する場合は、同じメカニズムを使用して、スポークから NVA へのトラフィックを引き付けます。 さらに、NVA は Azure Route Server から Azure プレフィックスを動的に学習し、動的ルーティング プロトコルを使用してオンプレミスにアドバタイズできます。 次の図は、このセットアップを説明しています。
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 の概要」を参照してください。
重要
同じ長さのプレフィックスが ExpressRoute と NVA から公開されるシナリオでは、Azure は ExpressRoute から学習したルートを優先してプログラムします。 詳細については、「ルーティングの優先順位」を参照してください。
仮想ネットワーク ゲートウェイを使用したオンプレミスへの接続
VPN または ExpressRoute ゲートウェイが、オンプレミス ネットワークへの接続を提供するために Route Server および NVA と同じ仮想ネットワークに存在する場合、これらのゲートウェイによって学習されたルートはスポーク VNet でもプログラミングされます。 これらのルートは、より具体的 (より長いネットワーク マスク) であるため、Route Server によって挿入される既定のルート (0.0.0.0/0) をオーバーライドします。 次の図は、ExpressRoute ゲートウェイが追加された前の設計を示しています。
VPN と ExpressRoute ゲートウェイによって学習されたオンプレミスのプレフィックスを使用してスポーク VNet がプログラムされないようにするには、スポーク サブネットのルート テーブルで "ゲートウェイ ルートの伝達" を無効にします。 オンプレミスへのトラフィックが NVA によって検査されるようにするために、スポーク サブネットのルート テーブルに 0.0.0.0/0 の UDR（ユーザー定義ルート）を設定し、その次のホップとしてハブ VNet の NVA/ファイアウォールを指定します。 "ゲートウェイ ルートの伝達" を無効にすると、これらのスポーク サブネットがルート サーバーからルートを動的に学習できなくなることに注意してください。
既定では、Route Server は NVA から学習したすべてのプレフィックスを ExpressRoute にも公開します。 これは、たとえば ExpressRoute のルート制限のため、望ましくない場合があります。 その場合、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 サブネットは、ExpressRoute と VPN/SDWAN NVA の両方からのルートを学習し、トラフィックをどちらの方向に送信するかを決定します。 前のセクションで説明したように、1000 を超えるルートを NVA アプライアンスが Route Server に公開する場合は、BGP コミュニティ no-advertise でマークされた BGP ルートを送信する必要があります。 このように、SDWAN プレフィックスが ExpressRoute 経由で再びオンプレミスに挿入されることはありません。
注
プライベート エンドポイント宛てのオンプレミスからのトラフィックの場合、このトラフィックはハブ内の Firewall NVA または Azure Firewall をバイパスします。 ただし、これにより、プライベート エンドポイントがオンプレミスのトラフィックをファイアウォールに転送するため、非対称ルーティング (このためにオンプレミスとプライベート エンドポイント間の接続が失われる可能性があります) が発生します。 ルーティングの対称性を確保するには、プライベート エンドポイントがデプロイされているサブネット上でプライベート エンドポイントのルート テーブル ネットワーク ポリシーを有効にします。
トラフィックの対称性
回復性やスケーラビリティを向上するためにアクティブ/アクティブなシナリオで複数の NVA インスタンスを使用するとき、NVA が接続の状態を維持する必要がある場合は、トラフィックの対称性は要件です。 たとえば、次世代ファイアウォールの場合です。
- Azure 仮想マシンからパブリック インターネットへの接続の場合、NVA は送信元ネットワーク アドレス変換 (SNAT) を使用して、エグレス トラフィックが NVA のパブリック IP アドレスから送信され、トラフィックの対称性が実現されます。
- インターネットから仮想マシンで実行されているワークロードへの受信トラフィックの場合、NVA は、宛先ネットワーク アドレス変換 (DNAT) に加え、最初のパケットを処理したのと同じ NVA インスタンスに仮想マシンからの受信ラフィックが確実に送信されるのを確認するために、ソース ネットワーク アドレス変換 (SNAT) を実行する必要があります。
- Azure 間の接続では、送信元の仮想マシンが送信先とは無関係に経路決定を行うため、トラフィックの対称性を実現するために、現在では SNAT が必要です。
アクティブ/パッシブ セットアップでも、複数の NVA インスタンスをデプロイできます。たとえば、そのうちの 1 つが (AS パスが長い) 悪いルートをアドバタイズする場合などです。 この場合、Azure Route Server は VNet 仮想マシンに優先ルートのみを挿入し、優先されるルートは、プライマリ NVA インスタンスが BGP 経由でのアドバタイズを停止した場合にのみ使用されます。
また、Route Server ではデータパス トラフィックがサポートされていないことにも注意してください。 ルートを Route Server にアドバタイズする場合、NVA は、次のホップとして自身を指定してルートをアドバタイズする必要があります。また、NVA の前にあるロード バランサーや、NVA と同じ VNet 内の NVA/ファイアウォールを通じてルートをアドバタイズすることも可能です。
関連するコンテンツ
- ExpressRoute と Azure VPN に対する Azure Route Server のサポートについて詳しく説明します。
- Azure Route Server とネットワーク仮想アプライアンスの間のピアリングを構成する方法について説明します。