次の方法で共有

Virtual WAN ハブのルーティング インテントとルーティング ポリシーの構成方法

  • [アーティクル]

Virtual WAN ハブ ルーティング インテントを使用すると、シンプルな宣言型のルーティング ポリシーを設定して、Azure Firewall、ネットワーク仮想アプライアンス、または Virtual WAN ハブ内にデプロイされた SaaS (サービスとしてのソフトウェア) ソリューションなどの bump-in-the-wire 方式セキュリティ ソリューションにトラフィックを送信することができます。

背景

ルーティング インテントとルーティング ポリシーを使用すると、Virtual WAN ハブを構成して、インターネットへのトラフィックとプライベート (ポイント対サイト VPN、サイト間 VPN、ExpressRoute、Virtual Network、ネットワーク仮想アプライアンス) トラフィックを、Azure Firewall、次世代ファイアウォール (NGFW)、ネットワーク仮想アプライアンス (NVA)、または仮想ハブ内にデプロイされた SaaS (サービスとしてのソフトウェア) ソリューションに転送することができます。

ルーティング ポリシーには、インターネット トラフィックとプライベート トラフィックの 2 種類のルーティング ポリシーがあります。 各 Virtual WAN ハブは、最大で 1 つのインターネット トラフィック ルーティング ポリシーと 1 つのプライベート トラフィック ルーティング ポリシーを持つことができ、それぞれに 1 つネクスト ホップのリソースがあります。 プライベート トラフィックには、ブランチと Virtual Network の両方のアドレス プレフィックスが含まれますが、それらはルーティング ポリシーで、ルーティング インテントの概念の中の 1 つのエンティティと見なされます。

  • インターネット トラフィック ルーティング ポリシー: インターネット トラフィック ルーティング ポリシーが Virtual WAN ハブ上で構成されている場合、その Virtual WAN ハブへのすべてのブランチ (リモート ユーザー VPN (ポイント対サイト VPN)、サイト間 VPN、ExpressRoute) および仮想ネットワーク接続では、インターネットへのトラフィックは、ルーティング ポリシーの一部として指定された Azure Firewall、サード パーティのセキュリティ プロバイダー、ネットワーク仮想アプライアンス、SaaS ソリューションのいずれかに転送されます。

    つまり、インターネット トラフィック ルーティング ポリシーが Virtual WAN ハブ上で構成されていると、Virtual WAN は、(ハブまたはスポーク内にデプロイされている) すべてのスポーク、ゲートウェイ、ネットワーク仮想アプライアンスに対して既定 (0.0.0.0/0) ルートをアドバタイズします。

  • プライベート トラフィック ルーティング ポリシー: プライベート トラフィック ルーティング ポリシーが Virtual WAN ハブ上で構成されていると、ハブ間のトラフィックを含め、Virtual WAN ハブ内への、および外へのすべてのブランチおよび Virtual Network トラフィックは、ネクスト ホップの Azure Firewall、ネットワーク仮想アプライアンス、Saas ソリューション リソースのいずれかに転送されます。

    つまり、プライベート トラフィック ルーティング ポリシーが Virtual WAN ハブ上で構成されていると、ブランチ間、ブランチから仮想ネットワーク、仮想ネットワークからブランチ、およびハブ間のすべてのトラフィックが、Virtual WAN ハブ内にデプロイされた Azure Firewall、ネットワーク仮想アプライアンス、Saas ソリューションのいずれかを経由して送信されます。

使用例

次のセクションでは、セキュリティで保護された Virtual WAN ハブにルーティング ポリシーが適用される、2 つの一般的なシナリオを説明します。

すべての Virtual WAN ハブがセキュリティで保護される (Azure Firewall、NVA、または Saas ソリューションを使用してデプロイされる)

このシナリオでは、すべての Virtual WAN ハブが、Azure Firewall、NVA、または Saas ソリューションを内部に含んだ状態でデプロイされます。 このシナリオでは、インターネット トラフィック ルーティング ポリシー、プライベート トラフィック ルーティング ポリシー、またはその両方を、各 Virtual WAN ハブで構成できます。

セキュリティで保護された 2 つのハブを備えたアーキテクチャを示すスクリーンショット。

ハブ 1 とハブ 2 がプライベート トラフィックとインターネット トラフィックの両方に対してルーティング ポリシーを持つ次の構成を考えてみます。

ハブ 1 の構成:

  • ネクスト ホップがハブ 1 の Azure Firewall、NVA、または Saas ソリューションであるプライベート トラフィック ポリシー
  • ネクスト ホップがハブ 1 の Azure Firewall、NVA、または Saas ソリューションであるインターネット トラフィック ポリシー

ハブ 2 の構成:

  • ネクスト ホップがハブ 2 の Azure Firewall、NVA、または Saas ソリューションであるプライベート トラフィック ポリシー
  • ネクスト ホップがハブ 2 の Azure Firewall、NVA、または Saas ソリューションであるインターネット トラフィック ポリシー

このような構成の結果、トラフィック フローは次のようになります。

Note

既定ルート (0.0.0.0/0) はハブ間で伝達されないため、インターネット トラフィックは、ハブ内のローカルのセキュリティ ソリューション経由で送信される必要があります。

ソース 終了 ハブ 1 の VNet ハブ 1 のブランチ ハブ 2 の VNet ハブ 2 のブランチ インターネット
ハブ 1 の VNet → ハブ 1 の AzFW または NVA ハブ 1 の AzFW または NVA ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 1 の AzFW、NVA、または SaaS
ハブ 1 のブランチ → ハブ 1 の AzFW、NVA、または SaaS ハブ 1 の AzFW、NVA、または SaaS ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 1 の AzFW、NVA、または SaaS
ハブ 2 の VNet → ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS
ハブ 2 のブランチ → ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 1 および 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS

セキュリティ保護と通常の両方の Virtual WAN ハブのデプロイ

このシナリオでは、セキュリティで保護された Virtual WAN ハブ (セキュリティ ソリューションがデプロイされているハブ) ではないハブも WAN に存在します。

ハブ 1 (標準) とハブ 2 (セキュリティ保護) が 1 つの Virtual WAN にデプロイされている次の構成について考えてみます。 ハブ 2 には、プライベート トラフィックとインターネット トラフィックの両方のルーティング ポリシーがあります。

ハブ 1 の構成:

  • N/A (ハブが Azure Firewall、NVA、SaaS ソリューションのいずれかを使用してデプロイされていない場合は、ルーティング ポリシーを構成できません)

ハブ 2 の構成:

  • ネクスト ホップがハブ 2 の Azure Firewall、NVA、または Saas ソリューションであるプライベート トラフィック ポリシー。
  • ネクスト ホップがハブ 2 の Azure Firewall、NVA、または Saas ソリューションであるインターネット トラフィック ポリシー。

1 つのセキュリティ保護されたハブと 1 つの通常のハブを含むアーキテクチャを示すスクリーンショット。

