Virtual WAN ルーティングの詳細
Azure Virtual WAN は、高度なネットワーク トポロジを簡単に作成できるネットワーク ソリューションです。これには、ポイント対サイト VPN、サイト間 VPN、ExpressRoute、統合 SDWAN アプライアンスを介した Azure VNet とオンプレミスの場所の間の Azure リージョンのルーティングが含まれ、また、トラフィックをセキュリティで保護するオプションも含まれます。 ほとんどのシナリオでは、Virtual WAN の内部ルーティングのしくみについて深い知識を持っている必要はありませんが、特定の状況では、Virtual WAN のルーティングの概念を理解しておくと役に立つ場合があります。
このドキュメントでは、複雑なネットワークで VNet とブランチを相互接続するときに組織で発生する可能性があるいくつかの動作について説明するサンプルの Virtual WAN のシナリオを紹介します。 この記事に示すシナリオは決して設計上の推奨事項を示すものではなく、Virtual WAN の一部の機能を示すように設計されたサンプル トポロジにすぎません。
シナリオ 1: 既定のルーティング優先順位を使用するトポロジ
この記事の最初のシナリオでは、ExpressRoute、VPN、SDWAN の 2 つのVirtual WAN ハブを使用してトポロジを分析します。 各ハブには、直接接続された VNet (VNet 11 と 21) と、NVA 経由で間接的に接続された VNet (VNet 121、122、221、222) があります。 VNet 12 は BGP 経由でハブ 1 とルーティング情報を交換し (「仮想ハブとの BGP ピアリング」を参照)、VNet 22 には静的ルートが構成されているため、両方のオプションの違いを確認できます。
各ハブでは、VPN と SDWAN アプライアンス サーバーは 2 つの目的を果たします。一方では、独自の個々のプレフィックス (ハブ 1 の VPN 経由の 10.4.1.0/24 とハブ 2 の SDWAN 経由の 10.5.3.0/24) をアドバタイズし、もう一方では同じリージョン (ハブ 1の 10.4.2.0/24 とハブ 2 の 10.5.2.0/24) で ExpressRoute 回線と同じプレフィックスをアドバタイズします。 この違いは、Virtual WAN ハブのルーティング設定のしくみを示すために使用されます。
すべての VNet 接続とブランチ接続が関連付けられて、既定のルート テーブルに反映されます。 ハブはセキュリティで保護されていますが (すべてのハブに Azure Firewall がデプロイされています)、プライベート トラフィックまたはインターネット トラフィックをセキュリティで保護するようには構成されていません。 こうすることで、すべての接続が None ルート テーブルに反映され、Default ルート テーブルからすべての非静的ルートが削除され、ポータルの有効なルート ブレードがほとんど空になるため、この記事の目的は無効になります (Azure Firewall にトラフィックを送信する静的ルートを除きます)。
重要
上の図は、2 つのセキュリティ保護付き仮想ハブを示しています。このトポロジはルーティング インテントでサポートされています。 詳細については、「Virtual WAN ハブのルーティング インテントとルーティング ポリシーの構成方法」を参照してください。
既定では、Virtual WAN ハブは、リージョン間の通信が有効になるように相互に情報を交換します。 Virtual WAN ルート テーブルで有効なルートを検査できます。たとえば、次の図はハブ 1 の有効なルートを示しています。
これらの有効なルートは、Virtual WAN によってブランチにアドバタイズされ、仮想ハブに接続されている VNet に挿入されるので、ユーザー定義のルートを使用する必要がなくなります。 仮想ハブで有効なルートを検査する場合、[次ホップの種類] フィールドと [配信元] フィールドはルートの配信元を示します。 たとえば、"Virtual Network 接続" の次ホップの種類は、Virtual WAN に直接接続されている VNet でプレフィックスが定義されていることを示します (前のスクリーンショットの VNet 11 と 12)。
VNet 12 の NVA は、次ホップの種類 "HubBgpConnection" が示すように、BGP 経由でルート 10.1.20.0/22 を挿入します (「仮想ハブを使用した BGP ピアリング」を参照)。 この概要ルートでは、間接スポーク VNet 121 (10.1.21.0/24) と VNet 122 (10.1.22.0/24) の両方について説明します。 リモート ハブ内の VNet とブランチは、hub2 の次ホップで表示され、自律システム番号 65520 がこれらのインターハブ ルートに 2 回付加されていることが AS パスで確認できます。
ハブ 2 には、統合された SDWAN ネットワーク仮想アプライアンスがあります。 この統合でサポートされている NVA の詳細については、「Virtual WAN ハブの NVA について」を参照してください。 SDWAN ブランチ 10.5.3.0/24 へのルートには、VPN_S2S_Gateway の次ホップがあることに注意してください。 この種類の次ホップは、現在、Azure Virtual Network ゲートウェイから受信するルート、またはハブで統合された NVA からのルートを示す可能性があります。
ハブ 2 では、間接スポーク VNet 221 (10.2.21.0/24) と VNet 222 (10.2.22.0/24) への 10.2.20.0/22 のルートが、静的ルートとしてインストールされます。これは、配信元 defaultRouteTable によって示されます。 ハブ 1 の有効なルートをチェックインすると、そのルートは存在しません。 その理由は、静的ルートは BGP 経由で伝播されず、すべてのハブで構成する必要があるためです。 そのため、ハブ 1 内の VNet とブランチ間の接続をハブ 2 (VNet 221 および 222) 内の間接スポークに接続するために、ハブ 1 に静的ルートが必要です。
静的ルートを追加すると、ハブ 1 に 10.2.20.0/22 ルートも含まれるようになります。
シナリオ 2: Global Reach とハブ ルーティングの基本設定
ハブ 1 で回線 2 からの ExpressRoute プレフィックス (10.5.2.0/24) が認識されており、ハブ 2 で回線 1 からの ExpressRoute プレフィックス (10.4.2.0/24) が認識されている場合でも、リモート リージョンからの ExpressRoute ルートはオンプレミスの ExpressRoute リンクにアドバタイズされません。 そのため、ExpressRoute の 場所が相互に通信するには ExpressRoute Global Reach が必要です。
重要
上の図は、2 つのセキュリティ保護付き仮想ハブを示しています。このトポロジはルーティング インテントでサポートされています。 詳細については、「Virtual WAN ハブのルーティング インテントとルーティング ポリシーの構成方法」を参照してください。
「仮想ハブ ルーティングの優先順位」で説明されているように、Virtual WAN では既定で ExpressRoute からのルートが優先されます。 ルートはハブ 1 から ExpressRoute 回線 1、ExpressRoute 回線 1 から回線 2、ExpressRoute 回線 2 からハブ 2 (およびその逆) にアドバタイズされるため、仮想ハブは、より直接的なハブ間リンクよりもこのパスを優先します。 ハブ 1 の有効なルートは、次のとおりです。
ルートでわかるように、ExpressRoute Global Reach は、ExpressRoute 自律システム番号 (12076) を先頭に複数回付加してから、ルートを Azure に送り返して、これらのルートの優先順位を下げます。 ただし、ExpressRoute の Virtual WAN の既定のハブ ルーティングの優先順位では、ルーティングの決定を行うときに AS パスの長さを無視します。
ハブ 2 の有効なルートも同様です。
「仮想ハブのルーティングの優先順位」で説明されているように、ルーティング設定は、VPN または AS-Path に変更できます。 たとえば、次の図に示すように、優先順位を VPN に設定できます。
VPN のハブのルーティングの優先順位を使用すると、ハブ 1 の有効なルートは次のようになります。
前の図は、10.4.2.0/24 へのルートの次ホップが VPN_S2S_Gateway になったことを示していますが、ExpressRoute の既定のルーティング優先順位では ExpressRouteGateway でした。 ただし、ハブ 2 では、10.5.2.0/24 へのルートは、引き続き次ホップ ExpressRoute で表示されます。これは、この場合、代替ルートは VPN Gateway からではなく、ハブに統合された NVA からであるためです。
ただし、ハブ間のトラフィックは、ExpressRoute 経由のルートを引き続き優先しています。 仮想ハブの間のより効率的な直接接続を使用するために、両方のハブでルートの優先順位を "AS パス" に設定できます。
これで、ハブ 1 のリモート スポークとブランチのルートには、意図したとおりの次ホップ Remote Hub が設定されます。
ハブ 2 の IP プレフィックス (192.168.2.0/23) は引き続き Global Reach リンク経由で到達可能に見えますが、ハブ 2 内のデバイスにアドレス指定されたトラフィックは存在しないため、これがトラフィックに影響を与えることはありません。 ただし、相互に SDWAN トンネルを確立している NVA が両方のハブにある場合、このルートは問題になる可能性があります。
ただし、現在 10.4.2.0/24 が VPN Gateway よりも優先されることに注意してください。 これは、VPN 経由でアドバタイズされたルートの AS パスが ExpressRoute 経由でアドバタイズされたルートよりも短い場合に発生する可能性があります。 オンプレミスの VPN デバイスを構成し、自律システム番号 (65501) を VPN ルートの先頭に付加して、優先順位を下げた後で、ハブ 1 は、10.4.2.0/24 の次ホップとして ExpressRoute を選択するようになりました。
ハブ 2 には、有効なルートの同様のテーブルが表示されます。ここで、他のハブの VNet とブランチは次ホップとして Remote Hub を使用して表示されます。
シナリオ 3: ExpressRoute 回線を両方のハブにクロス接続する
Azure リージョンと、ExpressRoute 経由で接続されているオンプレミスの場所との間に直接リンクを追加するには、多くの場合、次のトポロジに示すように、単一の ExpressRoute 回線をトポロジ内の複数の Virtual WAN ハブに接続することをお勧めします。これは、"蝶ネクタイ型" と説明されることがあります。
重要
上の図は、2 つのセキュリティ保護付き仮想ハブを示しています。このトポロジはルーティング インテントでサポートされています。 詳細については、「Virtual WAN ハブのルーティング インテントとルーティング ポリシーの構成方法」をご覧ください。
Virtual WAN は、両方の回線が両方のハブに接続されていることを示します。
ExpressRoute の既定のハブ ルーティング優先順位に戻ると、ハブ 1 のリモート ブランチと VNet へのルートは、再び ExpressRoute が次ホップとして表示されます。 ただし、今回の理由は Global Reach ではなく、ExpressRoute 回線では、あるハブから取得したルート アドバタイズが別のハブに返されるという事実のためです。 たとえば、ハブ 1 の場合の ExpressRoute のハブ ルーティング優先を使用した有効なルートは次のようになります。
ハブ ルーティング設定を AS パスに戻すと、ハブ 1 と 2 の間の直接接続を使用するハブ間ルートが最適なパスに戻ります。
次のステップ
Virtual WAN の詳細については、次を参照してください。
- Virtual WAN の FAQ