高度なポリシーベースルーティング

高度なポリシーベースルーティング

ネットワークを通過する音声、データ、映像のトラフィックやアプリケーションが絶えず増加する中、ネットワークはトラフィックタイプを認識して、パフォーマンスや可用性を損なうことなく、トラフィックの優先順位付け、分離、ルーティングを効果的に行う必要があります。

Junos OSリリース15.1X49-D60以降、SRXシリーズファイアウォールは、これらの課題に対処するための高度なポリシーベースルーティング(APBR)をサポートしています。

高度なポリシーベースルーティングは、セッションベースのアプリケーション認識型ルーティングの一種です。このメカニズムは、ポリシーベースのルーティングとアプリケーション認識型のトラフィック管理ソリューションを組み合わせたものです。APBRは、アプリケーションの属性に基づいてフローを分類し、これらの属性に基づいてフィルターを適用してトラフィックをリダイレクトすることを意味します。フロー分類メカニズムは、使用中のアプリケーションを表すパケットに基づいています。

APBRは以下を実装します。

• アプリケーショントラフィックやアプリケーション内のユーザーセッションを特定するAppIDのディープパケットインスペクション機能とパターンマッチング機能

• ASC でアプリケーションの種類と、一致する規則に対応する宛先 IP アドレス、宛先ポート、プロトコルの種類、およびサービスを検索します。

一致するルールが見つかった場合、トラフィックは適切なルートと対応するインターフェイスまたはデバイスに転送されます。

APBRのメリット

• アプリケーションに基づいてルーティング動作を定義できます。

• より柔軟なトラフィック処理機能を提供し、アプリケーションの属性に基づいてパケット転送をきめ細かく制御します。

APBRの仕組みを理解する

APBRの動作について説明する前に、APBRコンポーネントについて理解しましょう。

• APBR プロファイル (このドキュメントではアプリケーション プロファイルとも呼ばれます) を作成します。プロファイルには、複数の APBR ルールが含まれています。各ルールには、一致条件として複数のアプリケーションまたはアプリケーション グループが含まれます。トラフィックがルールのアプリケーションまたはアプリケーショングループのいずれかに一致する場合、ルールは一致したものとみなされ、プロファイルはアプリケーショントラフィックを関連するルーティングインスタンスに転送します。

• APBRプロファイルは、ルーティングインスタンスをAPBRルールに関連付けます。トラフィックがアプリケーション プロファイルに一致する場合、ルーティング インスタンスで定義された関連する静的ルートとネクスト ホップが、特定のセッションのトラフィックのルーティングに使用されます。

• アプリケーション プロファイルをイングレス トラフィックに関連付けます。APBRプロファイルをAPBRポリシーにアタッチし、セッションのアプリケーション・サービスとして適用できます。

APBRワークフローについて理解してから、APBRミッドストリームのサポートについて説明し、次にAPBRの最初のパケット分類について説明します。

APBR ワークフロー

図1 は、Junos OSリリース21.3R1以前のAPBRの動作をまとめたものです。

図 1: APBR の動作

セキュリティデバイスは、DPIを使用してアプリケーションの属性を識別し、APBRを使用してネットワーク経由でトラフィックをルーティングします。サービスチェーンでは、デバイスがABPRを適用する前に、アプリケーショントラフィックがDPIを受けます。DPI を使用してアプリケーションを識別するプロセスでは、複数のパケットを分析する必要があります。このような場合、最初のトラフィックはデフォルトルート(非APBRルート)を通過して宛先に到達します。プロセスは続行されますが、DPIはアプリケーションを識別します。DPI がアプリケーションを識別すると、APBR はセッションの残りの部分にルールを適用します。トラフィックは、APBRプロファイルルールに従ってルートを通過します。

ソース NAT に異なる NAT プールを使用し、ミッドストリーム APBR を適用した場合、セッションのソース IP アドレスは、ミッドストリーム APBR の前にセッションが使用していたアドレスと同じままです。

• APBRミッドストリームサポート
• 最初のパケット分類でのAPBR
• 最初のパケット分類の利点
• 制限

Junos OSリリース21.3R1以降、APBRはファーストパケット分類を使用してネットワークトラフィック内のアプリケーションを識別します。APBRは、トラフィックフローの最初のパケットを調べてアプリケーションを識別し、アプリケーション固有のルールを適用してトラフィックを転送します。

図2 は、APBRが最初のパケット分類を使用してアプリケーションの詳細を取得する方法を示しています。

