トラフィックが HCX Mobility Optimized Networking (MON) ポリシールートの期待通りに流れない問題

Products

• VMware HCX

Issue/Introduction

免責事項：これは英文の記事「Traffic Not Following HCX Mobility Optimized Networking (MON) Policy Routes As Expected」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

HCXを使用してネットワークを拡張し、Mobility Optimized Networking (MON) を有効にした後、MONポリシールートで「拒否（Deny）」ルールを構成しているにもかかわらず、クラウド内の仮想マシンからのトラフィックがクラウド環境内に留まらない場合があります。

これにより、トラフィックの流入パスと流出パスが異なる非対称ルーティングが発生します。トラフィックは期待通りに Tier-1/Tier-0 ゲートウェイに転送されず、HCXトンネルを通じてオンプレミス側へ流れ続けてしまいます。

MONポリシールートを理解するための重要な概念

重要: MONポリシールートは、MONが有効なクラウドVMから送信されるパケットの宛先IPアドレスのみを評価します。適切なトラフィック制御を行うためには、この点を理解することが極めて重要です。この記事で「トラフィック」という用語を使用する場合、それは具体的に「特定のIPアドレスまたはサブネットを宛先とするトラフィック」を指します。

ポリシールートの仕組み

1. MONポリシールートにおける「許可（Allow）」と「拒否（Deny）」という言葉は、直感に反する意味を持っています。
   • 許可 (Allow): 「このIP/サブネット宛のトラフィックを、HCXトンネル経由でオンプレミスへ送信する」ことを意味します。
   • 拒否 (Deny): 「このIP/サブネット宛のトラフィックを、ローカルゲートウェイを使用してクラウド内に保持する」ことを意味します。
2. ルールの評価は、ルールの並び順ではなく、**具体性（Specificity）**に基づいて行われます。
   • 最も具体的なルート（プレフィックス長が長いもの）が優先されます（例：/24 より先に /32 が評価され、/16 より先に /24 が評価されます）。
   • ルールが同じ具体性（同じプレフィックス長）を持つ場合、構成リストの最初に記載されているルールが適用されます。
3. デフォルトの設定では、ほとんどのトラフィックがオンプレミスにルーティングされます。
   • デフォルトルールでは、すべての RFC-1918 範囲（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）がオンプレミスへ行くように「Allow」として構成されています。
   • 特定のトラフィックをクラウド内に留めるには、より具体的な「Deny」ルールを追加する必要があります。
4. 複数のサービスメッシュ（Service Mesh）があるサイトの場合
   
   • MONサイトの名前はすべてサービスタイプに基づいているため、「hcx-cloud」と表示されます。
   • これらはサービスメッシュが作成された順序でリストされているため、UIを確認し、正しいMONサイトを選択するためにリストの何番目にあるかを数える必要がある場合があります。

MON適用時のトラフィックフロー

MONが有効なVMがパケットを送信する場合：

• 宛先IPが同じ拡張ネットワーク内にある場合: トラフィックはレイヤ2で直接流れます。
• 宛先IPがクラウドのNSX-T環境内の別のセグメントにある場合: トラフィックはローカルの Tier-1 ルーターを使用します。
• 宛先IPがクラウドのNSX-T環境外にある場合: パスを決定するためにポリシールートが評価されます。

検証ステップ

• Denyルールを構成しているにもかかわらず、MONが有効なクラウド内のVMからのトラフィックがHCXトンネル経由でオンプレミスに送信されている。
• パケットキャプチャにより、流入パスと流出パスが異なる非対称ルーティングが確認される。
• ポリシールート構成内のルートエントリを確認すると、Denyルールが既存のAllowルールよりも優先されていないことがわかる。

Environment

• Network Extension および MON が有効な VMware HCX
• クラウド環境にVMが存在する拡張ネットワーク

Cause

この問題は、MONポリシールートが宛先IPアドレスの具体性と Allow/Deny 設定に基づいてトラフィックを評価し、ルーティングの決定を行うというユニークな方式によって発生します。主に以下の2つの原因が寄与しています。

ルールの評価順序

複数のポリシールートが存在する場合、リストに表示される順序ではなく、その**具体性（より具体的なルートが優先される）**に従って評価されます。
つまり、リスト内の位置に関係なく、プレフィックス長が長いルール（例：/32）は、プレフィックス長が短いルール（例：/24）よりも先に評価されます。

Allow と Deny の構成定義

MONポリシールートにおいて、「Allow」と「Deny」は特有の意味を持ち、しばしば直感に反します。

• Allow: 「このIP/サブネット宛のトラフィックを、HCXトンネル経由でオンプレミスへ送信する」
• Deny: 「このIP/サブネット宛のトラフィックを、ローカルゲートウェイを使用してクラウド内に保持する」

これは、通常「Allow」がトラフィックの通過を許可し、「Deny」がそれをブロックするという、ほとんどのネットワーク管理者が期待する動作とは正反対です。