このような構成の結果、トラフィック フローは次のようになります。 既定ルート (0.0.0.0/0) はハブ間で伝達されないため、ハブ 1 に接続されているブランチおよび仮想ネットワークは、ハブにデプロイされたセキュリティ ソリューション経由でインターネットにアクセスできません。

ソース 終了 ハブ 1 の VNet ハブ 1 のブランチ ハブ 2 の VNet ハブ 2 のブランチ インターネット
ハブ 1 の VNet → 直接 直接 ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS -
ハブ 1 のブランチ → 直接 直接 ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS -
ハブ 2 の VNet → ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS
ハブ 2 のブランチ → ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS ハブ 2 の AzFW、NVA、または SaaS

既知の制限事項

  • ルーティング インテントは現在、Azure パブリックで使用できます。 21Vianet とAzure Governmentによって運営される Microsoft Azure は、現在ロードマップに含まれています。
  • ルーティング インテントは、すべての接続 (Virtual Network、サイト間 VPN、ポイント対サイト VPN、ExpressRoute) のルート テーブルの関連付けと伝達を管理することでルーティングを簡略化します。 したがって、カスタム ルート テーブルおよびカスタマイズされたポリシーを使用する Virtual WAN は、ルーティング インテントのコンストラクトで使用できません。
  • VPN トンネル エンドポイント (サイト間 VPN Gateway のプライベート IP とオンプレミス VPN デバイスのプライベート IP) 間のトラフィックを許可するように Azure Firewall が構成されている場合、ルーティング インテントが構成されているハブでは、暗号化された ExpressRoute (ExpressRoute 回線上で実行されるサイト間 VPN トンネル) がサポートされます。 必要な構成の詳細については、ルーティング インテントを使用した暗号化された ExpressRoute に関する記事を参照してください。
  • 次の接続のユース ケースは、ルーティング インテントでサポートされていません。
    • Virtual Network 接続を指す defaultRouteTable 内の静的ルートは、ルーティング インテントと組み合わせて使用できません。 ただし、BGP ピアリング機能は使用できます。
    • "静的ルートの伝達" を使用した Virtual Network 接続上の静的ルートは、プライベート ルーティング ポリシー内で指定されたネクストホップ リソースには適用されません。 Virtual Network 接続上の静的ルートをプライベート ルーティング ポリシーのネクスト ホップに適用するためのサポートは、ロードマップに含まれています。
    • 現在、SD-WAN 接続 NVA と別個のファイアウォール NVA または SaaS ソリューションの両方を同じVirtual WAN ハブにデプロイする機能はロードマップにあります。 ネクスト ホップ SaaS ソリューションまたはファイアウォール NVA を使ってルーティング インテントを構成すると、SD-WAN NVA と Azure の間の接続が影響を受けます。 代わりに、SD-WAN NVA とファイアウォール NVA または SaaS ソリューションを異なる仮想ハブにデプロイします。 または、SD-WAN NVA をハブに接続されたスポーク Virtual Network にデプロイし、仮想ハブ BGP ピアリング機能を利用することもできます。
    • ルーティング インテントのネクスト ホップ リソースとしてネットワーク仮想アプライアンス (NVA) を指定できるのは、NVA が次世代ファイアウォールまたはデュアルロールの次世代ファイアウォールであり、SD-WAN NVA である場合のみです。 現在、ルーティング インテントのネクスト ホップとして構成できる NVA は、チェックポイント、fortinet-ngfw、および fortinet-ngfw-and-sdwan のみです。 別の NVA を指定しようとすると、ルーティング インテントを作成できません。 NVA のタイプをチェックするには、仮想ハブから> ネットワーク仮想アプライアンスに移動し、[ベンダー] フィールドを確認します。 Palo Alto Networks Cloud NGFW はルーティング インテントのネクスト ホップとしてもサポートされていますが、タイプが SaaS ソリューションのネクスト ホップと見なされます。
    • ルーティング インテント ユーザーが、複数の ExpressRoute 回線を Virtual WAN に接続し、それらの間で、ハブにデプロイされたセキュリティ ソリューション経由でトラフィックを送信する場合は、サポート ケースを開いて、このユース ケースを有効にすることができます。 詳細については、ExpressRoute 回線間の接続の有効化に関するセクションを参照してください。

仮想ネットワークのアドレス空間の制限

Note

1 つの Virtual WAN ハブに接続できる仮想ネットワークのアドレス空間の最大数は調整可能です。 制限の引き上げを要求するには、Azure サポート ケースを開いてください。 制限は、Virtual WAN ハブ レベルで適用されます。 制限の引き上げが必要な Virtual WAN ハブが複数ある場合は、Virtual WAN デプロイ内のすべての Virtual WAN ハブに対して制限の引き上げを要求してください。

ルーティング インテントを使用しているお客様の場合、1 つの Virtual WAN ハブに直接接続されたすべての仮想ネットワーク全体のアドレス空間の最大数は 400 です。 この制限は、Virtual WAN デプロイ内の各 Virtual WAN ハブに個別に適用されます。 リモート ハブ (同じ Virtual WAN 内の他の Virtual WAN ハブ) に接続された仮想ネットワークのアドレス空間は、この制限にカウントされません。

ハブに直接接続された仮想ネットワークのアドレス空間の数が制限を超えた場合、仮想ハブでのルーティング インテントの有効化または更新は失敗します。 ルーティング インテントが既に構成されているハブで、仮想ネットワークのアドレス空間の更新などの操作の結果として仮想ネットワークのアドレス空間が制限を超える場合、新しく接続されたアドレス空間はルーティングできない可能性があります。

ローカルに接続されたすべての仮想ネットワークのアドレス空間の合計数が文書化された制限の 90% を超える場合、または仮想ネットワークのアドレス空間の数を制限を超えて増やすネットワーク拡張または展開操作を計画している場合は、事前に制限の引き上げを要求してください。

次の表に、仮想ネットワークのアドレス空間の計算例を示します。

仮想ハブ 仮想ネットワーク数 仮想ネットワークあたりのアドレス空間 仮想ハブに接続されている仮想ネットワークのアドレス空間の合計数 推奨アクション
ハブ #1 200 1 200 アクションは必要ありません。アドレス空間の数を監視します。
ハブ #2 150 3 450 制限の引き上げを要求して、ルーティング インテントを使用します。
ハブ #3 370 1 370 制限の引き上げを要求します。

次の PowerShell スクリプトを使用すると、1 つの Virtual WAN ハブに接続された仮想ネットワーク内のアドレス空間の数を概算できます。 Virtual WAN 内のすべての Virtual WAN ハブに対してこのスクリプトを実行します。 接続された仮想ネットワークのアドレス空間のアラートを追跡および構成するための Azure Monitor メトリックがロードマップに含まれています。

環境に合わせてスクリプト内の Virtual WAN ハブのリソース ID を変更してください。 テナント間の仮想ネットワーク接続がある場合は、接続された仮想ネットワーク リソースだけでなく、Virtual WAN 仮想ネットワーク接続オブジェクトを読み取るための十分なアクセス許可があることを確認してください。

$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
  