図 2: ファースト パケット分類 を使用した APBR

ファーストパケット分類では、アプリケーションの静的IPマッピングやポートの詳細などの詳細を含むリポジトリを利用します。リポジトリは、アプリケーション署名パッケージ (JDPI) の一部です。

キャッシュ可能なアプリケーションの最初のセッションでは、APBR は ASC に照会して、フローのアプリケーションの詳細を取得します。アプリケーションのエントリーが ASC で使用できない場合、APBR は JDPI にアプリケーションの詳細を照会します。APBR は、フローの IP アドレスとポートの詳細をクエリに使用します。アプリケーション・マッピングが使用可能な場合、JDPI は詳細を APBR に戻します。アプリケーションの詳細を取得した後、APBR はアプリケーションの構成済みプロファイルを検索し、割り当てられたルーティング・インスタンスを介してパケットをルーティングします。

同時に、JDPI はパケットの処理を継続し、ASC を更新します(有効な場合)。後続のフローでは、APBR はフローの ASC に存在するアプリケーション エントリに基づいてトラフィックのルーティングを実行します。

最初のパケット分類では、キャッシュ可能なアプリケーションのAPBR構成で、ソースNATに異なるNATプールを使用できます。

高度なポリシーベースルーティングオプション

以下のオプションを使用することで、APBR でトラフィック処理を合理化できます。

• Limit route change- 一部のセッションは、アプリケーション シグネチャがアプリケーションを識別するため、セッションの途中で連続的に分類されます。アプリケーションがアプリケーション・シグニチャーによって識別されるたびに、APBR が適用され、これによりトラフィックの経路が変更されます。セッションのルートを変更できる回数を制限するには、 ステートメントのオプションtunablesを使用しますmax-route-change。

  set security advance-policy-based-routing tunables max-route-change value

  例：

  この例では、セッションごとのルート変更数を 5 に制限します。セッションの途中でルートに変更が発生した場合、このカウントは 4 に減らされます。このプロセスは、カウントが 0 に達するまで続きます。その後、セッションの途中でAPBRは適用されません。

  識別されたアプリケーションがASCにエントリーを持っている場合、セッションはAPBR構成に従って指定されたルートで開始されるため、そのセッションのカウントは減少しません。

• Terminate session if APBR is bypassed–セッションの途中でAPBRが適用されているときにゾーン間に不一致がある場合は、セッションを終了できます。セッションの途中でAPBRを適用する場合、新しいエグレスインターフェイスと既存のエグレスインターフェイスの両方が同じゾーンの一部である必要があります。セッションの途中でインターフェイスのゾーンを変更した場合、デフォルトではAPBRは適用されず、トラフィックは引き続き既存のインターフェイスを通過します。このデフォルトの動作を変更するには、トラフィックがAPBRをバイパスして同じルートを通過できるようにする代わりに、 ステートメントのオプションtunablesを使用することでdrop-on-zone-mismatch、セッションを完全に終了します。

  例：

• Enable logging- ロギングを有効にして、例えば、インターフェイスのゾーンの変更によりAPBRがバイパスされた場合などに、デバイスで発生するイベントを記録できます。ステートメントの tunables オプションを使用してenable-logging、ロギングを設定できます。

  例：

• Enable reverse reroute—ECMP ルートのトラフィック対称性を必要とし、着信トラフィックをセッションの途中で切り替える必要がある展開では、次のようにセキュリティ ゾーンに固有のオプション enable-reverse-reroute を使用して再ルーティングを実現できます。

  例：

  [edit]

  set security zones security-zone zone-name enable-reverse-reroute

  着信パケットがインターフェイスに到着し、発信/戻りインターフェイスが異なるセキュリティ ゾーンで上記の設定が有効になっている場合、インターフェイスの変更が検出され、再ルートがトリガーされます。リバースパスに対してルート検索が実行され、パケットが到着したインターフェイスが優先されます。

  リバース パス上のトラフィックのルート ルックアップに失敗すると、特定のセッションで以降の処理が停止します。

  リバース再ルーティングのサポートは、Junos OSリリース15.1X49-D130以降のリリースから利用できます。

• Support for Layer 3 and Layer 4 Applications—Junos OSリリース20.2R1以降、APBRはレイヤー3およびレイヤー4のカスタムアプリケーションをサポートします。以下の構成ステートメントを使用して、APBRでレイヤー3およびレイヤー4のカスタムアプリケーション検索を手動で無効にすることができます。
• Application Tracking—

  AppTrack を有効にして、トラフィックを検査し、指定したゾーン内のアプリケーション フローの統計情報を収集できます。詳細については、「 アプリケーション トラッキングについて 」を参照してください。

