シナリオ:VNet のカスタム分離

Virtual WAN の仮想ハブ ルーティングを使用する場合、多くのシナリオを利用できます。 VNet のカスタム分離シナリオでは、特定の VNet のセットが他の特定の VNet のセットに到達できないようにすることが目標です。 ただし、すべてのブランチ (VPN/ER/User VPN) に接続するには、VNet が必要です。 仮想ハブ ルーティングの詳細については、「仮想ハブのルーティングについて」を参照してください。

デザイン

必要なルート テーブルの数を確認するには、接続マトリックスを作成します。 このシナリオでは、次のようになります。各セルは、ソース (行) が宛先 (列) と通信できるかどうかを表します。

前の表の各マスは、Virtual WAN 接続 (フローの "ソース" 側、行ヘッダー) が宛先 (フローの "ターゲット" 側、斜体の列ヘッダー) と通信するかどうかを示しています。 このシナリオでは、ファイアウォールもネットワーク仮想アプライアンスも存在しないため、通信は Virtual WAN を介して直接行われます (そのため、表では "直接" という単語が使用されています)。

異なる行パターンの数は、このシナリオで必要になるルート テーブルの数になります。 この例では、仮想ネットワークの RT_BLUE と RT_RED、ブランチの Default とここでは呼ばれる、3 つのルートを持つルート テーブルです。 ブランチは常に Default ルーティング テーブルに関連付けられている必要があることに注意してください。

ブランチは、赤と青の両方の VNet からプレフィックスを学習する必要があるため、すべての VNet を Default (および RT_BLUE または RT_RED のいずれか) に伝達する必要があります。 青と赤の VNet は、ブランチのプレフィックスを学習する必要があるため、ブランチは RT_BLUE および RT_RED の両方のルート テーブルに伝達されます。 その結果、最終的な設計は次のようになります。

• 青の仮想ネットワーク:
  • 関連付けられたルート テーブル:RT_BLUE
  • ルート テーブルへの伝達:RT_BLUE および Default
• 赤の仮想ネットワーク:
  • 関連付けられたルート テーブル:RT_RED
  • ルート テーブルへの伝達:RT_RED および Default
• ブランチ:
  • 関連付けられたルート テーブル: [Default]
  • ルート テーブルへの伝達:RT_BLUE、RT_RED および Default

仮想ハブ ルーティングの詳細については、「仮想ハブのルーティングについて」を参照してください。

ワークフロー

図 1 には、青と赤の VNet 接続があります。

• 青の接続された Vnet は互いに通信できるだけでなく、すべてのブランチ (VPN/ER/P2S) 接続にも対応できます。
• 赤の Vnet は互いに通信できるだけでなく、すべてのブランチ (VPN/ER/P2S) 接続にも対応できます。

ルーティングを設定するときは、次の手順を考慮してください。

1. Azure portal に 2 つのカスタム ルート テーブルを作成し、RT_BLUE および RT_RED を作成します。
2. ルート テーブル RT_BLUE の場合、次の設定に従います。
   • Association: 青の VNet をすべて選択します。
   • Propagation: ブランチについては、ブランチのオプションを選択します。ブランチ (VPN/ER/P2S) 接続を暗黙的に指定することで、ルートはこのルート テーブルに伝達されます。
3. 赤の VNet とブランチ (VPN/ER/P2S) の RT_RED ルート テーブルについても同じ手順を繰り返します。

これにより、次の図に示すようにルーティング構成が変更されます。

図 1

次のステップ

• Virtual WAN の詳細については、FAQ を参照してください。
• 仮想ハブ ルーティングの詳細については、「仮想ハブのルーティングについて」を参照してください。