foreach($connection in $hubVNETconnections) {
  try{
    $resourceURI = $connection.RemoteVirtualNetwork.Id
    $RG = ($resourceURI -split "/")[4]
    $name = ($resourceURI -split "/")[8]
    $VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
    $addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
  }
  catch{
    Write-Host "An error ocurred  while processing VNET connected to Virtual WAN hub with resource URI:  " -NoNewline
    Write-Host $resourceURI 
    Write-Host "Error Message: " -ForegroundColor Red
    Write-Host $_.Exception.Message -ForegroundColor Red 
  }
  finally{
  }
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green

考慮事項

現在、ルーティング インテントなしで Virtual WAN ハブで Azure Firewall を使用しているお客様は、Azure Firewall Manager、Virtual WAN ハブ ルーティング ポータルを使用して、または他の Azure 管理ツール (PowerShell、CLI、REST API) 経由でルーティング インテントを有効にすることができます。

ルーティング インテントを有効にする前に、次の点を考慮してください。

  • ルーティング インテントは、カスタム ルート テーブルがなく、defaultRouteTable に静的ルートがなく、ネクスト ホップが Virtual Network 接続であるハブでのみ構成できます。 詳細については、「前提条件」を参照してください。
  • ルーティング インテントを有効にする前に、ゲートウェイ、接続、ルート テーブルのコピーを保存してください。 以前の構成がシステムで自動的に保存され、適用されることはありません。 詳細については、「ロールバック戦略」を参照してください。
  • ルーティング インテントにより、defaultRouteTable 内の静的ルートが変更されます。 Azure portal の最適化により、REST、CLI、または PowerShell を使用してルーティング インテントを構成した場合は、ルーティング インテントを構成した後の defaultRouteTable の状態が異なる場合があります。 詳細については、静的ルートに関するセクションを参照してください。
  • ルーティング インテントを有効にすると、オンプレミスへのプレフィックスのアドバタイズに影響します。 詳細については、プレフィックスのアドバタイズに関するセクションを参照してください。
  • サポート ケースを開いて、ハブ内のファイアウォール アプライアンス経由で ExpressRoute 回線間の接続を有効にすることができます。 この接続パターンを有効にすると、ExpressRoute 回線にアドバタイズされるプレフィックスが変更されます。 詳細については、ExpressRoute に関するセクションを参照してください。
  • ルーティング インテントは、ハブにデプロイされたセキュリティ アプライアンスを介してハブ間トラフィック検査を有効にする Virtual WAN の唯一のメカニズムです。 ハブ間トラフィック検査では、Virtual WAN ハブにデプロイされたセキュリティ アプライアンス間でトラフィックが対称的にルーティングされるように、すべてのハブでルーティング インテント意図を有効にする必要もあります。
  • ルーティング インテントは、仮想ネットワークとオンプレミスのトラフィックを、ルーティング ポリシーで指定されたネクスト ホップ リソースに送信します。 Virtual WAN は、構成されたルーティング ポリシーに従ってオンプレミスと Virtual Network トラフィックをルーティングするように基盤 Azure プラットフォームをプログラムするため、仮想ハブ ルーター経由ではトラフィックを処理しません。 ルーティング インテント経由でルーティングされたパケットはルーターによって処理されないため、ルーティング インテントが構成されたハブ上では、データプレーン パケット転送用に追加のルーティング インフラストラクチャ ユニットを割り当てる必要はありません。 ただし、Virtual WAN ハブに接続されている仮想ネットワーク内の仮想マシンの数に応じて、追加のルーティング インフラストラクチャ ユニットを割り当てる必要がある場合があります。
  • ルーティング インテントを使用すると、プライベート ルーティング ポリシーとインターネット ルーティング ポリシーに異なるネクスト ホップ リソースを構成できます。 たとえば、プライベート ルーティング ポリシーのネクスト ホップをハブ内の Azure Firewall に設定し、インターネット ルーティング ポリシーのネクスト ホップをハブ内の NVA または SaaS ソリューションに設定することができます。 SaaS ソリューションとファイアウォール NVA は Virtual WAN ハブ内の同じサブネットにデプロイされるため、SaaS ソリューションとファイアウォール NVA を同じハブ内にデプロイすると、水平スケールアウトに使用できる IP アドレスが少なくなり、SaaS ソリューションの水平方向のスケーラビリティに影響が出る可能性があります。さらに、各 Virtual WAN ハブにデプロイできる SaaS ソリューションは最大 1 つです。

前提条件

ルーティング インテントとルーティング ポリシーを有効にするには、仮想ハブが、次の前提条件を満たしている必要があります。

  • 仮想ハブと共にデプロイされるカスタム ルート テーブルはありません。 存在するルート テーブルは、noneRouteTable と defaultRouteTable のみです。
  • 静的ルートのネクスト ホップを Virtual Netwok 接続にすることはできません。 defaultRouteTable 内の静的ルートのネクスト ホップを Azure Firewall にすることはできます。

上記の要件を満たしていないハブでは、ルーティング インテントを構成するオプションがグレー表示されます。

Azure Firewall Manager でルーティング インテントを使用する (ハブ間オプションを有効にする) 場合は、さらに要件があります。

  • Azure Firewall Manager によって作成されたルートは、private_traffic、internet_traffic、または all_traffic の名前付け規則に従います。 したがって、defaultRouteTable 内のすべてのルートは、この規則に従う必要があります。

ロールバック戦略

Note

ルーティング インテントの構成がハブから完全に削除されると、ハブへのすべての接続が、既定のラベルに伝達されるように設定されます (これは、Virtual WAN 内の "すべての" defaultRouteTables に適用されます)。 そのため、Virtual WAN にルーティング インテントを実装することを検討している場合は、元の構成に戻す場合に適用する既存の構成 (ゲートウェイ、接続、ルート テーブル) のコピーを保存しておく必要があります。 以前の構成がシステムで自動的に復元されることはありません。

ルーティング インテントにより、ハブ内のすべての接続のルートの関連付けと伝達が管理されて、ルーティングと構成が簡素化されます。

次の表では、ルーティング インテントが構成された後の、すべての接続に関連付けられているルート テーブルと伝達されたルート テーブルについて説明します。

ルーティング インテントの構成 関連付けられたルート テーブル 伝達されたルート テーブル
インターネット defaultRouteTable 既定のラベル (Virtual WAN 内のすべてのハブの defaultRouteTable)
プライベート defaultRouteTable noneRouteTable
インターネットとプライベート defaultRouteTable noneRouteTable

defaultRouteTable の静的ルート

次のセクションでは、ルーティング インテントがハブで有効になっている場合に、defaultRouteTable の静的ルートがルーティング インテントでどのように管理されるかを説明します。 ルーティング インテントで defaultRouteTable に加えられた変更は、元に戻すことができません。

ルーティング インテントを削除する場合は、以前の構成を手動で復元する必要があります。 したがって、ルーティング インテントを有効にする前に、構成のスナップショットを保存することをお勧めします。

Azure Firewall Manager と Virtual WAN ハブ ポータル

ルーティング インテントをハブで有効にすると、構成されたルーティング ポリシーに対応する静的ルートが自動的に defaultRouteTable に作成されます。 これらのルートは次のとおりです。

ルート名 プレフィックス ネクスト ホップ リソース
_policy_PrivateTraffic 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 Azure Firewall
_policy_PublicTraffic 0.0.0.0/0 Azure Firewall

注意

defaultRouteTable 内の静的ルートのうち、0.0.0.0/0 と RFC1918 スーパーネット (10.0.0.0/8、192.168.0.0/16、および 172.16.0.0/12) のどちらとも正確に一致しないプレフィックスを含むものはどれも、private_traffic という名前の単一の静的ルートに自動的に統合されます。 RFC1918 スーパーネットまたは 0.0.0.0/0 と一致する、defaultRouteTable 内のプレフィックスは、ポリシーの種類に関係なく、ルーティング インテントが構成されると、常に自動的に削除されます。

たとえば、ルーティング インテントを構成する前に、次のルートが defaultRouteTable にあるシナリオを考えてみます。

ルート名 プレフィックス ネクスト ホップ リソース
private_traffic 192.168.0.0/16、172.16.0.0/12、40.0.0.0/24、10.0.0.0/24 Azure Firewall
to_internet 0.0.0.0/0 Azure Firewall
additional_private 10.0.0.0/8、50.0.0.0/24 Azure Firewall

このハブでルーティング インテントを有効にすると、defaultRouteTable が、次の終了状態になります。 RFC1918 および 0.0.0.0/0 以外のプレフィックスはすべて、private_traffic という名前の 1 つのルートに統合されます。

ルート名 プレフィックス ネクスト ホップ リソース
_policy_PrivateTraffic 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 Azure Firewall
_policy_PublicTraffic 0.0.0.0/0 Azure Firewall
private_traffic 40.0.0.0/24、10.0.0.0/24、50.0.0.0/24 Azure Firewall

その他のメソッド (PowerShell、REST、CLI)

ポータル以外のメソッドを使用してルーティング インテントを作成すると、対応するポリシー ルートが defaultRouteTable に自動的に作成され、さらに、0.0.0.0/0 または RFC1918 スーパーネット (10.0.0.0/8、192.168.0.0/16、または 172.16.0.0/12) と正確に一致するプレフィックスを含む静的ルートがすべて削除されます。 ただし、他の静的ルートは自動的には統合されません。

たとえば、ルーティング インテントを構成する前に、次のルートが defaultRouteTable にあるシナリオを考えてみます。

ルート名 プレフィックス ネクスト ホップ リソース
firewall_route_ 1 10.0.0.0/8 Azure Firewall
firewall_route_2 192.168.0.0/16、10.0.0.0/24 Azure Firewall
firewall_route_3 40.0.0.0/24 Azure Firewall
to_internet 0.0.0.0/0 Azure Firewall

次の表は、ルーティング インテントが正常に作成された後の defaultRouteTable の最終状態を表しています。 firewall_route_1 と to_internet は、唯一のプレフィックスが 10.0.0.0/8 と 0.0.0.0/0 のみであったため、自動的に削除されています。 firewall_route_2 は RFC1918 集約プレフィックスであるため、変更されて、192.168.0.0/16 が削除されています。

ルート名 プレフィックス ネクスト ホップ リソース
_policy_PrivateTraffic 10.0.0.0/8、192.168.0.0/16、172.16.0.0/12 Azure Firewall
_policy_PublicTraffic 0.0.0.0/0 Azure Firewall
firewall_route_2 10.0.0.0/24 Azure Firewall
firewall_route_3 40.0.0.0/24 Azure Firewall

オンプレミスへのプレフィックス アドバタイズ

次のセクションでは、仮想ハブでルーティング インテントが構成された後に、どのように Virtual WAN でルートがオンプレミスにアドバタイズされるかを説明します。

インターネット ルーティング ポリシー

注意

既定のルート 0.0.0.0/0 は仮想ハブ間でアドバタイズされません。

仮想ハブでインターネット ルーティング ポリシーを有効にした場合は、既定のルート 0.0.0.0/0 によって、そのハブへのすべての接続 (Virtual Network ExpressRoute、サイト間 VPN、ポイント対サイト VPN、ハブ内の NVA、BGP の各接続) にアドバタイズされます。これらの接続では、[既定のルートの伝達] または [インターネット セキュリティを有効にする] フラグが true に設定されています。 既定のルートを学習してはならないすべての接続では、このフラグを false に設定できます。

プライベート ルーティング ポリシー

プライベート ルーティング ポリシーを使用して仮想ハブが構成されている場合は、Virtual WAN によって、次の方法でローカルのオンプレミス接続にルートがアドバタイズされます。

  • ローカル ハブの Virtual Network、ExpressRoute、サイト間 VPN、ポイント対サイト VPN、ハブ内の NVA、または BGP の各接続のうち、現在のハブに接続されているものから学習されたプレフィックスに対応するルート。
  • リモート ハブの Virtual Network、ExpressRoute、サイト間 VPN、ポイント対サイト VPN、ハブ内の NVA、または BGP の各接続のうち、プライベート ルーティング ポリシーが構成されているものから学習されたプレフィックスに対応するルート。
  • リモート ハブの Virtual Network、ExpressRoute、サイト間 VPN、ポイント対サイト VPN、ハブ内の NVA、または BGP の各接続のうち、ルーティング インテントが構成されいないと同時に、リモート接続によってローカル ハブの defaultRouteTable に伝達されるものから学習されたプレフィックスに対応するルート。
  • 1 つの ExpressRoute 回線から学習されたプレフィックスは、Global Reach が有効になっていない限り、他の ExpressRoute 回線にはアドバタイズされません。 ハブにデプロイされたセキュリティ ソリューションを介して ExpressRoute から ExpressRoute への転送 (トランジット) を有効にする場合は、サポート ケースを開いてください。 詳細については、ExpressRoute 回線間の接続の有効化に関するセクションを参照してください。

主要なルーティングのシナリオ

次のセクションでは、Virtual WAN ハブでルーティング インテントを構成する際のいくつかの主要なルーティングのシナリオとルーティングの動作について説明します。

ルーティング インテントを使用した ExpressRoute 回線間のトランジット接続

Virtual WAN 内の ExpressRoute 回線間のトランジット接続は、2 つの異なる構成を介して提供されます。 これらの 2 つの構成には互換性がないため、2 つの ExpressRoute 回線間のトランジット接続をサポートするには、顧客が 1 つの構成オプションを選択する必要があります。

Note

プライベート ルーティング ポリシーを使用してハブ内のファイアウォール アプライアンス経由で ExpressRoute から ExpressRoute へのトランジット接続を有効にするには、Microsoft サポートでサポート ケースを開いてください。 このオプションは Global Reach と互換性がないため、Virtual WAN に接続されているすべての ExpressRoute 回線間の適切なトランジット ルーティングを確保するには、Global Reach を無効にする必要があります。

  • ExpressRoute Global Reach: ExpressRoute Global Reach を使用すると、2 つの Global Reach 対応回線が仮想ハブを通過することなく、相互に直接トラフィックを送信できます。
  • ルーティング意図のプライベート ルーティング ポリシー: プライベート ルーティング ポリシーを構成すると、2 つの ExpressRoute 回線がハブにデプロイされたセキュリティ ソリューションを介して相互にトラフィックを送信できます。

次の構成では、ルーティング意図のプライベート ルーティング ポリシーを使用するハブ内のファイアウォール アプライアンス経由での ExpressRoute 回線間の接続を使用できます。

  • 両方の ExpressRoute 回線が、同じハブに接続されており、そのハブでプライベート ルーティング ポリシーが構成されています。
  • ExpressRoute 回線が異なるハブに接続されており、両方のハブでプライベート ルーティング ポリシーが構成されています。 したがって、両方のハブにセキュリティ ソリューションがデプロイされている必要があります。

ExpressRoute でのルーティングに関する考慮事項

注意

以下のルーティングに関する考慮事項は、Microsoft サポートによって有効になっているサブスクリプション内のすべての仮想ハブに適用され、ハブ内のセキュリティ アプライアンスを介して ExpressRoute に ExpressRoute 接続を許可します。

仮想ハブにデプロイされたファイアウォール アプライアンスを使用した ExpressRoute 回線間のトランジット接続が有効になった後は、オンプレミスの ExpressRoute にルートがアドバタイズされる際の動作が、次のように変化することを想定できます。

  • Virtual WAN により RFC1918 集約プレフィックス (10.0.0.0/8、192.168.0.0/16、172.16.0.0/12) が、ExpressRoute に接続されたオンプレミスに自動的にアドバタイズされます。 これらの集約ルートは、前のセクションで説明したルートに加えてアドバタイズされます。
  • Virtual WAN により、defaultRouteTable 内のすべての静的ルートが、ExpressRoute 回線に接続されたオンプレミスに自動的にアドバタイズされます。 つまり、Virtual WAN によって、[プライベート トラフィック プレフィックス] テキスト ボックスで指定されたルートがオンプレミスにアドバタイズされます。

これらのルート アドバタイズの変更により、これは、ExpressRoute に接続されたオンプレミスが、RFC1918 集約アドレス範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) の正確なアドレス範囲をアドバタイズできないことを意味します。 [プライベート トラフィック] テキスト ボックス内の集約スーパーネットやプレフィックスとは異なり、より具体的なサブネット (RFC1918 の範囲内) をアドバタイズしていることを確認してください。

