アプリケーションQoS
AppQoSは、特定のアプリケーションへのアクセスを特定および制御し、ステートフルファイアウォールルールベースの粒度を提供して、アプリケーション層のサービス品質(QoS)を照合して適用することができます。詳細については、次のトピックを参照してください。
アプリケーションのサービス品質(AppQoS)について
アプリケーションサービス 品質 (AppQoS)機能は、Junos OSサービス クラス (CoS)の機能を拡張し、レイヤー7アプリケーションタイプに基づいたDSCP値のマーキング、損失優先度設定によるアプリケーションベースのトラフィックの尊重、レイヤー7アプリケーションタイプに基づくエグレスPICの転送レートの制御などを行います。
セキュリティデバイスでDSCP値をマークするには、4つの方法があります。
IDP攻撃アクションベースのDSCPリライター
レイヤー7アプリケーションベースのDSCPリライター
ALGベースのDSCPリライター
ファイアウォールフィルターベースのDSCPリライター
IDPリマーキングは、IDPルールに基づいてイングレスポートで実行されます。アプリケーションのリマーキングは、アプリケーションルールに基づいてegressポートで実行されます。インターフェイスベースのリマーキングは、ファイアウォールフィルタールールに基づいて、egressポートでも発生します。(Junos OS CoS機能の詳細については、 サービスクラスユーザーガイド(セキュリティデバイス) を参照してください。)
これら 3 人のリライターのコメントの決定は異なる場合があります。パケットが 3 つすべてをトリガーした場合、一致がパケット コンテンツのどれだけ深く行われたかによって優先される方法が決まります。IDPリマーキングはアプリケーションリマーキングよりも優先し、アプリケーションリマーキングはインターフェイスベースのリマーキングよりも優先されます。
パケットがAppQoSとALGベースのDSCPリライターの両方をトリガーする場合、AppQoSはALGベースのDSCPリライターよりも優先されます。
AppQoS DSCP書き換え器は、転送クラスと損失優先度の両方を通じてパケットのサービス品質を伝えます。AppQoSレート制限パラメーターは、関連するキューの伝送速度とボリュームを制御します。
- アプリケーションQoSのメリット
- 一意の転送クラスとキューの割り当て
- アプリケーション認識型DSCPコードポイントと損失優先度の設定
- レートリミッターとプロファイル
- レートリミッターの割り当て
- レートリミッターアクション
- AppQoSセキュリティポリシーの設定
アプリケーションQoSのメリット
AppQoSは、アプリケーショントラフィックに優先順位を付けて計測する機能を提供し、ビジネスクリティカルなアプリケーショントラフィックや優先度の高いアプリケーショントラフィックにより良いサービスを提供します。
一意の転送クラスとキューの割り当て
フォワーディングクラスは、次の3つの機能を提供します。
類似した特性を持つパケットをグループ化する
出力キューを割り当てます
既存のJunos OSファイアウォールフィルターベースのリライターとの競合を解決
一意の転送クラス名により、AppQoSリマーキングがインターフェイスベースの 書き換えルールによって上書きされることを防ぎます。ファイアウォールフィルターベースのリライターは、パケットの転送クラスがこのリライター用に特別に定義されたクラスに一致する場合に、パケットのDSCP値をリマークします。パケットの転送クラスがファイアウォールフィルターベースのリライターのクラスのいずれにも一致しない場合、DSCP値はリマークされません。したがって、AppQoS値が上書きされないようにするには、ファイアウォールフィルターベースのリライターに認識されない転送クラス名を使用してください。
各転送クラスは、適切な程度の拡張処理または標準処理を提供するエグレス キューに割り当てられます。1つのキューに多くの転送クラスを割り当てることができます。そのため、デバイスに定義されたキューは、IDP、AppQoS、ファイアウォールフィルターベースの書き換え器で使用できます。送信優先度を区別するのは、キューではなく転送クラス名です。(キューとスケジューラの設定については、 『サービスクラスユーザーガイド(セキュリティデバイス) 』を参照してください。)
アプリケーション認識型DSCPコードポイントと損失優先度の設定
AppQoSでは、定義された転送クラスを選択したアプリケーションに関連付けるルールに基づいて、トラフィックがグループ化されます。ルールの一致基準には、1つ以上のアプリケーションが含まれます。一致するアプリケーションからのトラフィックがルールに遭遇すると、ルールアクションが転送クラスを設定し、DSCP値と損失優先度をアプリケーションに適した値にマークします。
差別化されたサービス(DiffServ)コードポイント(DSCP)値は、6ビットのビットマップ値、またはユーザー定義またはデフォルトのエイリアスによってルールで指定されます。 表1は 、Junos OSのデフォルトのDSCPエイリアス名とビットマップ値のリストを示しています。
エイリアス |
ビット値 |
|---|---|
EF |
101110 |
AF11 |
001010 |
AF12 |
001100 |
AF13 |
001110 |
AF21 |
010010 |
AF22 |
010100 |
AF23 |
010110 |
AF31 |
011010 |
AF32 |
011100 |
AF33 |
011110 |
AF41 |
100010 |
AF42 |
100100 |
AF43 |
100110 |
be |
000000 |
CS1 |
001000 |
CS2 |
010000 |
CS3 |
011000 |
CS4 |
100000 |
CS5 |
101000 |
NC1/CS6 |
110000 |
NC2/CS7 |
111000 |
詳細については、「 デフォルトのCoS値とエイリアス」 を参照してください。
キューのスケジューラは、損失優先度を使用して、ドロッププロファイルを特定の損失優先度値に関連付けることで、混雑期間中のパケット破棄を制御します。(キューとスケジューラの設定については、 『サービスクラスユーザーガイド(セキュリティデバイス) 』を参照してください。)
ルールは、トラフィックグループに損失の優先度を適用します。損失優先度が高いということは、混雑期間中にパケットがドロップされる可能性が高いことを意味します。損失の優先度には4つのレベルがあります。
highmedium-highmedium-lowlow
ルールセットは、 class-of-service application-traffic-control 設定コマンドで定義されます。
[edit class-of-service] user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application application-name application-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application-group application-group-name application-group-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then forwarding-class fc-name user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then dscp-code-point bitmap user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then loss-priority loss-pri-value
レートリミッターとプロファイル
輻輳が発生すると、AppQoSはデバイス上のすべてのエグレスPICにレート制限を実装します。パケットが割り当てられた制限を超える場合、パケットは破棄されます。 レートリミッターは 、異なるクラスのトラフィックに対して、一貫したレベルのスループットとパケットロスの感度を維持します。すべてのエグレスPICは、同じレート制限スキームを採用しています。
PICの総帯域幅は約10Gbpsです。PIC用のレートリミッターハードウェアは、最大2Gbpsをプロビジョニングできます。そのため、レート制限の帯域幅の上限は231 bpsです。
レートリミッタープロファイルは、制限を定義します。 bandwidth-limit 仕様と burst-size-limit 仕様を独自に組み合わせたものです。 bandwidth-limit は、ポートを通過できる最大キロビット/秒を定義します。 burst-size-limit は、1 回のバーストでポートを通過できる最大バイト数を定義します。この burst-size-limit は、各バーストのサイズに限りがあることで、優先度の低いトラフィックの枯渇を軽減します。
AppQoSでは、デバイスあたり最大16のプロファイルと最大1000のレートリミッターを使用できます。複数のレートリミッターが同じプロファイルを使用できます。次の例では、2つのプロファイルを使用して5つのレートリミッターが定義されています。
レートリミッター名 |
プロフィール |
|
|---|---|---|
帯域幅制限 |
バーストサイズ制限 |
|
リミッター-1 |
200 |
26000 |
リミッター-2 |
200 |
26000 |
リミッター-3 |
200 |
26000 |
リミッター-4 |
400 |
52000 |
リミッター-5 |
400 |
52000 |
レートリミッターは、 class-of-service application-traffic-control 設定コマンドで定義されます。
[edit class-of-service] user@host# set application-traffic-control rate-limiters rate-limiter-name bandwidth-limit value-in-Kbps burst-rate-limit value-in-bytes
レートリミッターの割り当て
レートリミッターは、トラフィックの適用に基づいてルールに適用されます。各セッションには、 client-to-server と server-to-clientの2つのレートリミッターが適用されます。この用途により、各方向のトラフィックを個別にプロビジョニングできます。
レートリミッターによるトラフィック帯域幅の処理は、トラフィックの方向に関係なくパケットレベルで行われます。例えば、10Gのレートリミッターが1つだけ設定されている場合、イングレスとエグレスのトラフィックが同じラインカードからのものである場合、スループット(イングレスとエグレスの両方の方向を合わせた最大トラフィック)は最大10Gで、20Gにはできません。ただし、デバイスがIOCをサポートし(I/Oカード(IOC))を持ち、イングレストラフィックが1つのIOCを経由し、エグレストラフィックが他のIOCを経由する場合、10Gの単一のレートリミッターを設定した場合、20Gのスループットを期待できます。
同じルールセット内の異なるAppQoSルールは、レートリミッターを共有できます。この場合、これらのルールのアプリケーションは同じ帯域幅を共有します。同じレートリミッターを割り当てることができる1つのルールセット内のルール数に制限はありません。
以下の例は、前のセクションで定義したレートリミッターを割り当てる方法を示しています。例えば、ルールセットは、複数のルールで、一方または両方のフロー方向でレートリミッターを再利用できます。
ルールセット-1
ルール-1A
クライアントからサーバーへのリミッター-1
サーバーからクライアントへのリミッター-1
ルール-1B
クライアントからサーバーへのリミッター-1
サーバーからクライアントへのリミッター-1
複数のルールセットで同じプロファイルが必要な場合は、同じ bandwidth-limit と burst-size-limitを指定する十分な数のレートリミッターを定義する必要があります。次の例の 2 つのルール セットは、異なるが同等のレート リミッターを割り当てることで、同じプロファイルを実装します。
ルールセット-2
ルール-2A
クライアントからサーバーへのリミッター-2
サーバーからクライアントへのリミッター-2
ルール-2B
クライアントからサーバーへのリミッター-2
サーバーからクライアントへのリミッター-4
ルールセット-3
ルール-3A
クライアントからサーバーへのリミッター-3
サーバーからクライアントへのリミッター-3
ルール-3B
クライアントからサーバーへのリミッター-3
サーバーからクライアントへのリミッター-5
レートリミッターは、転送クラス、DSCP値、損失優先度の設定と同じ方法で edit class-of-service application-traffic-control rule-sets コマンドを使用して適用されます。
[edit class-of-service] user@host# set application-traffic-control rule-sets rule-set-name rule rule-name1 then rate-limit client-to-server rate-limiter1 server-to-client rate-limiter2
AppQoSとファイアウォールフィルターベースのレート制限が両方ともエグレスPICに実装されている場合は、両方が考慮されます。AppQoSレート制限が最初に考慮されます。その後、ファイアウォールフィルターベースのレート制限が発生します。
PICからパケットがドロップされた場合、デバイスはクライアントまたはサーバーに通知を送信しません。クライアントとサーバーデバイス上の上位アプリケーションが、再送信とエラー処理を担当します。
レートリミッターアクション
セキュリティデバイスのタイプに基づいて、AppQoSルールにさまざまなレートリミッターアクションを設定することができます。
破棄
このオプションを選択すると、プロファイル外パケットがドロップされます。
これはデフォルトのアクションタイプであり、設定する必要はありません。
このオプションは、すべてのセキュリティデバイスでサポートされています
損失優先度高
このオプションを選択すると、損失の優先度が最大に上がります。言い換えれば、それは遅延したドロップです。つまり、破棄の決定はエグレス出力キューレベルで行われます。輻輳がなければ、損失優先度が最大であってもトラフィックを許可します。しかし、輻輳が発生した場合は、これらの最大損失優先パケットを最初に破棄します。
このオプションは、次のコマンドを使用して、AppQoSルール内で(デフォルトのアクションを上書きするため)設定する必要があります。
[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high
-
このオプションは、選択したデバイスでサポートされています。 プラットフォーム固有のAppQoS動作 表を参照してください。
AppQoSセキュリティポリシーの設定
AppQoSルールセットは、既存のポリシーまたは特定のアプリケーションポリシーに実装できます。
[edit security policies from-zone zone-name to-zone zone-name]
user@host# set policy policy-name match source-address IP-address
user@host# set policy policy-name match destination-address IP-address
user@host# set policy policy-name match application application-name application-name
user@host# set policy policy-name then permit application-services application-traffic-control rule-set app-rule-set-name
関連項目
例:アプリケーションのサービス品質の設定
この例では、ポリシー内でAppQoSの優先度設定とレート制限を有効にする方法を示しています。
要件
この機能を設定する前に、デバイスの初期化以外の特別な設定を行う必要はありません。
概要
この例では、AppQoS が実装されているため、FTP アプリケーションは指定されたスループットを下回るレベルに制限され、他のアプリケーションは従来の速度と損失優先度レベルで送信されます。
設定
手順
この例をすばやく設定するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストします。
set class-of-service forwarding-classes queue 4 my-app-fc set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000 set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log set security policies from-zone trust to-zone untrust policy p1 match source-address any set security policies from-zone trust to-zone untrust policy p1 match destination-address any set security policies from-zone trust to-zone untrust policy p1 match application any set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set ftp-test1
ステップバイステップの手順
セキュリティデバイス上でAppQoSを設定するには:
-
AppQoSマーキング専用の転送クラスを1つ以上定義します。この例では、単一の転送クラスmy-app-fcが定義され、キュー4に割り当てられています。
[edit] user@host# set class-of-service forwarding-classes queue 4 my-app-fc
[edit] user@host# set class-of-service forwarding-classes class my-app-fc queue 4
ジュニパーネットワークスデバイスは、8つのキュー(0から7)をサポートします。デフォルトのキュー 0 から 3 は、デフォルトの転送クラスに割り当てられます。キュー4〜7にはFCへのデフォルトの割り当てはなく、マップされません。キュー 4 から 7 を使用するには、カスタム FC 名を作成し、キューにマップする必要があります。詳細については、「 フォワーディングクラスの概要」を参照してください。
レートリミッターを定義します。この例では、2つのレートリミッターが定義されています。
[edit] user@host# set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 user@host# set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 user@host# set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 user@host# set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000
-
AppQosルールとアプリケーションの一致基準を定義します。
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log
この例では、一致が行われると、パケットは転送クラスmy-app-fc、DSCP値はaf22、損失優先度は低でマークされます。両方向に同じレートリミッターを割り当てています。
単一のルールで、一方または両方のトラフィック方向にレートリミッターを割り当てることができます。また、ルールセット内の他のルールに同じレートリミッターを割り当てることもできます。ただし、同じレートリミッターを異なるルールセットに割り当てることはできません。
-
前のルールに一致しないアプリケーションパケットを処理する別のルールを定義します。この例では、残りのすべてのアプリケーションに 2 番目で最後のルールが適用されます。
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log
-
AppQoS設定をセキュリティポリシーに追加します。
[edit] user@host# set security policies from-zone trust to-zone untrust policy p1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match application any user@host# set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set app-test1
結果
設定モードから、 show security policies and show class-of-service コマンドを入力してポリシー設定を確認します。出力に意図した設定が表示されない場合は、この例の手順を繰り返して設定を修正します。
簡潔にするために、この show コマンド出力には、この例に関連する設定のみ含まれています。システム上のその他の設定はすべて省略記号(...)で置き換えられています。
...
policy p1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
application-traffic-control {
rule-set app-test1
}
}
}
}
}
...
user@host# show class-of-service
forwarding-classes {
queue 4 my-app-fc;
}
application-traffic-control {
rate-limiters test-rl {
bandwidth-limit 100;
burst-size-limit 13000;
}
rate-limiters test-r2 {
bandwidth-limit 200;
burst-size-limit 26000;
}
rule-sets app-test1 {
rule 0 {
match {
application [junos:FTP junos:HTTP];
}
then {
forwarding-class my-app-fc;
dscp-code-point af22;
loss-priority low;
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
rule 1 {
match {
application-any;
}
then {
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
}
}
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
設定が正常に機能していることを確認します。
フローセッション設定の検証
目的
AppQoSが有効になっていることを確認します。
アクション
動作モードから、 show security flow session application-traffic-control extensive コマンドを入力します。
user@host> show security flow session application-traffic-control extensive
Session ID: 3729, Status: Normal, State: Active
Flag: 0x40
Policy name: p1
Source NAT pool: Null
Dynamic application: junos:FTP
Application traffic control rule-set: app-test1, Rule: rule0
Maximum timeout: 300, Current timeout: 276
Session State: Valid
Start time: 18292, Duration: 603536
In: 192.0.2.1/1 --> 203.0.113.0/1;pim,
Interface: reth1.0,
Session token: 0x1c0, Flag: 0x0x21
Route: 0x0, Gateway: 192.0.2.4, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 21043, Bytes: 1136322
Out: 203.0.113.0/1 --> 192.0.2.0/1;pim,
Interface: .local..0,
Session token: 0x80, Flag: 0x0x30
Route: 0xfffd0000, Gateway: 192.0.2.0, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 0, Bytes: 0
意味
アプリケーショントラフィック制御のエントリーは、現在のセッションのルールセットとルールを識別します。
セッション統計の検証
目的
AppQoSセッション統計が各エグレスノードで蓄積されていることを確認します。
アクション
動作モードから、 show class-of-service application-traffic-control counter コマンドを入力します。
user@host> show class-of-service application-traffic-control counter pic: 2/1 Counter type Value Sessions processed 300 Sessions marked 200 Sessions honored 0 Sessions rate limited 100 Client-to-server flows rate limited 100 Server-to-client flows rate limited 100 pic: 2/0 Counter type Value Sessions processed 400 Sessions marked 300 Sessions honored 0 Sessions rate limited 200 Client-to-server flows rate limited 200 Server-to-client flows rate limited 200
意味
AppQoS 統計は、アプリケーショントラフィック制御サービスが有効になっている場合にのみ維持されます。処理、マーク、および承認されたセッションの数は、セッションが設定されたAppQoS機能に基づいて指示されていることを示しています。レート制限統計では、レート制限された指向性セッション フローの数がカウントされます。
レートリミッター統計の検証
目的
FTP アプリケーションが検出されたときに、帯域幅が予想通りに制限されていることを確認します。
アクション
動作モードから、 show class-of-service application-traffic-control statistics rate-limiter コマンドを入力します。
user@host> show class-of-service application-traffic-control statistics rate-limiter pic: 2/1 Ruleset Application Client-to-server Rate(kbps) Server-to-client Rate(kbps) app-test1 HTTP test-r2 200 test-r2 200 app-test1 HTTP test-r2 200 test-r2 200 appp–test1 FTP test-r1 100 test-r1 100
意味
各PICのリアルタイムアプリケーション帯域幅制限情報がルールセット別に表示されます。このコマンドは、アプリケーションがレート制限され、プロファイルが適用されていることを示します。
ルール統計の検証
目的
ルールがルールの統計と一致していることを確認します。
アクション
動作モードから、 show class-of-service application-traffic-control statistics rule コマンドを入力します。
user@host>show class-of-service application-traffic-control statistics rule pic: 2/1 Ruleset Rule Hits app-test1 0 100 app-test1 1 200 ... pic: 2/0 Ruleset Rule Hits app-test1 0 100 app-test1 1 200
意味
このコマンドは、各ルールセットに基づくルールの(セッション)ヒット数に関する情報を提供します。
統合ポリシーに対するアプリケーションのサービス品質サポート
統合ポリシーは、既存の5タプルまたは6タプル(ユーザーファイアウォール付きの5タプル)一致条件の一部として動的アプリケーションを使用して、時間の経過に伴うアプリケーションの変化を検出できるようにするセキュリティポリシーです。
アプリケーションサービス品質(AppQoS)は、セキュリティデバイスが統合ポリシーで設定されている場合にサポートされます。複数のセキュリティポリシーがトラフィックに一致する場合、統合ポリシーの競合を管理するためにデフォルトのAppQoSルールセットを設定できます。
AppQoSルールセットは、アプリケーション認識型のサービス品質制御を実装するための統合ポリシーに含まれています。 application-traffic-control オプションの下にルールを含むルールセットを設定し、AppQoSルールセットをアプリケーションサービスとして統合セキュリティポリシーにアタッチできます。トラフィックが指定された動的アプリケーションに一致し、ポリシーアクションが許可されている場合、アプリケーション認識型サービス品質が適用されます。
統合ポリシーにおける以下のAppQoS機能に留意してください。
従来のセキュリティポリシーから統合ポリシーへのアップグレード—統合ポリシーでは、
dynamic-applicationオプションをnoneとして設定すると、セキュリティポリシーの一致中にAppQoSルールセットが適用され、AppQoSは識別されたトラフィックに対応するルールを探します。これは、リリース18.2R1以前のJunos OSリリースのAppQoS機能でも同じ動作です。統合ポリシーを持つAppQoSルール—アプリケーショントラフィック制御設定では、AppQoSルールセットは一致条件を
application-anyとして設定し、統合ポリシーでは特定の動的アプリケーションを一致条件として使用すると、AppQoS機能は統合ポリシーのルールに従って機能します。
統合ポリシーのデフォルトのアプリケーションサービス品質ルールセットについて
AppQoSデフォルトルールセットを設定して、セキュリティポリシーの競合を管理できます。
初期ポリシールックアップフェーズは、動的アプリケーションを特定する前に行われます。異なるAppQoSルールセットを含むポリシーが複数潜在的なポリシーリストに存在する場合、セキュリティデバイスは、より明示的な一致が発生するまでデフォルトのAppQoSルールセットを適用します。
AppQoSは、 edit security ngfw 階層レベルでデフォルトのAppQoSルールセットとして設定できます。デフォルトのAppQoSルールセットは、 [edit class-of-service application-traffic-control] 階層レベルで設定された既存のAppQoSルールセットの1つから活用されます。
表2は 、統合ポリシーのさまざまなシナリオでのデフォルトのAppQoSルールセットの使用法をまとめたものです。
アプリケーション識別ステータス |
AppQoSルールセットの使用状況 |
アクション |
|---|---|---|
セキュリティポリシーの競合はありません。 |
[ |
AppQoSは、AppQoSルールセットと同様に適用されます。 |
セキュリティポリシーの競合と競合するポリシーには、個別のAppQoSルールセットがあります。 |
デフォルトのAppQoSルールセットが設定されていないか、見つかりません。 |
デフォルトのAppQoSプロファイルが設定されていないため、セッションは無視されます。 その結果、ポリシー競合シナリオで最終的に一致したポリシーにAppQoSルールセットが設定されていても、このルールセットは適用されません。セキュリティポリシーの競合を管理するには、デフォルトのAppQoSルールセットを設定することをお勧めします。 |
デフォルトのAppQoSルールセットが設定されます。 |
AppQoSは、デフォルトのAppQoSルールセットと同様に適用されます。 |
|
最終用途が特定される |
一致するセキュリティポリシーには、デフォルトのAppQoSルールセットと同じAppQoSルールセットがあります。 |
AppQoSは、デフォルトのAppQoSルールセットと同様に適用されます。 |
一致するセキュリティポリシーにはAppQoSルールセットがありません。 |
デフォルトのAppQoSルールセットは適用されず、AppQoSはセッションに適用されません。 |
|
一致するセキュリティポリシーには、すでに適用されているデフォルトのAppQoSルールセットとは異なるAppQoSルールセットがあります。 |
デフォルトのAppQoSルールセットは、デフォルトのAppQoSルールセットのままです。 |
デフォルトのAppQoSルールセットがトラフィックに適用されていて、最終セキュリティポリシーに異なるAppQoSルールセットがある場合、デフォルトのAppQoSルールセットから最終セキュリティポリシーのAppQoSルールセットへの切り替えはサポートされていません。
さまざまなシナリオで設定されたデフォルトのアプリケーションサービス品質ルール
以下のリンクは、さまざまなシナリオにおけるデフォルトのAppQoSルールセットについて説明した例を示しています。
表3は、一致条件として動的アプリケーションを使用する統合ポリシー用に設定されたさまざまなAppQoSルールセットを示しています。
セキュリティポリシー |
送信元ゾーン |
送信元IPアドレス |
宛先ゾーン |
宛先IPアドレス |
ポート番号 |
プロトコル |
動的アプリケーション |
サービス |
AppQoSルールセット |
|---|---|---|---|---|---|---|---|---|---|
ポリシー-P1 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
AppQoS |
AppQoS-1 |
|
ポリシー-P2 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
グーグル |
AppQoS |
AppQoS-2 |
ポリシー-P3 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
ユーチューブ |
AppQoS |
AppQoS-3 |
この例では、任意のAppQoSルールセット(AppQoS-1、AppQoS-2、AppQoS-3)を [security ngfw] 階層レベルのデフォルトAppQoSルールセットとして設定できます。デフォルトのルールセットがセキュリティポリシー設定の一部である必要はありません。 [edit class-of-service application-traffic-control] 階層レベルのAppQoSルールセットは、デフォルトのAppQoSルールセットとして割り当てることができます。
- ポリシーの競合なし—すべてのポリシーに同じAppQoSルールセットがあります
- ポリシーの競合なし—すべてのポリシーに同じAppQoSルールセットがあり、最終ポリシーにはAppQoSルールセットがありません
- ポリシーの競合—最終ポリシーに対してAppQoSルールセットは設定されていません
- ポリシー競合—デフォルトのAppQoSルールセットと、最終ポリシーの異なるAppQoSルールセット
ポリシーの競合なし—すべてのポリシーに同じAppQoSルールセットがあります
一致するポリシーには、 表4に示すように同じAppQoSルールセットがあります。
セキュリティポリシー |
送信元ゾーン |
送信元IPアドレス |
宛先ゾーン |
宛先IPアドレス |
ポート番号 |
プロトコル |
動的アプリケーション |
サービス |
AppQoSルールセット |
|---|---|---|---|---|---|---|---|---|---|
ポリシー-P1 |
S1 |
任意 |
D1 |
任意 |
任意 |
任意 |
AppQoS |
AppQoS-1 |
|
ポリシー-P2 |
S1 |
任意 |
D1 |
任意 |
任意 |
任意 |
グーグル |
AppQoS |
AppQoS-1 |
このシナリオでは、ポリシー Policy-P1 と Policy-P2 には同じ AppQoS ルール セットがあります。それがAppQoS-1です。ルールセットAppQoS-1が適用されます。このシナリオでは、ポリシーP3は設定されていません。
ルールセットAppQoS-2をデフォルトのルールセットとして設定している場合は、適用されません。これは、競合するポリシー(Policy-P1およびPolicy-P2)のAppQoSルールセットに競合がないためです。
ポリシーの競合なし—すべてのポリシーに同じAppQoSルールセットがあり、最終ポリシーにはAppQoSルールセットがありません
一致するすべてのポリシーには、 表5 に示すように同じAppQoSルールセットがあり、最終的なポリシーにはAppQoSルールセットがありません。
セキュリティポリシー |
送信元ゾーン |
送信元IPアドレス |
宛先ゾーン |
宛先IPアドレス |
ポート番号 |
プロトコル |
動的アプリケーション |
サービス |
AppQoSルールセット |
|---|---|---|---|---|---|---|---|---|---|
ポリシー-P1 |
S1 |
任意 |
D1 |
任意 |
任意 |
任意 |
AppQoS |
AppQoS-1 |
|
ポリシー-P2 |
S1 |
任意 |
D1 |
任意 |
任意 |
任意 |
グーグル |
AppQoS |
AppQoS-1 |
ポリシー-P3 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
ユーチューブ |
その他 |
なし |
このシナリオでは、ポリシーP1とポリシーP2の両方に同じAppQoSルールセット、つまりAppQoS-1があります。この場合、ルールセットAppQoS-1が適用されます。
最終ポリシーPolicy-P3に一致すると、AppQoSルールセットがPolicy-P3に対して設定されていないため、AppQoSはセッションを無視します。
最終セキュリティポリシーにAppQoSルールが設定されていない場合、AppQoSはトラフィックに適用されません。事前一致段階で適用されたすべてのAppQoS設定が元の値に戻ります。
ポリシーの競合—最終ポリシーに対してAppQoSルールセットは設定されていません
表 6に示すように、デフォルトのAppQoSルールセット(このシナリオではAppQoS-1)が潜在的なポリシー一致中に適用されます。最終ポリシーPolicy-P3にはAppQoSルールセットがありません。
セキュリティポリシー |
送信元ゾーン |
送信元IPアドレス |
宛先ゾーン |
宛先IPアドレス |
ポート番号 |
プロトコル |
動的アプリケーション |
サービス |
AppQoSルールセット |
|---|---|---|---|---|---|---|---|---|---|
ポリシー-P1 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
AppQoS |
AppQoS-1 |
|
ポリシー-P2 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
グーグル |
AppQoS |
AppQoS-2 |
ポリシー-P3 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
ユーチューブ |
その他 |
NA |
AppQoS は、最終一致するポリシー Policy-P3 が適用されている場合、セッションを無視します。
最終セキュリティポリシーにAppQoSルールが設定されていない場合、AppQoSはトラフィックに適用されません。この場合、事前一致段階で適用されたすべてのAppQoS設定が元の値に戻ります。
ポリシー競合—デフォルトのAppQoSルールセットと、最終ポリシーの異なるAppQoSルールセット
ルールセットAppQoS-1は、デフォルトのルールセットとして設定され、最終的なアプリケーションがまだ識別されていない場合に適用されます。最終ポリシーのポリシー-P3には、 表7に示すように、異なるAppQoSルールセット(AppQoS-3)があります。
セキュリティポリシー |
送信元ゾーン |
送信元IPアドレス |
宛先ゾーン |
宛先IPアドレス |
ポート番号 |
プロトコル |
動的アプリケーション |
サービス |
AppQoSルールセット |
|---|---|---|---|---|---|---|---|---|---|
ポリシー-P1 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
AppQoS |
AppQoS-1 |
|
ポリシー-P2 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
グーグル |
AppQoS |
AppQoS-2 |
ポリシー-P3 |
S1 |
50.1.1.1 |
D1 |
任意 |
任意 |
任意 |
ユーチューブ |
AppQoS |
AppQoS-3 |
最終アプリケーションが識別されると、ポリシーPolicy-P3が照合され、適用されます。この場合、ルールセットAppQoS-3は適用されません。代わりに、ルールセットAppQoS-1がデフォルトルールセットとして適用され、デフォルトのルールセットとして残ります。
統合ポリシーによるAppQoSの制限
一致するトラフィックにセキュリティポリシーが適用されると、AppQoSルールセットが許可されたトラフィックに適用されます。セキュリティポリシーと適用されたAppQoSルールセットの動的アプリケーションが異なる場合、次の例に示すように競合が発生する可能性があります。
user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 match application junos:GOOGLEuser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then forwarding-class network-controluser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then dscp-code-point 110001user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then loss-priority high
user@host#set security policies from-zone trust to-zone untrust policy 1 match source-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match destination-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match application anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match dynamic-application junos:FTPuser@host#set security policies from-zone trust to-zone untrust policy 1 then permit application-services application-traffic-control rule-set AQ2
この例では、アプリケーションのトラフィック制御ルールがjunos:GOOGLE用に設定されており、動的アプリケーションのセキュリティポリシーの一致条件はjunos:FTPです。このような場合、最終ポリシーが適用されるときに競合が発生する可能性があります。
関連項目
例:統合ポリシーによるアプリケーションのサービス品質の設定
この例では、統合ポリシー内でアプリケーションサービス品質(AppQoS)を有効にして、トラフィックに優先順位付けとレート制限を提供する方法を示しています。
要件
この例では、以下のハードウェアおよびソフトウェアコンポーネントを使用しています。
Junos OSリリース18.2R1以降を実行するSRXシリーズファイアウォール。この設定例は、Junos OSリリース18.2R1向けにテストされています。
この機能を設定する前に、デバイスの初期化以外の特別な設定を行う必要はありません。
概要
この例では、AppQoSルールセットを設定し、FacebookアプリケーションのセキュリティポリシーでアプリケーションサービスとしてAppQoSを呼び出します。
[edit security ngfw]階層レベルでデフォルトのAppQoSルールセットを定義し、セキュリティポリシーの競合があればそれを管理します。
設定
手順
ステップバイステップの手順
統合ポリシーでAppQoSを設定するには:
AppQoSルールセットを定義します。
[edit] user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 match application junos:FACEBOOK-APP user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then forwarding-class fc-appqos loss-priority medium-low dscp-code-point 101110 log user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then rate-limit client-to-server Ratelimit1 user@host# set class-of-service application-traffic-control rate-limiters Ratelimit1 bandwidth-limit 1000
デフォルトのAppQoSルールセットを設定します。アプリケーションのトラフィック制御の下で、デフォルトのAppQoSルールセットとして作成されたルールセット
RS1を選択します。[edit] user@host# set security ngfw default-profile application-traffic-control rule-set RS1
サービスクラスルールセットを統合ポリシーに関連付けます。
[edit] user@host# set security policies from-zone untrust to-zone trust policy from_internet match source-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match destination-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match application any user@host# set security policies from-zone untrust to-zone trust policy from_internet match dynamic-application junos:FACEBOOK-APP user@host# set security policies from-zone untrust to-zone trust policy from_internet then permit application-services application-traffic-control rule-set RS1
結果
設定モードから、 show security policies コマンドを入力してポリシー設定を確認します。出力に意図した設定が表示されない場合は、この例の手順を繰り返して設定を修正します。
簡潔にするために、この show コマンド出力には、この例に関連する設定のみ含まれています。システム上のその他の設定はすべて省略記号(...)で置き換えられています。
...
policies {
from-zone trust to-zone untrust {
policy permit-all {
match {
source-address any;
destination-address any;
application any;
dynamic-application junos:FACEBOOK-APP;
}
then {
permit {
application-services {
application-traffic-control {
rule-set RS1;
}
}
}
}
}
}
}
...
ngfw {
default-profile {
application-traffic-control {
rule-set RS1;
}
}
}
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
設定が正常に機能していることを確認します。
フローセッション設定の検証
目的
AppQoSセッションの統計情報を表示します。
アクション
動作モードから、 show class-of-service application-traffic-control counter コマンドを入力します。
出力例
コマンド名
pic: 0/0 Counter type Value Sessions processed 2 Sessions marked 1 Sessions honored 1 Sessions rate limited 1 Client-to-server flows rate limited 0 Server-to-client flows rate limited 1 Session default ruleset hit 1 Session ignored no default ruleset 1
意味
出力には、処理、マーク、尊重されたセッションの数が表示されます。レート制限統計では、レート制限された指向性セッション フローの数がカウントされます。
ルール統計の検証
目的
AppQoSルールの統計情報を表示します。
アクション
動作モードから、 show class-of-service application-traffic-control statistics rule コマンドを入力します。
user@host>show class-of-service application-traffic-control statistics rule
pic: 0/0
Ruleset Rule Hits
RS1 1 1
意味
出力には、各AppQoSルールセットの下でルールに一致したセッション数に関する情報が表示されます。
HTTP2:AppQoS DSCPサポート
HTTP/2アプリケーションサービス品質(AppQoS)差別化されたサービスコードポイント(DSCP)のサポートは、最初のストリーム分類を活用することで、HTTP/2セッション全体でのサービス品質(QoS)ルールの適用を強化します。この機能強化により、HTTP/2セッションにQoSルールを適用できるようになり、トラフィックがアプリケーションタイプに応じて分類され、優先順位が付けられるようになります。この機能により、HTTP/2トラフィックに詳細なAppQoSポリシーを適用できます。これは、異なるアプリケーションに分類された複数のストリームを処理する場合に不可欠です。最初のストリームセッションの分類に基づいてAppQoSルールを適用することで、不特定のルールが原因でフォールバックロジックが呼び出された場合でも、一貫したQoS管理を確保できます。この機能は、既存のHTTP/2トラフィック管理フレームワークに統合され、従来のポリシーケースと統合ポリシーケース全体のシナリオに対応し、追加のCLI設定なしで暗号化されたセッションで効果的なQoSの適用を維持できます。
概要
特定のHTTP/2ルールがない場合、HTTP/2トラフィックはDSCPマーキング用のHTTP AppQoSルールを継承するようになり、一貫したQoS動作が保証されます。
HTTP は、複数のアプリ(facebook、twitter など)が個別のセッションとして表示され、セッションごとに AppQoS が適用されて個別に分類される包括的なアプリケーションです。以前は、HTTP/2セッションはhttp2としてのみ分類され、子ストリームアプリケーションの分類はありませんでした
つまり、HTTP/2セッションでは、親セッションのAppQoSルールのみを適用できます。しかし、HTTP/2は複数のストリームを使用し、それぞれが異なるアプリケーションとして分類されます。AppQoSルールの一致では、子セッションの分類は無視されました。
新しい更新では、最初のストリームセッションのアプリケーション分類を使用して、AppQoSルールを照合し、HTTP/2親セッションに適用します。最初のストリームの最終分類アプリケーションにAppQoSルールがない場合、セッションは親HTTP/2 AppQoSルールにフォールバックします。
例:
複数のストリームを含むHTTP/2セッションについて考えてみましょう。
- 最初のストリームは twitter として識別されます。
- twitterのAppQoSルールが適用されます。
- HTTP/2親セッションのすべてのストリームは、ルールを継承します。
ここでは、パケットは汎用の http2 キューには移動しなくなります。それらは完全にFirst Streamのアプリケーションキュー(Twitter)に移動します。
フォールバックロジック
HTTP/2トラフィックは、HTTPトラフィックの一部として扱われます。HTTP/2ルールがない場合、トラフィックはDSCPマーキング用のHTTP AppQoSルールにフォールバックします。このフォールバックを実現するために、次の例に示すように分類パスが調整されます。
親セッション
- 以前の動作:
ip.tcp.ssl.http2 - 新しい動作:
ip.tcp.ssl.http.http2
子セッション
- 以前の動作:
ip.tcp.ssl.http.facebook - 新しい動作:
ip.tcp.ssl.http.http2.facebook
分類ロジック
AppQoS for HTTP/2 では、トップダウンのルール ルックアップを使用します。最も具体的なアプリから始めて、HTTP2、HTTP、SSL、application-any を経てフォールバックします。最初のストリームセッションの分類が親セッションルールの照合に使用され、正確なQoS割り当てとロギングが保証されます。
ルールセットとアプリケーションマッピング- 各セキュリティポリシーは、さまざまなアプリケーション(http、http2、facebookなど)に対して特定のAppQoSルールを持つルールセットを使用します。
- 各ルールは、転送クラス(ベストエフォート、保証フォワーディング、優先フォワーディング、ネットワーク制御)とCOSキューを割り当てます。
- AppQoSルールのルックアップは、最も具体的なアプリケーション(ネストされたアプリ)から開始し、階層を上に移動します。セッション(親/子)は、階層パス(例:
ip.tcp.ssl.http.http2.facebook)を使用して分類されます。この例では、検索シーケンスは次のとおりです。
- ネストされたアプリ(
facebook-chat)がルールセットで構成されていない場合、http2ルールが適用されます。 http2が設定されていない場合は、httpルールが適用されます。httpが設定されていない場合は、sslルールが適用されます。- 分類されたアプリに対してAppQoSルールが存在しない場合、
application-anyルールが適用されます。 application-anyが設定されていない場合、セッションは以前に適用されたDSCPルールで続行されます。
この分類により、HTTP/2セッションが無視されることはなく、常にQoS処理を受けることができます。
- ネストされたアプリ(
例:AppQoSプロファイルには、特定のアプリケーション向けのルールと「任意」のキャッチオールルールが含まれています。例えば、プロファイルにはHTTP、Facebook、Yahoo、Any のルールセットが含まれており、最初のストリームは次のように分類されます: http.http2.twitter
ケースA — 「任意」のルールが設定済み
- 明示的なTwitterルールは存在しません。
- Anyルールが存在するため、AppQoSはAnyを選択します。
- 結果: 任意ルールが適用されます。
ケースB — 「Any」ルールが設定されていません
- 明示的なTwitterルールは存在しません。
- 使用可能なルールはありません。
- この場合、システムは、特異度の降順で次に最適な一致にフォールバックします。
- HTTP2ルール(存在する場合)
- http2ルールがない場合→httpにフォールバックします
- デフォルトのキューを使用する→httpルールがない場合
- 結果: 上記のフォールバック順序に基づいて、最も近い一致ルールが選択されます。
- 親セッション:通常、上位レベル(例:http2)に分類されます。
- 子セッション: より具体的なネストされたアプリ(例:facebook、twitter)で分類されます。
これで、最初のストリームセッションの分類が、親セッションのルールマッチングで考慮されます。
フォワーディングとロギング- 各セッションのトラフィックには、一致したルールに基づいて転送クラスとキューが割り当てられます。
- Syslogエントリーは、セッションとストリーム終了の両方の分類とルールの一致を反映します
制限事項
- HTTP/2の場合、最初のストリームのアプリケーション分類のみが、親セッションのAppQoSルールマッチングに使用されます。
- 長時間のセッションでは、ミッドストリームのアプリスイッチ(HTTP/1またはHTTP/2)によってCoSキューが変更され、パケットの並べ替えが発生することがあります。エンドデバイスでのTCP再アセンブリは、シーケンス番号を使用してこれを処理します。
- AppQoSのHTTP/2は、シャーシクラスターおよびマルチノード高可用性のシナリオではサポートされていません。
- SSLフォワードプロキシが設定されている場合、HTTP/1.1とHTTP/2の両方のトラフィック設定で、AppQoSレートリミッターはHTTPSトラフィックに対して正しく機能しません。
HTTP2暗号化トラフィック
暗号化されたトラフィックの場合、HTTP/2 モジュールは無効になっているため、HTTP/2 子セッションは作成されません。AppQoSは、親セッションにのみ適用されます。
プラットフォーム固有のAppQoS動作
AppQoSと機能エクスプローラを使用して、特定の機能のプラットフォームおよびリリースサポートを確認します。
お使いのプラットフォームに固有の動作を確認するには、以下の表を使用して下さい:
| プラットフォーム |
違い |
|---|---|
| SRXシリーズ |
SRX5400、SRX5600、SRX5800では、転送クラス名とキュー割り当てを定義するために、以下の設定ステートメントを使用します。 [edit class-of-service] user@host# set forwarding-classes class forwarding-class-name queue-num queue-number |
| SRXシリーズ | SRX300、SRX320、SRX340、SRX345、SRX380、SRX400、SRX440、SRX550M、SRX1500、SRX4100、SRX4200、SRX4600、およびvSRXでは、転送クラス名とキュー割り当てを定義するために以下の設定ステートメントを使用します。 [edit class-of-service] user@host# set forwarding-classes queue queue-number forwarding-class-name |
| SRXシリーズ | SRX300、SRX320、SRX340、SRX345、SRX400、SRX440は、AppQoSルールの loss-priority-highオプションを使用して、デフォルトのアクションを上書きします。[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high |
| SRXシリーズ | SRX5400、SRX5600、SRX5800は、デバイスあたり最大1000のレートリミッターをサポートします。ただし、使用できるプロファイルは16個のみで、それぞれが帯域幅制限パラメーターとバーストサイズ制限パラメーターの一意の組み合わせによって定義されます。 |
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。