例: 広範なサブネットルール（172.16.0.0/12 が Allow）と、より具体的なサブネットルール（172.16.5.10/32 が Deny）がある構成を考えます。管理者は具体的な Deny ルールによって 172.16.5.10 へのトラフィックがクラウド内に留まることを期待するかもしれませんが、ルールの評価方法によっては、広範な Allow ルールが優先されることでトラフィックがオンプレミスに流れる可能性があります。

実際のトラフィックフローの動作

MONが有効なVMがトラフィックを送信しようとする際：

1. 宛先IPが同じ拡張ネットワーク内の場合、トラフィックはレイヤ2で直接流れます。
2. 宛先IPがクラウドのNSX-T環境内の別のセグメントにある場合、トラフィックはローカルの Tier-1 ルーターを使用します。
3. 宛先IPがクラウドのNSX-T環境外にある場合、ポリシールートが評価されます：
   • 宛先IPが Allow ルールに一致する場合: トラフィックはHCXトンネル経由でオンプレミスに戻ります。
   • 宛先IPが Deny ルールに一致する場合: トラフィックはクラウド内に留まり、Tier-1/Tier-0 ゲートウェイを使用します。
   • 宛先IPがいかなるルールにも一致しない場合: トラフィックはクラウド内に留まり、Tier-1/Tier-0 ゲートウェイを使用します。

ポリシールートの評価順序

評価の順序は具体性に基づいており、インターフェースに表示される順序ではありません。

• 最も具体的なルート（最小のサブネット / 最大のプレフィックス）が優先されます。
• /32 ルールは /24 よりも具体的であり、/24 は /16 よりも具体的です。
• ルールが同じ具体性を持つ場合は、構成リストで最初に記載されているルールが適用されます。

デフォルト構成

デフォルトで、HCXは以下のポリシールートを作成します。

• すべての RFC-1918 範囲（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）が Allow として構成されます。
• これは、デフォルトですべてのプライベートIPトラフィックがオンプレミスに送信されることを意味します。
• 一致しないトラフィック（インターネットトラフィックを含む）はすべてクラウド内に留まります。

このデフォルト構成は、特定の RFC-1918 宛先トラフィックをクラウド内に留めたい場合に問題を引き起こす可能性があり、より具体的な Deny ルールを追加する必要があります。

Resolution

特定のIPアドレス宛のトラフィックを、オンプレミスに送らずにクラウド内に留めるよう、MONポリシールートを正しく構成するには、以下の手順に従ってください。

HCX Network Extension インターフェースにアクセスする

1. HCX Center プラグインまたは直接の URL 経由で HCX Manager にログインします。
2. Network Extension > Advanced > Policy Routes に移動します。

クラウドに留めるべき宛先IPに対して Deny ルールを構成する

1. オンプレミス環境に送るべきではない特定のサブネット（例：###.###.###.###/32）に対して、明示的な DENY ルールを追加します。
2. このルールが、このIP範囲を含む可能性のあるいかなる ALLOW ルールよりも具体的であることを確認してください。
3. ポリシールートは、VMのゲートウェイがクラウドに移行されたときにのみトラフィックに影響を与えることを忘れないでください。

重複するサブネットには、最も具体的なネットワークマスクを使用する

• 許可されている大きなネットワーク（例：###.###.###.###/12）の一部である特定の宛先IP（例：###.###.###.###/32）を拒否（クラウド保持）する必要がある場合、その Deny ルールは、広範な Allow ルールを上書きするためにより具体的なネットワークマスク（/32）を使用しなければなりません。

構成を確認する

1. 変更を適用した後、traceroute などのツールを使用してトラフィックフローを確認します。
2. 拒否（Deny）されたサブネット宛のトラフィックがクラウド環境内に留まっていることを確認します。
3. 他の宛先IPへのトラフィックが期待通りにオンプレミスへ流れていることを確認します。

包括的な制御のために

1. デフォルトの RFC-1918 エントリを削除し、正確なトラフィックフローの要件に基づいて特定の Allow/Deny ルールを追加することを検討してください。
2. オンプレミスに行く必要がある特定の宛先サブネットに対してのみ、明示的な Allow ルールを追加します。
3. クラウドに留まるべき宛先サブネットに対しては、明示的な Deny ルールを追加します。

この適切な構成を理解することで、特定のIP範囲へのトラフィックが確実にクラウド内に留まり、非対称ルーティングの問題を防ぎ、ネットワークトラフィックフローを最適化することができます。

これらの手順に従ってもエラーが解消されない場合は、Broadcomサポートにお問い合わせください。

Additional Information

• VMware HCX Mobility Optimized Networking (MON) guidance - Azure VMware Solution
• Mobility Optimized Networking Policy Routes
• Uploading files to cases on the Broadcom Support Portal
• Collecting diagnostic information for VMware HCX