さらに、ExpressRoute 回線が RFC1918 以外のプレフィックスを Azure にアドバタイズしている場合は、[プライベート トラフィック プレフィックス] テキスト ボックスに入力するアドレス範囲が ExpressRoute でアドバタイズされたルートより一般的であることを確認してください。 たとえば、ExpressRoute 回線がオンプレミスから 40.0.0.0/24 をアドバタイズする場合、[Private Traffic Prefixes] (プライベート トラフィック プレフィックス) テキストボックスに a/23 CIDR 範囲以上を入力します (例: 40.0.0.0/23)。

他のオンプレミスへのルート アドバタイズ (サイト間 VPN、ポイント対サイト VPN、NVA) は、ハブにデプロイされたセキュリティ アプライアンスを経由した ExpressRoute から ExpressRoute へのトランジット接続を有効にしても影響を受けません。

暗号化された ExpressRoute

ルーティング インテントのプライベート ルーティング ポリシーで暗号化された ExpressRoute (ExpressRoute 回線経由のサイト間 VPN トンネル) を使用するには、Virtual WAN サイト間 VPN Gateway (ソース) とオンプレミス VPN デバイス (宛先) のトンネル プライベート IP アドレス間のトラフィックを許可するようにファイアウォール規則を構成します。 ファイアウォール デバイスでディープ パケット検査を使用している顧客には、これらのプライベート IP 間のトラフィックをディープ パケット検査から除外することをお勧めします。

