Share via

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

  • [アーティクル]

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

背景

ルーティング インテントとルーティング ポリシーを使用すると、Virtual WAN ハブを構成して、インターネット接続トラフィックとプライベート (ポイント対サイト VPN、サイト間 VPN、ExpressRoute、Virtual Network、およびネットワーク仮想アプライアンス) トラフィックを、仮想ハブにデプロイされた Azure Firewall、次世代ファイアウォール ネットワーク仮想アプライアンス (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 ハブ内外のすべてのブランチおよび仮想ネットワーク トラフィックは、ネクスト ホップの 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 ピアリング機能は使用できます。
    • 現在、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 回線間の接続の有効化に関するセクションを参照してください。

考慮事項

現在、ルーティング インテントなしで 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 ハブにデプロイされたセキュリティ アプライアンス間でトラフィックが対称的にルーティングされるように、すべてのハブでルーティング インテント意図を有効にする必要もあります。

前提条件

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

  • 仮想ハブと共にデプロイされるカスタム ルート テーブルはありません。 存在するルート テーブルは、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 回線間の接続の有効化に関するセクションを参照してください。

ルーティング インテントを使用した 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 を使用してプライベート ルーティング ポリシーを構成すると、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 デバイスを構成します。

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 でルーティング インテントとルーティング ポリシーを構成するときにトラブルシューティングを行う一般的な方法を説明します。

有効なルート

仮想ハブ上にプライベート ルーティング ポリシーが構成されている場合は、オンプレミスと仮想ネットワークの間のすべてのトラフィックが、その仮想ハブで 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 を参照してください。