ユースケース

• 複数の ISP リンクを使用する場合:

  • APBRは、複数のリンクが使用可能な場合に、重要なアプリケーション用の広帯域で低遅延のリンクを選択するために使用できます。

  • APBRは、リンク障害が発生した場合に、重要なトラフィックのフォールバックリンクを作成するために使用できます。複数のリンクが使用可能な場合に、重要なアプリケーショントラフィックを伝送するメインリンクが停止した場合、フォールバックリンクとして設定された別のリンクを使用してトラフィックを伝送することができます。

  • APBRは、ディープインスペクションや分析のためのトラフィックを分離するために使用できます。この機能を使用すると、ディープインスペクションと監査を受ける必要があるアプリケーションに基づいてトラフィックを分類できます。必要に応じて、このようなトラフィックを別のデバイスにルーティングできます。

制限

APBR には以下の制限があります。

• トラフィックのルートのリダイレクトは、アプリケーション システム キャッシュ(ASC)にエントリが存在するかどうかによって異なります。ルーティングは、ASC 参照が成功した場合にのみ成功します。最初のセッションでは、トラフィックに ASC が存在しない場合、トラフィックはデフォルト ルート(非 APBR ルート)を経由して宛先に到達します(この制限は、Junos OS 15.1X49-D110 より前のリリースにのみ適用されます)。

• アプリケーション署名パッケージがインストールされていない場合、またはアプリケーション識別が有効になっていない場合、APBR は機能しません。

ミッドストリームをサポートするAPBRには、次の制限があります。

• APBRは、転送トラフィックに対してのみ機能します。

• APBR は、アクティブ FTP などの制御セッションからエンティティーによって開始されたデータ・セッションでは機能しません。

• ソース NAT に異なる NAT プールを使用し、ミッドストリーム APBR が適用される場合、セッションの送信元 IP アドレスは、ミッドストリーム APBR を適用する前にセッションが使用していたアドレスと同じままになります。

• ミッドストリームをサポートするAPBRは、すべてのエグレスインターフェイスが同じゾーンにある場合にのみ機能します。このため、APBRミッドストリームサポートを利用するために使用できるのは、転送および仮想ルーティングおよび転送(VRF)ルーティングインスタンスのみです。

APBRポリシーの仕組み

APBRポリシーは、セキュリティゾーンに対して定義されます。ゾーンに関連付けられたAPBRポリシーが1つ以上ある場合、セキュリティ・ゾーンから開始されたセッションはポリシー一致を通過します。

APBRポリシーによるトラフィックの照合と、定義されたパラメーター/ルールに基づく高度なポリシーベースのルーティングの適用には、次のシーケンスが含まれます。

• トラフィックがイングレスゾーンに到着すると、APBRポリシールールと照合されます。ポリシー一致条件には、送信元アドレス、宛先アドレス、およびアプリケーションが含まれます。

• トラフィックがセキュリティ ポリシー ルールに一致すると、APBR ポリシーのアクションがトラフィックに適用されます。APBR プロファイル名を指定することにより、APBR ポリシー・アクションでアプリケーション・サービスとして APBR を有効にすることができます。

• APBR プロファイル構成には、動的アプリケーションと dyamic アプリケーション・グループのセットを含むルール・セットが一致条件として含まれています。これらのルールのアクション部分には、トラフィックを転送する必要があるルーティング インスタンスが含まれています。ルーティングインスタンスは、静的ルートまたは動的に学習されたルートの設定を含むことができます。

• スタティック ルートを宛先とするすべてのトラフィックは、特定のデバイスまたはインターフェイスへのトランジットのためにネクストホップ アドレスに送信されます。

APBRポリシールールはターミナルルールであり、トラフィックがポリシーに一致すると、他のポリシーによってそれ以上処理されないことを意味します。

APBRポリシーに一致するトラフィックがあり、APBRプロファイルにルールに一致するトラフィックがない場合、APBRポリシーに一致するトラフィックは、デフォルトのルーティングインスタンス[inet0]を経由して宛先に到達します。

従来のAPBRプロファイルのサポート