VPN 構成をダウンロードし、vpnSiteConnections -> gatewayConfiguration -> IPAddresses を表示することで、Virtual WAN サイト間 VPN Gateway のトンネル プライベート IP アドレスを取得できます。 [IPAddresses] フィールドにリストされている IP アドレスは、ExpressRoute 経由の VPN トンネルを終了するために使用されるサイト間 VPN Gateway の各インスタンスに割り当てられたプライベート IP アドレスです。 下の例では、ゲートウェイ上のトンネル IP は 192.168.1.4 と 192.168.1.5 です。

 "vpnSiteConnections": [
      {
        "hubConfiguration": {
          "AddressSpace": "192.168.1.0/24",
          "Region": "South Central US",
          "ConnectedSubnets": [
            "172.16.1.0/24",
            "172.16.2.0/24",
            "172.16.3.0/24",
            "192.168.50.0/24",
            "192.168.0.0/24"
          ]
        },
        "gatewayConfiguration": {
          "IpAddresses": {
            "Instance0": "192.168.1.4",
            "Instance1": "192.168.1.5"
          },
          "BgpSetting": {
            "Asn": 65515,
            "BgpPeeringAddresses": {
              "Instance0": "192.168.1.15",
              "Instance1": "192.168.1.12"
            },
            "CustomBgpPeeringAddresses": {
              "Instance0": [
                "169.254.21.1"
              ],
              "Instance1": [
                "169.254.21.2"
              ]
            },
            "PeerWeight": 0
          }
        }

オンプレミス デバイスが VPN 終了に使用するプライベート IP アドレスは、VPN サイト リンク接続の一部として指定された IP アドレスです。

VPN サイトのオンプレミス デバイスのトンネル IP アドレスを示すスクリーンショット。

上記のサンプル VPN 構成と VPN サイトを使用して、次のトラフィックを許可するファイアウォール規則を作成します。 VPN Gateway の IP はソース IP である必要があり、オンプレミスの VPN デバイスは構成された規則内の宛先 IP である必要があります。

規則のパラメーター 値
ソース IP 192.168.1.4 と 192.168.1.5
発信元ポート *
宛先 IP 10.100.0.4
宛先ポート *
Protocol ANY

暗号化された ExpressRoute のパフォーマンス

暗号化された ExpressRoute を使用してプライベート ルーティング ポリシーを構成すると、VPN ESP パケットが、ハブにデプロイされたネクスト ホップ セキュリティ アプライアンス経由でルーティングされます。 その結果、両方向 (オンプレミスからの受信と Azure からの送信) で 1 Gbps という暗号化された ExpressRoute の最大 VPN トンネル スループットを期待できます。 最大 VPN トンネル スループットを実現するには、次のデプロイの最適化を検討してください。

  • Azure Firewall Standard または Azure Firewall Basic の代わりに Azure Firewall Premium をデプロイします。
  • 最初に、VPN トンネル エンドポイント (上記の例では 192.168.1.4 と 192.168.1.5) 間のトラフィックを許可する規則を Azure Firewall ポリシー内の最優先項目にすることによって、その規則が Azure Firewall で確実に処理されるようにします。 Azure Firewall 規則の処理ロジックの詳細については、Azure Firewall 規則の処理ロジックに関するページを参照してください。
  • VPN トンネル エンドポイント間のトラフィックのディープパケットをオフにします。 ディープ パケット検査からトラフィックを除外するように Azure Firewall を構成する方法については、IDPS バイパス リストのドキュメントを参照してください。
  • IPSEC の暗号化と整合性の両方に GCMAES256 を使用してパフォーマンスを最大化するように VPN デバイスを構成します。

接続とファイアウォール用のデュアルロール NVA の NVA インスタンスへの直接ルーティング

Note

Virtual WAN 内でプライベート ルーティング ポリシーと共に使用されるデュアルロール NVA への直接ルーティングの適用対象は、Virtual WAN ハブ内にデプロイされた NVA から BGP 経由で学習された仮想ネットワークとルート間のトラフィックだけです。 NVA に接続されたオンプレミスへの ExpressRoute および VPN トランジット接続は、NVA インスタンスに直接ルーティングされるのではなく、デュアルロール NVA のロード バランサー経由でルーティングされます。

特定のネットワーク仮想アプライアンスは、同じデバイス上に接続 (SD-WAN) とセキュリティ (NGFW) の両方の機能を持つことができます。 これらの NVA は、デュアルロール NVA と見なされます。 「NVA パートナー」で、使用中の NVA がデュアルロール NVA であるかどうかを確認してください。

デュアルロール NVA 用のプライベート ルーティング ポリシーが構成されている場合、Virtual WAN は、NVA 内部ロード バランサーとは異なり、その Virtual WAN ハブの NVA デバイスから学習したルートを、NVA インスタンスとしてネクスト ホップを使用して、Virtual WAN 内のその他の仮想ハブだけでなく、直接接続された (ローカル) Virtual Network にも自動的にアドバタイズします。

NVA の 1 つのインスタンスのみが特定のプレフィックスのルートを Virtual WAN にアドバタイズしている (または、いずれかのインスタンスから学習したルートの AS-PATH 長が常に最短である) アクティブ/パッシブ NVA 構成の場合、Virtual WAN は Azure Virtual Network からのアウトバウンド トラフィックが常にアクティブ (または優先) NVA インスタンスにルーティングされることを保証します。

アクティブ/パッシブ NVA のルーティング パターンを示すスクリーンショット。

(複数の NVA インスタンスが同じプレフィックスを同じ AS-PATH 長でアドバタイズする) アクティブ/アクティブ NVA 構成の場合、Azure は ECMP を自動的に実行して Azure からオンプレミスへのトラフィックをルーティングします。 Azure のソフトウェアによるネットワーク制御プラットフォームでは、フローレベルの対称性は保証されていません。つまり、Azure へのインバウンド フローと Azure からのアウトバウンド フローは、異なる NVA インスタンスに送信される可能性があります。 これにより、ステートフル ファイアウォール検査によってドロップされる非対称ルーティングが発生します。 そのため、NVA で非対称転送をサポートするか、セッションの共有/同期をサポートすることが出来ない限りは、NVA がデュアルロール NVA として動作している場合に、アクティブ/アクティブ接続パターンを使用することは推奨されません。 使用中の NVA が非対称転送またはセッション状態の共有/同期をサポートしているかどうかの詳細については、使用中の NVA のプロバイダーにお問い合わせください。

アクティブ/アクティブ NVA のルーティング パターンを示すスクリーンショット。

Azure portal を使用したルーティング インテントの構成

ルーティング インテントとルーティング ポリシーは、Azure portal を介して、Azure Firewall Manager または Virtual WAN ポータルを使って構成できます。 Azure Firewall Manager ポータルでは、ネクスト ホップ リソースの Azure Firewall を使ってルート ポリシーを構成できます。 Virtual WAN ポータルでは、ネクスト ホップ リソースである Azure Firewall、仮想ハブ内にデプロイされたネットワーク仮想アプライアンス、または SaaS ソリューションを使ってルーティング ポリシーを構成できます。

Virtual WAN で保護されたハブで Azure Firewall を使っているお客様は、Azure Firewall Manager の [Enable inter-hub] (ハブ間を有効にする) 設定を [有効] に設定してルーティング インテントを使うか、Virtual WAN ポータルを使ってルーティング インテントとポリシーのネクスト ホップ リソースとして Azure Firewall を直接構成することができます。 どちらのポータル エクスペリエンスでも構成は同等であり、Azure Firewall Manager での変更は Virtual WAN ポータルに自動的に反映されます。また、その逆も同様です。

Azure Firewall Manager を使用してルーティング インテントとルーティング ポリシーを構成する

次の手順は、Azure Firewall Manager を使用して仮想ハブでルーティング インテントとルーティング ポリシーを構成する方法を説明しています。 Azure Firewall Manager では、タイプ Azure Firewall のネクスト ホップ リソースのみがサポートされています。

  1. ルーティング ポリシーを構成する Virtual WAN ハブに移動します。

  2. [セキュリティ] で [セキュリティ保護付き仮想ハブの設定] を、次に [このセキュリティ保護付き仮想ハブのセキュリティ プロバイダーとルートの設定を Azure Firewall Manager で管理する] を選択します。 セキュリティ保護付きハブを変更する方法を示すスクリーンショット。

  3. ルーティング ポリシーを構成するハブをメニューから選択します。

  4. [設定] の [セキュリティの構成] を選択します。

  5. インターネット トラフィック ルーティング ポリシーを構成する場合、 [Internet Traffic](インターネット トラフィック) で [Azure Firewall] または関連するインターネット セキュリティ プロバイダーを選択します。 そうでない場合は、 [なし] を選択します。

  6. Azure Firewall 経由で (ブランチおよび仮想ネットワーク トラフィックの) プライベート トラフィック ルーティング ポリシーを構成する場合、 [Private Traffic](プライベート トラフィック) .のドロップダウンから [Azure Firewall] を選択します。 そうでない場合は、 [Bypass Azure Firewall](Azure Firewall をバイパスする) を選択します。

    ルーティング ポリシーの構成方法を示すスクリーンショット。

  7. プライベート トラフィック ルーティング ポリシーを構成し、IANA 以外の RFC1918 プレフィックスをアドバタイズするブランチまたは仮想ネットワークを使用する場合は、 [Private Traffic Prefixes](プライベート トラフィック プレフィックス) を選択し、表示されるテキスト ボックスに IANA 以外の RFC1918 プレフィックス範囲を指定します。 [Done] を選択します。

    プライベート トラフィック プレフィックスを編集する方法を示すスクリーンショット。

  8. [Inter-hub](ハブ間) で [有効] を選択します。 このオプションを有効にすると、この Virtual WAN ハブのルーティング インテントにルーティング ポリシーが確実に適用されます。

  9. [保存] を選択します。

  10. ルーティング ポリシーを構成するその他のセキュリティで保護された Virtual WAN ハブに対して手順 2 から 8 を繰り返します。

  11. この時点で、テスト トラフィックを送信する準備ができています。 必要なセキュリティ構成に基づいてトラフィックを許可または拒否するようにファイアウォール ポリシーが適切に構成されていることを確認してください。

Virtual WAN ポータルを使用してルーティング インテントとルーティング ポリシーを構成する

次の手順は、Virtual WAN ポータルを使用して仮想ハブでルーティング インテントとルーティング ポリシーを構成する方法を説明しています。

  1. 「前提条件」セクションの手順 3 の確認メールに記載されているカスタム ポータル リンクから、ルーティング ポリシーを構成する Virtual WAN ハブに移動します。

  2. [ルーティング] の [ルーティング ポリシー] を選択します。

    ルーティング ポリシーへの移動方法を示すスクリーンショット。

  3. プライベート トラフィック ルーティング ポリシー (ブランチと Virtual Network トラフィックの) を構成する場合は、[プライベート トラフィック] で [Azure Firewall]、[ネットワーク仮想アプライアンス]、または [SaaS ソリューション] を選択します。 [ネクスト ホップ リソース] で、関連するネクスト ホップ リソースを選択します。

    NVA プライベート ルーティング ポリシーの構成方法を示すスクリーンショット。

  4. プライベート トラフィック ルーティング ポリシーを構成し、IANA 以外の RFC1918 プレフィックスを使用するブランチまたは仮想ネットワークを使用する場合は、[Additional Prefixes](追加のプレフィックス) を選択し、表示されるテキスト ボックスに IANA 以外の RFC1918 プレフィックス範囲を指定します。 [Done] を選択します。 プライベート ルーティング ポリシーで構成されているすべての仮想ハブの [プライベート トラフィック プレフィックス] テキスト ボックスに同じプレフィックスを追加して、正しいルートがすべてのハブにアドバタイズされるようにします。

    NVA ルーティング ポリシーの追加プライベート プレフィックスを構成する方法を示すスクリーンショット。

  5. インターネット トラフィック ルーティング ポリシーを構成する場合は、[Azure Firewall]、[ネットワーク仮想アプライアンス]、または [SaaS ソリューション] を選択します。 [ネクスト ホップ リソース] で、関連するネクスト ホップ リソースを選択します。

    NVA のパブリック ルーティング ポリシーの構成方法を示すスクリーンショット。

  6. ルーティング インテントとルーティング ポリシーの構成を適用するために、[保存] をクリックします。

    ルーティング ポリシーの構成を保存する方法を示すスクリーンショット。

  7. ルーティング ポリシーを構成するすべてのハブについて、この手順を繰り返します。

  8. この時点で、テスト トラフィックを送信する準備ができています。 ファイアウォール ポリシーが適切に構成されており、必要なセキュリティ構成に基づいてトラフィックが許可されるか、拒否されることを確認してください。

BICEP テンプレートを使用してルーティング意図を構成する

テンプレートと手順については、BICEP テンプレートを参照してください。

トラブルシューティング

次のセクションでは、Virtual WAN Hub でルーティング インテントとルーティング ポリシーを構成するときにトラブルシューティングを行う一般的な方法を説明します。

有効なルート

Note

Virtual WAN ルーティング インテントのネクスト ホップ リソース上に適用される有効なルートの取得は、プライベート ルーティング ポリシー内で指定されたネクスト ホップ リソースに対してのみサポートされます。 プライベートおよびインターネットのルーティング ポリシーを両方使用している場合、インターネット ルーティング ポリシーのネクスト ホップ リソース上に Virtual WAN によってプログラムされた有効なルートについては、プライベート ルーティング ポリシー内で指定されたネクスト ホップ リソース上の有効なルートを確認してください。 インターネット ルーティング ポリシーのみを使用している場合は、defaultRouteTable 上の有効なルートを確認して、インターネット ルーティング ポリシーのネクスト ホップ リソース上にプログラムされたルートを表示します。

仮想ハブ上にプライベート ルーティング ポリシーが構成されている場合は、オンプレミスと仮想ネットワークの間のすべてのトラフィックが、その仮想ハブで Azure Firewall、ネットワーク仮想アプライアンス、または SaaS ソリューションによって検査されます。

したがって、defaultRouteTable の有効なルートには、RFC1918 集計プレフィックス (10.0.0.0/8、192.168.0.0/16、172.16.0.0/12) とネクスト ホップ Azure Firewall またはネットワーク仮想アプライアンスが表示されます。 これは、Virtual Network とブランチの間のすべてのトラフィックが、ハブ内の Azure Firewall、NVA、または SaaS ソリューションにルーティングされて検査されることを表します。

defaultRouteTable の有効なルートを示すスクリーンショット。

ファイアウォールがパケットを検査した (そして、ファイアウォール規則の構成ごとにパケットが許可された) 後、Virtual WAN によりパケットが最後の転送先に転送されます。 検査済みパケットの転送に Virtual WAN が使用するルートを確認するには、ファイアウォールまたはネットワーク仮想アプライアンスの有効なルート テーブルを表示します。

Azure Firewall の有効なルートを示すスクリーンショット。

ファイアウォールの有効なルート テーブルは、ネットワーク内の問題 (構成の誤り、特定のブランチや Virtual Network に関する問題など) を絞り込んで分離するのに役立ちます。

構成の問題のトラブルシューティング

構成の問題のトラブルシューティングを行っている場合は、次の点を考慮してください。

  • defaultRouteTable に、ネクスト ホップ Virtual Network 接続を含むカスタム ルート テーブルと静的ルートがどちらも含まれていないことを確認します。
    • デプロイが上記の要件を満たしていない場合は、ルーティング インテントを構成するオプションが Azure portal でグレー表示されます。
    • CLI、PowerShell、または REST を使用している場合は、ルーティング インテントの作成操作が失敗します。 失敗したルーティング インテントを削除し、カスタム ルート テーブルと静的ルートを削除してから、再作成を試みます。
    • Azure Firewall Manager を使用している場合は、defaultRouteTable 内の既存のルートの名前が private_traffic、internet_traffic、または all_traffic であることを確認します。 ルーティング インテントを構成する (ハブ間を有効にする) オプションは、ルートの名前が異なる場合はグレー表示されます。
  • ハブでルーティング インテントを構成した後は、既存の接続の更新、またはハブへの新しい接続が、関連付けられ、伝達された省略可能なルート テーブル フィールドを空白に設定して作成されていることを確認します。 Azure portal を介して実行されるすべての操作に対して、省略可能な関連付けと伝達が自動的に空白に設定されます。

データ パスのトラブルシューティング

「既知の制限事項」セクションを既に読んでいると仮定して、データパスと接続のトラブルシューティングを行ういくつかの方法を以下に示します。

  • 有効なルートを使用したトラブルシューティング:
    • プライベート ルーティング ポリシーが構成されている場合は、RFC1918 集約 (10.0.0.0/8、192.168.0.0/16、172.16.0.0/12) の defaultRouteTable の有効なルートに、ネクスト ホップ ファイアウォールを含むルートと、[プライベート トラフィック] テキスト ボックスに指定されたあらゆるプレフィックスが表示されます。 すべての Virtual Network とオンプレミスのプレフィックスが defaultRouteTable の静的ルート内のサブネットであることを確認してください。 オンプレミスまたは Virtual Network が、defaultRouteTable の有効なルート内のサブネットではないアドレス空間を使用している場合は、[プライベート トラフィック] テキスト ボックスにプレフィックスを追加します。
    • インターネット トラフィック ルーティング ポリシーが構成されている場合は、defaultRouteTable の有効なルートに、既定のルート (0.0.0.0/0) が表示されます。
    • defaultRouteTable の有効なルートに正しいプレフィックスがあることを確認したら、ネットワーク仮想アプライアンスまたは Azure Firewall の有効なルートを表示します。 ファイアウォール上の有効なルートで、Virtual WAN によって選択されたルートが示され、ファイアウォールがパケットを転送できる転送先が決定されます。 欠落しているプレフィックス、または正しくない状態のプレフィックスを把握すると、データ パスの問題を絞り込み、トラブルシューティングが必要な VPN、ExpressRoute、NVA、または BGP 接続を指摘するのに役立ちます。
  • シナリオ固有のトラブルシューティング:
    • セキュリティで保護されていないハブ (Azure Firewall と NVA のどちらもないハブ) が Virtual WAN にある場合は、セキュリティで保護されていないハブへの接続が、ルーティング インテントが構成されたハブの defaultRouteTable に伝達されていることを確認します。 伝達が defaultRouteTable に設定されていない場合は、セキュリティで保護されたハブへの接続から、セキュリティで保護されていないハブにパケットを送信できません。
    • インターネット ルーティング ポリシーが構成されている場合は、既定のルート 0.0.0.0/0 を学習する必要のあるすべての接続について、[既定のルートの伝達] または [インターネット セキュリティを有効にする] 設定が true に設定されていることを確認します。 この設定が false に設定されている接続では、インターネット ルーティング ポリシーが構成されている場合でも、0.0.0.0/0 ルートが学習されません。
    • 仮想ハブに接続されている Virtual Network 内にデプロイされたプライベート エンドポイントを使用している場合は、Virtual WAN ハブに接続されている Virtual Network 内にデプロイされたプライベート エンドポイント向けのオンプレミスからのトラフィックは、既定でルーティング インテントのネクスト ホップの Azure Firewall、NVA、または SaaS をバイパスします。 ただし、これにより、スポーク仮想ネットワークのプライベート エンドポイントがオンプレミスのトラフィックをファイアウォールに転送するため、非対称ルーティング (このためにオンプレミスとプライベート エンドポイント間の接続が失われる可能性があります) が発生します。 ルーティングの対称性を確保するには、プライベート エンドポイントがデプロイされているサブネット上でプライベート エンドポイントのルート テーブル ネットワーク ポリシーを有効にします。 プライベート トラフィック テキスト ボックスでプライベート エンドポイントのプライベート IP アドレスに対応する /32 ルートを構成しても、プライベート ルーティング ポリシーがハブで構成されている場合、トラフィックの対称性は保証されません。
    • プライベート ルーティング ポリシーで暗号化された ExpressRoute を使用している場合は、ファイアウォール デバイスに、Virtual WAN サイト間 VPN Gateway プライベート IP トンネル エンドポイントとオンプレミス VPN デバイス間のトラフィックを許可する規則が構成されていることを確認してください。 ESP (暗号化された外部) パケットは、Azure Firewall ログにログを記録する必要があります。 ルーティング インテントを使用した暗号化された ExpressRoute の詳細については、暗号化された ExpressRoute のドキュメントを参照してください。

Azure Firewall ルーティングに関する問題のトラブルシューティング

  • ルーティング インテントの構成を始める前に、Azure Firewall が、正常なプロビジョニング状態になっていることを確認してください。
  • IANA RFC1918 以外のプレフィックスをブランチ/Virtual Network で使用している場合は、Firewall Manager の [プライベート プレフィックス] テキスト ボックスに、そのプレフィックスを指定していることを確認してください。 構成された "プライベート プレフィックス" は、ルーティング インテントで構成された Virtual WAN 内の他のハブに自動的には伝達されません。 接続を確保するには、ルーティング インテントを持つすべてのハブの [プライベート プレフィックス] テキストボックスにこれらのプレフィックスを追加します。
  • Firewall Manager の [Private Traffic Prefixes](プライベート トラフィック プレフィックス) テキスト ボックスの一部として RFC1918 以外のアドレスを指定した場合は、RFC1918 以外のプライベート トラフィックに対して SNAT を無効にするために、ファイアウォールで SNAT ポリシーを構成する必要がある場合があります。 詳細については、Azure Firewall SNAT 範囲に関するページを参照してください。
  • Azure Firewall のログを構成、確認して、ネットワーク トラフィックのトラブルシューティングと分析に役立てます。 Azure Firewall の監視を設定する方法の詳細については、Azure Firewall の診断に関するページを参照してください。 さまざまな種類の Azure Firewall ログの概要については、「Azure Firewall のログとメトリック」を参照してください。
  • Azure Firewall の詳細については、Azure Firewall のドキュメントを参照してください。

ネットワーク仮想アプライアンスのトラブルシューティング

  • ルーティング インテントの構成を始める前に、ネットワーク仮想アプライアンスが、正常なプロビジョニング状態になっていることを確認してください。
  • 接続されたオンプレミスまたは Virtual Network で、IANA RFC1918 以外のプレフィックスを使用している場合は、そのプレフィックスを [プライベート プレフィックス] テキスト ボックスに指定していることを確認してください。 構成された "プライベート プレフィックス" は、ルーティング インテントで構成された Virtual WAN 内の他のハブに自動的には伝達されません。 接続を確保するには、ルーティング インテントを持つすべてのハブの [プライベート プレフィックス] テキストボックスにこれらのプレフィックスを追加します。
  • [プライベート トラフィック プレフィックス] テキスト ボックスの一部として、RFC1918 以外のアドレスを指定した場合は、NVA で SNAT ポリシーを構成して、RFC1918 以外の特定のプライベート トラフィックで SNAT を無効にする必要がある場合があります。
  • NVA ファイアウォール のログを調べて、ファイアウォール規則によってトラフィックが削除されたり、拒否されたりしていないかを確認します。
  • トラブルシューティングに関するサポートとガイダンスについては、NVA プロバイダーにお問い合わせください。

"サービスとしてのソフトウェア" のトラブルシューティング

  • ルーティング インテントの構成を始める前に、Saas ソリューションが、正常なプロビジョニング状態になっていることを確認してください。
  • トラブルシューティングのその他のヒントについては、Virtual WAN ドキュメントのトラブルシューティングのセクションを参照するか、Palo Alto Networks Cloud NGFW のドキュメントを参照してください。

次のステップ

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