Junos OS リリース 18.2R1 より前は、APBR プロファイルはセキュリティ ゾーン レベルで適用されていました。APBR ポリシーのサポートにより、セキュリティゾーンレベルの APBR 設定は、下位互換性と設定を新しい設定に準拠させる機会を提供するためにすぐに削除されるのではなく、将来的に非推奨になります。

ただし、ゾーンベースの APBR を構成していて、特定のセキュリティゾーンの APBR ポリシーを追加しようとすると、コミットが失敗する可能性があります。ゾーンのAPBRポリシーを設定するには、ゾーンベースの設定を削除する必要があります。同様に、APBR ポリシーがセキュリティ・ゾーン用に構成されている場合に、ゾーン・ベースの APBR を構成しようとすると、コミット・エラーが発生します。

制限

• 特定のアドレスまたはAPBRポリシールールで設定されたアドレスを使用する場合は、グローバルアドレス帳を使用することをお勧めします。なぜなら、ポリシーの評価時に宛先ゾーンがわからないため、ゾーン固有のルールが宛先アドレスに適用されない可能性があるからです。

• セキュリティゾーンjunosホストゾーンのAPBRポリシーの設定はサポートされていません。

APBR プロファイルでのルール処理

アプリケーションの属性に基づいてトラフィックを分類し、その属性に基づいてポリシーを適用してトラフィックをリダイレクトすることで、高度なポリシーベースのルーティングを提供できます。これを行うには、APBR プロファイルを定義し、それを APBR ポリシーに関連付ける必要があります。APBR プロファイルを作成して、動的アプリケーション、アプリケーション・グループ、またはその両方、または URL カテゴリーを一致基準として持つ複数のルールを含めることができます。APBR プロファイルで構成されるルールには、次のいずれかを含めることができます。

• 1 つ以上のアプリケーション、動的アプリケーション、またはアプリケーション グループ

• URL カテゴリ(IP 宛先アドレス)—EWF またはローカル Web フィルタリング。

APBR プロファイルでは、両方の一致基準に対してルール検索が実行されます。使用可能な一致基準が 1 つしかない場合、使用可能な一致基準に基づいてルール検索が実行されます。

APBR プロファイルには、トラフィックをアプリケーションまたは URL カテゴリーと突き合わせるためのルールと、ルート検索のために、一致するトラフィックを指定されたルーティング・インスタンスにリダイレクトするアクションが含まれています。

Junos OSリリース18.3R1では、URLカテゴリの照合は宛先IPアドレスに基づいて行われます。このため、URL カテゴリベースのルール一致は、セッションの最初のパケットで終了します。動的アプリケーションはセッションの途中で識別される可能性があるため、動的アプリケーション・ルールのマッチング・プロセスは、アプリケーション識別プロセスが完了するまで続行されます。

URL カテゴリベース ルーティングのメリット

• URL ベースのカテゴリを使用すると、Web トラフィックをきめ細かく制御できます。Webサイトの特定のカテゴリに属するトラフィックは、さまざまなパスを介してリダイレクトされ、カテゴリに基づいて、HTTPSトラフィックのSSL復号化を含む、さらなるセキュリティ処理の対象となります。

• URLカテゴリに基づくトラフィック処理機能を使用すると、選択したWebサイトに異なるパスを使用できます。異なるパスを使用することで、QoE(Quality of Experience)が向上し、利用可能な帯域幅を効果的に活用できるようになります。

• SD-WAN ソリューションでは、動的なアプリケーションベースのルーティングに加えて、URL カテゴリーベースのルーティングを利用できます。

• URLカテゴリベースのルーティングは、ソースNAT設定の変更に対応できるため、ローカルインターネットブレイクアウトソリューションに使用できます。

URL カテゴリベース ルーティングの制限

APBR プロファイルでの URL カテゴリーの使用には、以下の制限があります。

• APBR プロファイルの URL カテゴリー識別には、宛先 IP アドレスのみが使用されます。ホスト、または URL または SNI フィールドに基づく URL カテゴリはサポートされていません。

• 動的アプリケーションまたはURLカテゴリーのいずれかをAPBRプロファイル・ルールの一致条件として構成できます。URL カテゴリと動的アプリケーションの両方でルールを設定すると、コミット エラーが発生します。

利点

• ルーティング動作をよりきめ細かく定義し、ネットワークを通過するアプリケーショントラフィックにポリシーを安全に適用できるようにします。

• より柔軟なトラフィック処理機能を提供し、ユーザーの役割とビジネス要件に基づいてパケット転送をきめ細かく制御します。

導入

アプリケーション識別技術は、ディープパケットインスペクション(DPI)に依存しています。暗号化されたトラフィックなど、DPIエンジンがアプリケーションを識別できない場合があります。このようなトラフィックにAPBRルールを適用すると、トラフィックはAPBR機能が適用されない状態で通常の処理が行われます。

Junos OSリリース19.3R1以降、SRXシリーズファイアウォールは、DSCPタグ付きトラフィックでAPBR機能を実行するための一致条件として、APBRルールでのDSCP値の設定をサポートしています。

動的アプリケーションや動的アプリケーショングループなど、APBRルールの他の一致基準に加えて、DSCP値を設定できます。

APBRルールでDSCP値を設定することで、DSCPマーキングのあるトラフィックにAPBRサービスを拡張できます。

ユースケース

DSCPを使用したAPBRルールを、暗号化されたトラフィックの一致条件として使用できます。

制限

• 1 つの APBR プロファイルで DSCP 値と URL カテゴリを使用してルールを構成する場合、サポートは使用できません。

DSCP値を一致条件として使用する場合のAPBRルールルックアップ

APBR ルールでは、DSCP 値、動的アプリケーション、またはその両方の組み合わせを構成できます。

APBRルールでDSCPと動的アプリケーションの両方を構成している場合、トラフィックがルールで指定されたすべての基準に一致すると、ルールは一致と見なされます。APBR ルールに複数の DSCP 値が存在する場合、いずれかの条件が一致すると、一致したと見なされます。

APBR プロファイルには複数のルールを含めることができ、各ルールにはさまざまな一致条件があります。

APBR プロファイルに複数の APBR ルールがある場合、ルール検索では次の優先順位が使用されます。

1. DSCP + 動的アプリケーションのルール

2. 動的適用のルール

3. DSCP 値を持つルール

APBR プロファイルに複数のルールが含まれている場合、システムはルール検索を実行し、次の順序でルールを適用します。

• システムは、セッションの最初のパケットに DSCP ベースのルールを適用します。

• システムは、DPI 分類またはアプリケーション システム キャッシュ (ASC) から使用可能なアプリケーション情報があるかどうかを引き続きチェックします。

• セッションの途中で、DPI が新しいアプリケーションを識別すると、システムはルール検索を実行し、必要に応じて新しいルール(アプリケーションベースのルールまたは DSCP ベースのルール、あるいは両方の組み合わせ)を適用します。

• アプリケーションとルールの識別は、DPIが最終アプリケーションとしてアプリケーションを識別するか、最大再ルート値に達するまで続きます。

• ルール検索がどのルールにも一致しない場合、それ以上のアクションは実行されません。

APBRがどのようにルール検索を実行し、ルールを適用するかを、次の2つの例で理解しましょう。

• 例1
• 例2

構成

• CLIクイック構成
• 手順
• 結果

ミッドストリームルーティングを選択的に無効にする必要があるのはなぜですか?

一部のセッションは、アプリケーション シグネチャによってアプリケーションを識別するため、セッションの途中で連続的に分類されます。アプリケーションがアプリケーション・シグニチャーによって識別されるたびに、APBR が適用され、これによりトラフィックの経路が変更されます。オプションを使用して max-route-change 、セッションのルートを変更できる回数を制限できます。このオプションを 0 に設定すると、特定のセッションで APBR が無効になります。ただし、このオプションでは、デバイスでAPBR機能がグローバルに無効になりますが、これは必要ない場合があります。

ミッドストリームでのAPBRの選択的無効化

Junos OS リリース 19.4R1 以降、特定の APBR ルールのセッションの途中で APBR サービスを選択的にオフにし、残りのセッションではグローバル APBR 機能を維持できるようになりました。特定のAPBRルールのミッドストリームルーティングを無効にすると、システムは対応するアプリケーショントラフィックにミッドストリームAPBRを適用せず、非APBRルートを介してトラフィックをルーティングします。

ミッドストリームAPBRを選択的に無効にするには、[]階層レベルでミッドストリームルーティングを無効にするオプション(disable-midstream-routing)edit security advance-policy-based-routing profile apbr-profile-name rule apbr-rule-nameを使用してAPBRルールを構成できます。

表 7 は、ミッドストリーム APBR を選択的に無効にした場合の動作を示しています。

特定のAPBRルールのミッドストリームルーティングを無効にすると、アプリケーショントラフィックはデフォルトの非APBRルートを介して再ルーティングされます。