ALGアプリケーション
アプリケーションプロパティの設定
アプリケーションのプロパティを設定するには、[edit applications]階層レベルでapplicationステートメントを含めます。
[edit applications] application application-name { application-protocol protocol-name; child-inactivity-timeout seconds; destination-port port-number; gate-timeout seconds; icmp-code value; icmp-type value; inactivity-timeout value; protocol type; rpc-program-number number; snmp-command command; source-port port-number; ttl-threshold value; uuid hex-value; }
application-setステートメントを設定することで、アプリケーションオブジェクトをグループ化できます。詳細については、アプリケーションセットの設定を参照してください。
このセクションでは、アプリケーションを設定するための以下のタスクについて説明します。
- アプリケーションプロトコルの設定
- ネットワークプロトコルの設定
- ICMPコードとタイプの設定
- 送信元ポートと宛先ポートの設定
- 非アクティブタイムアウト期間の設定
- IKE ALGアプリケーションの設定
- SIPの設定
- パケット照合のためのSNMPコマンドの設定
- RPCプログラム番号の設定
- TTLしきい値の設定
- ユニバーサル一意識別子の設定
アプリケーションプロトコルの設定
application-protocolステートメントでは、サポートされているアプリケーションプロトコル(ALG)のうち、どのアプリケーションプロトコルを設定し、サービス処理用のアプリケーションセットに含めるかを指定できます。アプリケーションプロトコルを設定するには、[edit applications application application-name]階層レベルでapplication-protocolステートメントを含めます。
[edit applications application application-name] application-protocol protocol-name;
表1 は、サポートされているプロトコルのリストを示しています。特定のプロトコルの詳細については、 ALGの説明を参照してください。
プロトコル名 |
CLI値 |
コメント |
|---|---|---|
ブートストラッププロトコル(BOOTP) |
|
BOOTPおよびDHCP(ダイナミックホスト構成プロトコル)をサポートします。 |
分散コンピューティング環境(DCE)リモートプロシージャコール(RPC) |
|
|
DCE RPCポートマップ |
|
|
ドメインネームシステム(DNS) |
|
|
実行 |
|
|
FTP |
|
|
H.323 |
|
– |
IKEアルゴリズム |
|
|
インターネット制御メッセージプロトコル(ICMP) |
|
|
インターネットORB間プロトコル |
|
– |
IP |
|
– |
ログイン |
|
– |
NetBIOS |
|
|
ネットショー |
|
|
ポイントツーポイントトンネリングプロトコル |
|
– |
RealAudio |
|
– |
リアルタイムストリーミングプロトコル(RTSP) |
|
|
RPC User Datagram Protocol(UDP)または TCP |
|
|
RPCポートマッピング |
|
|
シェル |
|
|
セッション開始プロトコル |
|
– |
SNMP |
|
|
SQLNet |
|
|
トークプログラム |
|
|
トレースルート |
|
|
トリビアルFTP(TFTP) |
|
|
WinFrame |
|
– |
同じサービスセットで2回NATが設定されている場合、ICMP用のアプリケーションレベルゲートウェイ(ALG)を設定し、ステートフルファイアウォール、NAT、またはCoSルールの下でルートをトレースできます。これらのALGは、PGCP(パケットゲートウェイコントローラプロトコル)によって作成されたフローには適用できません。Twice NATは、他のALGをサポートしていません。NATは、IPアドレスとTCPまたはUDPヘッダーのみを適用し、ペイロードには適用しません。
2 回 NAT の設定の詳細については、「 Junos Address Aware ネットワークアドレッシングの概要」を参照してください。
ネットワークプロトコルの設定
protocolステートメントを使用すると、アプリケーション定義で一致させるサポートされているネットワークプロトコルを指定できます。ネットワークプロトコルを設定するには、[edit applications application application-name]階層レベルでprotocolステートメントを含めます。
[edit applications application application-name] protocol type;
プロトコルタイプは数値で指定します。より一般的に使用されるプロトコルでは、テキスト名もコマンドラインインターフェイス(CLI)でサポートされています。 表2 は、サポートされているプロトコルのリストを示しています。
ネットワークプロトコルタイプ |
CLI値 |
コメント |
|---|---|---|
IPセキュリティ(IPsec)認証ヘッダー(AH) |
|
– |
外部ゲートウェイ・プロトコル(EGP) |
|
– |
IPsecカプセル化セキュリティペイロード(ESP) |
|
– |
一般的なルーティングカプセル化(GR) |
|
– |
ICMP |
|
|
ICMPv6 |
|
|
インターネットグループ管理プロトコル(IGMP) |
|
– |
IP in IP |
|
– |
OSPF |
|
– |
プロトコル独立マルチキャスト(PIM) |
|
– |
リソース予約プロトコル(RSVP) |
|
– |
TCP |
|
|
UDP |
|
|
使用可能な数値の完全なリストについては、RFC 1700、 割り当てられた番号(インターネットプロトコルスイート用)を参照してください。
IPバージョン6(IPv6)は、アプリケーション定義のネットワークプロトコルとしてサポートされていません。
デフォルトでは、2回のNAT機能は、ICMPエラーメッセージのペイロードに埋め込まれたIP、TCP、およびUDPヘッダーに影響を与える可能性があります。アプリケーションステートメントに protocol tcp および protocol udp ステートメントを含めることで、2回NAT設定することができます。2 回 NAT の設定の詳細については、「 Junos Address Aware ネットワークアドレッシングの概要」を参照してください。
ICMPコードとタイプの設定
ICMPコードとタイプは、ネットワークプロトコルと組み合わせて、アプリケーション定義でのパケット一致のための追加の仕様を提供します。ICMP設定を構成するには、[edit applications application application-name]階層レベルでicmp-codeおよびicmp-typeステートメントを含めます。
[edit applications application application-name] icmp-code value; icmp-type value;
含めることができるICMPコードとタイプ値は1つだけです。 application-protocol ステートメントには、 icmp値が必要です。 表3は 、サポートされているICMP値のリストを示しています。
CLIステートメント |
説明 |
|---|---|
|
この値またはキーワードは、 数値の代わりに、以下のテキスト同義語(フィールド値も記載されています)のいずれかを指定します。キーワードは、それらが関連するICMPタイプによってグループ化されます。 パラメータ問題: リダイレクト: time-exceeded: 到達不能: |
|
通常、 数値の代わりに、次のテキスト同義語(フィールド値も記載されています)のいずれかを指定できます: |
拒否アクションを含む入力ファイアウォールフィルターとステートフルファイアウォールルールを含むサービスセットでインターフェイスを設定した場合、ステートフルファイアウォールルールがパケットで実行される前に、ルーターは入力ファイアウォールフィルターを実行します。その結果、パケット転送エンジンがインターフェイスを介してICMPエラーメッセージを送信したときに、入力方向にパケットが表示されないため、ステートフルファイアウォールルールでパケットがドロップされる可能性があります。
可能な回避策は、入力方向のステートフルファイアウォールの後に実行されるため、拒否アクションを実行するための転送テーブルフィルターを含めるか、ローカルで生成されたICMPパケットがステートフルファイアウォールサービスに行かないように出力サービスフィルターを含めることです。
送信元ポートと宛先ポートの設定
TCPまたはUDPの送信元ポートと宛先ポートは、ネットワークプロトコルと組み合わせて、アプリケーション定義内のパケット一致のための追加の仕様を提供します。ポートを設定するには、[edit applications application application-name]階層レベルでdestination-portおよびsource-portステートメントを含めます。
[edit applications application application-name] destination-port value; source-port value;
送信元または宛先ポートを1つ定義する必要があります。通常、ポートで使用されているプロトコルを決定するには、 protocol match ステートメントと合わせてこの一致を指定します。制約については 、表 1 を参照してください。
数値または 表4に示すテキスト同義語のいずれかを指定できます。
ポート名 |
対応するポート番号 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一致基準の詳細については、 ルーティングポリシー、ファイアウォールフィルター、およびトラフィックポリサーユーザーガイドを参照してください。
非アクティブタイムアウト期間の設定
アプリケーションの非アクティブのタイムアウト期間を指定できます。その間にソフトウェアがアクティビティを検出しなかった場合、タイマーが終了するとフローは無効になります。タイムアウト期間を設定するには、[edit applications application application-name]階層レベルでinactivity-timeoutステートメントを含めます。
[edit applications application application-name] inactivity-timeout seconds;
デフォルト値は30秒です。アプリケーションに設定した値は、 [edit interfaces interface-name service-options] 階層レベルで設定されたグローバル値を上書きします。詳細については、「 サービスインターフェイスのデフォルトのタイムアウト設定の設定」を参照してください。
IKE ALGアプリケーションの設定
Junos OSリリース17.4R1以前では、MXシリーズルーターのIPsec機能のJunos VPN Site Secureスイートでは、ネットワークアドレス変換トラバーサル(NAT-T)はサポートされていません。IKE ALGは、NAT-Tに準拠していないIPsecピア間で、NAPT-44およびNAT64フィルターを介してIKEv1およびIPsecパケットを通過させることができます。このALGは、ESPトンネルモードのみをサポートします。宛先ポート(500)、非アクティブタイムアウト(30秒)、ゲートタイムアウト(120秒)、ESPセッションアイドルタイムアウト(800秒)の定義された値を持つ、定義済みのIKE ALGアプリケーション junos-ikeを使用できます。定義済みの junos-ike アプリケーションとは異なる値でIKE ALGを使用する場合は、新しいIKE ALGアプリケーションを設定する必要があります。
IKE ALGアプリケーションを設定するには:
アプリケーションの名前を指定します。
[edit applications] user@host# set application junos-ike
IKE ALGを指定します。
[edit applications application junos-ike] user@host# set application-protocol ike-esp-nat
UDPプロトコルを指定します。
[edit applications application junos-ike] user@host# set protocol udp
宛先ポートに500を指定します。
[edit applications application junos-ike] user@host# set destination-port 500
-
IKEセッションが削除されるまで非アクティブになるまでの秒数を指定します。デフォルトは30秒です。
[edit applications application junos-ike] user@host# set inactivity-timeout seconds
IKEがIPsecクライアントとサーバーの間にセキュリティアソシエーションを確立してから、ESPトラフィックが双方向に開始されるまでの経過時間を秒数で指定します。このタイムアウト値までに ESP トラフィックが開始されていない場合、ESP ゲートは削除され、ESP トラフィックはブロックされます。デフォルトは120秒です。
[edit applications application junos-ike] user@host# set gate-timeout seconds
ESP セッション(IPsec データ トラフィック)のアイドル タイムアウトを秒単位で指定します。この間にESPセッションでIPsecデータトラフィックが渡されない場合、セッションは削除されます。デフォルトは800秒です。
[edit applications application junos-ike] user@host# set child-inactivity-timeout seconds
SIPの設定
SIP(Session Initiation Protocol)は、テレフォニー、FAX、ビデオ会議、インスタントメッセージング、ファイル交換などのインターネットサービスに関与するエンドポイント間の通信のための汎用化されたプロトコルです。
Junos OSは、RFC 3261、 SIP:セッション開始プロトコルに記載されている標準に従ってALGサービスを提供します。Junos OS での SIP フローは、RFC 3665、 セッション開始プロトコル(SIP)の基本的なコールフローの例に記載されているとおりです。
Junos OS SIP ALGを実装する前に、「Junos OS SIP ALGの制限事項」で説明されている特定の制限事項について理解しておく必要があります
SIP ALGとNATを組み合わせて使用すると、アドレス変換によりSIPヘッダーフィールドが変更されます。これらの変換の説明については、 SIP ALGとネットワークアドレス変換の相互作用を参照してください。
アダプティブ サービス インターフェイスに SIP を実装するには、[edit applications application application-name] 階層レベルで application-protocol ステートメントを値 sip で設定します。このステートメントの詳細については、アプリケーションプロトコルの設定を参照してください。さらに、SIPの実装方法を変更するために設定できるステートメントが他に2つあります。
ルーターが、NATファイアウォールの背後にあるエンドポイントデバイスの着信SIPコールを受け入れるようにすることができます。ファイアウォールの背後にあるデバイスがファイアウォールの外側にあるプロキシに登録すると、ASまたはマルチサービスPICは登録状態を維持します。
learn-sip-registerステートメントが有効になっている場合、ルーターはこの情報を使用して着信コールを受け入れることができます。このステートメントが設定されていない場合、着信コールは受け入れられません。ファイアウォールの内側にあるデバイスのみが、ファイアウォール外側のデバイスを呼び出すことができます。SIP 登録を設定するには、
[edit applications application application-name]階層レベルでlearn-sip-registerステートメントを含めます。[edit applications application application-name] learn-sip-register;
注:learn-sip-registerステートメントは、次世代サービスMX-SPC3には適用されません。また、
show services stateful-firewall sip-registerコマンドを発行して、SIPレジスタを手動で検査することもできます。詳細については、 『Junos OSシステムの基本とサービスコマンドリファレンス』を参照してください。show services stateful-firewall sip-registerコマンドは、次世代サービスではサポートされていません。保留になっているSIPコールの期間中のタイムアウト期間を指定できます。通話が保留になると、アクティビティはなく、設定された
inactivity-timeout期間が経過した後にフローがタイムアウトし、通話状態が破棄されることがあります。これを回避するために、コールが保留になると、フロータイマーがsip-call-hold-timeoutサイクルにリセットされ、コールの状態とフローがinactivity-timeout期間よりも長く保持されます。注:sip-call-hold-timeoutステートメントは、次世代サービスMX-SPC3には適用されません。タイムアウト期間を設定するには、
[edit applications application application-name]階層レベルでsip-call-hold-timeoutステートメントを含めます。[edit applications application application-name] sip-call-hold-timeout seconds;
デフォルト値は7200秒で、範囲は0〜36,000秒(10時間)です。
SIP ALGとネットワークアドレス変換の相互作用
ネットワークアドレス変換(NAT)プロトコルを使用すると、プライベートサブネット内の複数のホストが単一のパブリックIPアドレスを共有してインターネットにアクセスできます。発信トラフィックの場合、NATはプライベートサブネット内のホストのプライベートIPアドレスをパブリックIPアドレスに置き換えます。受信トラフィックの場合、パブリックIPアドレスはプライベートアドレスに変換され、メッセージはプライベートサブネット内の適切なホストにルーティングされます。
セッション開始プロトコル(SIP)サービスで NAT を使用すると、SIP メッセージのヘッダーと SIP 本文に IP アドレスが含まれているため、より複雑になります。SIP サービスで NAT を使用する場合、SIP ヘッダーには発信者と受信者に関する情報が含まれており、デバイスはこの情報を変換して外部ネットワークから非表示にします。SIP 本文には、メディア送信用の IP アドレスとポート番号を含む SDP(セッション記述プロトコル)情報が含まれています。デバイスは、メディアを送受信するためのリソースを割り当てるためにSDP情報を変換します。
SIPメッセージのIPアドレスとポート番号の置換方法は、メッセージの方向によって異なります。送信メッセージの場合、クライアントのプライベートIPアドレスとポート番号は、ジュニパーネットワークスファイアウォールのパブリックIPアドレスとポート番号に置き換えられます。受信メッセージの場合、ファイアウォールのパブリックアドレスがクライアントのプライベートアドレスに置き換えられます。
INVITEメッセージがファイアウォールを越えて送信されると、SIPアプリケーション層ゲートウェイ(ALG)は、メッセージヘッダーからコールテーブルに情報を収集し、それを使用して後続のメッセージを正しいエンドポイントに転送します。ACKや200 OKなどの新しいメッセージが到着すると、ALGは「From:、To:、Call-ID:」フィールドをコールテーブルと比較して、メッセージのコールコンテキストを特定します。既存のコールと一致する新しいINVITEメッセージが届くと、ALGはそれをREINVITEとして処理します。
SDP情報を含むメッセージが到着すると、ALGはポートを割り当て、ポートとSDP内のポートの間にNATマッピングを作成します。SDPはRTP(Real-Time Transport Protocol)およびRTCP(Real-Time Control Protocol)チャネル用のシーケンシャルポートを必要とするため、ALGは連続した偶数奇数ポートを提供します。ポートのペアが見つからない場合は、SIPメッセージを破棄します。
このトピックでは、次のセクションについて説明します。
発信コール
内部ネットワークから外部ネットワークへのSIP要求メッセージでSIPコールが開始されると、NATはSDP内のIPアドレスとポート番号を置き換え、IPアドレスとポート番号をジュニパーネットワークスのファイアウォールにバインドします。Via、Contact、Route、およびRecord-Route SIPヘッダーフィールドも存在する場合、ファイアウォールIPアドレスにバインドされます。ALGは、再送信やSIP応答メッセージに使用するために、これらのマッピングを保存します。
次に、SIP ALGはファイアウォールにピンホールを開き、SDPおよびVia、Contact、Record-Routeヘッダーフィールドの情報に基づいてネゴシエートされた動的に割り当てられたポートでデバイスを通過できるようにします。ピンホールにより、着信パケットが連絡先、経由、記録ルートのIPアドレスとポートに到達することもできます。リターントラフィックを処理する際、ALGは元のContact、Via、Route、Record-Route SIPフィールドをパケットに挿入し直します。
着信
着信コールは、パブリックネットワークからデバイス上のパブリックスタティックNATアドレスまたはインターフェイスIPアドレスに対して開始されます。静的NATは、内部ホストを指す静的に設定されたIPアドレスです。インターフェイスIPアドレスは、内部ホストからSIPレジストラに送信されるREGISTERメッセージを監視する際に、ALGによって動的に記録されます。デバイスが着信SIPパケットを受信すると、セッションを設定し、パケットのペイロードをSIP ALGに転送します。
ALGはSIPリクエストメッセージ(最初はINVITE)を調べ、SDPの情報に基づいて、送信メディアのゲートを開きます。200 OK応答メッセージが到着すると、SIP ALGはIPアドレスとポートに対してNATを実行し、アウトバウンド方向にピンホールを開きます。(開いたゲートは存続時間が短く、200 OK応答メッセージがすぐに受信されないとタイムアウトします。
200 OK応答が到着すると、SIPプロキシはSDP情報を調べ、各メディアセッションのIPアドレスとポート番号を読み取ります。デバイス上のSIP ALGは、アドレスとポート番号に対してNATを実行し、アウトバウンドトラフィックのピンホールを開き、インバウンド方向のゲートのタイムアウトを更新します。
ACKが200 OKに到着すると、SIP ALGも通過します。メッセージにSDP情報が含まれている場合、SIP ALGはIPアドレスとポート番号が前回のINVITEから変更されていないことを確認します。変更されている場合、ALGは古いピンホールを削除し、メディアを通過させるために新しいピンホールを作成します。また、ALGは、Via、Contact、Record-Route SIPフィールドを監視し、これらのフィールドが変更されたと判断した場合は、新しいピンホールを開きます。
転送された通話
転送されたコールとは、例えば、ネットワーク外のユーザ A がネットワーク内のユーザ B にコールを呼び出し、ユーザ B がネットワーク外のユーザ C にコールを転送する場合です。SIP ALGは、ユーザーAからのINVITEを通常の着信コールとして処理します。しかし、ALGがネットワーク外のBからCへの転送されたコールを調べ、BとCが同じインターフェイスを使用して到達していることに気付いた場合、メディアがユーザーAとユーザーCの間で直接流れるため、ファイアウォールにピンホールが開かないことはありません。
通話の終了
BYE メッセージは通話を終了します。デバイスがBYEメッセージを受信すると、他のメッセージの場合と同様にヘッダーフィールドを変換します。しかし、BYE メッセージは受信者によって 200 OK で確認する必要があるため、ALG はコールの破棄を 5 秒間遅らせて、200 OK の送信に時間を確保します。
コール Re-INVITE メッセージ
Re-INVITEメッセージは、通話に新しいメディアセッションを追加し、既存のメディアセッションを削除します。新しいメディア セッションが通話に追加されると、ファイアウォールに新しいピンホールが開き、新しいアドレス バインディングが作成されます。このプロセスは、元のコール設定と同じです。1 つ以上のメディア セッションが通話から削除されると、BYE メッセージと同様にピンホールが閉じられ、バインディングが解放されます。
セッションタイマーの呼び出し
SIP ALGは、Re-INVITEまたはUPDATEメッセージを受信しない場合、セッションExpires値を使用してセッションをタイムアウトします。ALGは、INVITEに対する200 OK応答からSession-Expires値(存在する場合)を取得し、この値をシグナリングのタイムアウトに使用します。セッションがタイムアウトする前にALGが別のINVITEを受信した場合、ALGはすべてのタイムアウト値をこの新しいINVITEまたはデフォルト値にリセットし、このプロセスが繰り返されます。
予防措置として、SIP ALGはハードタイムアウト値を使用して、コールが存在できる最大時間を設定します。これにより、次のいずれかのイベントが発生した場合に、デバイスが保護されます。
通話中にエンド システムがクラッシュし、BYE メッセージが受信されない。
悪意のあるユーザーが SIP ALG を攻撃しようとして BYE を送信することはありません。
SIPプロキシの実装が不十分だと、Record-Routeの処理に失敗し、BYEメッセージが送信されません。
ネットワーク障害により、BYE メッセージを受信できません。
通話のキャンセル
どちらの当事者も、CANCELメッセージを送信して通話をキャンセルできます。CANCELメッセージを受信すると、SIP ALGはファイアウォールを通るピンホールを閉じ(開いている場合は)、アドレスバインディングを解除します。リソースを解放する前に、ALGは制御チャネルのエージアウトを約5秒間遅らせて、最後の200のOKが通過する時間を確保します。5秒間のタイムアウトが終了すると、487または非200応答のどちらが到着したかに関係なく、通話は終了します。
フォーク
フォークにより、SIPプロキシは単一のINVITEメッセージを複数の宛先に同時に送信できます。1 つのコールに対して複数の 200 件の OK 応答メッセージが到着すると、SIP ALG は受信した最初の 200 件の OK メッセージでコール情報を解析しますが、更新します。
SIPメッセージ
SIP メッセージ形式は、SIP ヘッダー セクションと SIP 本文で構成されています。リクエストメッセージでは、ヘッダーセクションの最初の行はリクエスト行であり、これにはメソッドタイプ、request-URI、プロトコルバージョンが含まれます。応答メッセージでは、最初の行は状態コードを含む状態行です。SIPヘッダーには、シグナリングに使用されるIPアドレスとポート番号が含まれています。ヘッダー セクションから空白行で区切られた SIP 本文は、セッション記述情報用に予約されており、これはオプションです。Junos OSは現在、SDPのみをサポートしています。SIP 本文には、メディアの伝送に使用される IP アドレスとポート番号が含まれています。
SIPヘッダー
次のサンプルSIPリクエストメッセージでは、NATがヘッダーフィールドのIPアドレスを置き換えて、外部ネットワークから非表示にしています。
INVITE bob@10.150.20.5SIP/2.0 Via: SIP/2.0/UDP10.150.20.3:5434 From: alice@10.150.20.3To: bob@10.150.20.5Call-ID: a12abcde@10.150.20.3Contact: alice@10.150.20.3:5434 Route: <sip:netscreen@10.150.20.3:5060> Record-Route: <sip:netscreen@10.150.20.3:5060>
IPアドレス変換の実行方法は、メッセージのタイプと方向によって異なります。メッセージは次のいずれかです。
インバウンドリクエスト
アウトバウンド応答
アウトバウンドリクエスト
インバウンド応答
表5は 、これらの各ケースでNATがどのように実行されるかを示しています。いくつかのヘッダーフィールドについて、ALGが判断するのは、メッセージがネットワークの内部から来たか外部からかということだけではありません。また、どのクライアントが呼び出しを開始したか、メッセージが要求か応答かを判断する必要があります。
インバウンドリクエスト (パブリックからプライベートへ) |
宛先： |
ドメインをローカルアドレスに置き換える |
差出人： |
なし |
|
Call-ID: |
なし |
|
経由: |
なし |
|
Request-URI: |
ALGアドレスをローカルアドレスに置き換えます |
|
コンタクト: |
なし |
|
Record-Route: |
なし |
|
ルート: |
なし |
|
アウトバウンド応答 (プライベートからパブリックへ) |
宛先： |
ALGアドレスをローカルアドレスに置き換えます |
差出人： |
なし |
|
Call-ID: |
なし |
|
経由: |
なし |
|
Request-URI: |
該当なし |
|
コンタクト: |
ローカルアドレスをALGアドレスに置き換えます |
|
Record-Route: |
ローカルアドレスをALGアドレスに置き換えます |
|
ルート: |
なし |
|
アウトバウンドリクエスト (プライベートからパブリックへ) |
宛先： |
なし |
差出人： |
ローカルアドレスをALGアドレスに置き換えます |
|
Call-ID: |
なし |
|
経由: |
ローカルアドレスをALGアドレスに置き換えます |
|
Request-URI: |
なし |
|
コンタクト: |
ローカルアドレスをALGアドレスに置き換えます |
|
Record-Route: |
ローカルアドレスをALGアドレスに置き換えます |
|
ルート: |
ALGアドレスをローカルアドレスに置き換えます |
|
アウトバウンド応答 (パブリックからプライベートへ) |
宛先： |
なし |
差出人： |
ALGアドレスをローカルアドレスに置き換えます |
|
Call-ID: |
なし |
|
経由: |
ALGアドレスをローカルアドレスに置き換えます |
|
Request-URI: |
該当なし |
|
コンタクト: |
なし |
|
Record-Route: |
ALGアドレスをローカルアドレスに置き換えます |
|
ルート: |
ALGアドレスをローカルアドレスに置き換えます |
SIP本文
SIP本文のSDP情報には、ALGがメディアストリームのチャネルを作成するために使用するIPアドレスが含まれています。SDPセクションの変換では、リソース、つまりメディアを送受信するためのポート番号も割り当てられます。
次のサンプル SDP セクションからの抜粋は、リソース割り当て用に変換されたフィールドを示しています。
o=user 2344234 55234434 IN IP410.150.20.3c=IN IP410.150.20.3m=audio43249RTP/AVP 0
SIP メッセージには、複数のメディア ストリームを含めることができます。この概念は、電子メール メッセージに複数のファイルを添付するのと似ています。例えば、SIP クライアントから SIP サーバーに送信された INVITE メッセージには、以下のフィールドがある場合があります。
c=IN IP410.123.33.4m=audio33445RTP/AVP 0 c=IN IP410.123.33.4m=audio33447RTP/AVP 0 c=IN IP410.123.33.4m=audio33449RTP/AVP 0
Junos OSは、各方向にネゴシエートされた最大6個のSDPチャネルをサポートし、1つの通話で合計12個のチャネルをサポートします。
Junos OS SIP ALGの制限事項
SIP ALGの設定には、以下の制限が適用されます。
RFC 3261に記載されているメソッドのみがサポートされます。
SIPバージョン2のみがサポートされます。
TCPは、MS-MPCのシグナリングメッセージのトランスポートメカニズムとしてはサポートされていませんが、次世代サービスではサポートされています。
STUNを使用する場合は、SIP ALGを設定しないでください。 クライアントがSTUN/TURNを使用して、発信者と応答者またはプロキシの間のファイアウォールまたはNATデバイスを検出する場合、クライアントはNATデバイスの動作を最適に推測し、それに応じて行動してコールを発信しようとします。
MS-MPCでは、SIP ALGとエンドポイントに依存しないマッピングNATプールオプションを使用しないでください。 エラーが発生します。これは、次世代サービスには適用されません。
IPv6シグナリングデータはMS-MPCではサポートされていませんが、次世代サービスではサポートされています。
認証はサポートされていません。
暗号化されたメッセージはサポートされていません。
SIPフラグメント化はMS-MPCではサポートされていませんが、次世代サービスではサポートされています。
SIP メッセージを含む UDP パケットの最大サイズは 9 KB と想定されます。これより大きいSIPメッセージはサポートされていません。
SIPメッセージ内の最大メディアチャネル数は6と想定されます。
完全修飾ドメイン名(FQDN)は、重要なフィールドではサポートされていません。
QoSはサポートされていません。SIP は DSCP 書き換えをサポートします。
ウォームスタンバイを除き、高可用性はサポートされていません。
なしのタイムアウト設定は、SIPまたはNATではサポートされていません。
マルチキャスト(フォークプロキシ)はサポートされていません。
パケット照合のためのSNMPコマンドの設定
パケット照合のSNMPコマンド設定を指定できます。SNMPを設定するには、[edit applications application application-name]階層レベルでsnmp-commandステートメントを含めます。
[edit applications application application-name] snmp-command value;
サポートされている値は、get、get-next、set、およびtrapです。マッチングには1つの値のみを設定できます。[edit applications application application-name]階層レベルのapplication-protocolステートメントには、値snmpが必要です。アプリケーションプロトコルの指定については、アプリケーションプロトコルの設定を参照してください。
RPCプログラム番号の設定
パケット照合用のRPCプログラム番号を指定できます。RPCプログラム番号を設定するには、[edit applications application application-name]階層レベルにrpc-program-numberステートメントを含めます。
[edit applications application application-name] rpc-program-number number;
DCEまたはRPCに使用される値の範囲は、100,000〜400,000です。[edit applications application application-name]階層レベルのapplication-protocolステートメントには、値rpcが必要です。アプリケーションプロトコルの指定については、アプリケーションプロトコルの設定を参照してください。
TTLしきい値の設定
トレース ルートのTTL(Time-to-Live)しきい値を指定して、トレース ルーティングのネットワーク浸透の許容レベルを制御できます。TTL値を設定するには、[edit applications application application-name]階層レベルでttl-thresholdステートメントを含めます。
[edit applications application application-name] ttl-threshold value;
[edit applications application application-name]階層レベルのapplication-protocolステートメントには、値tracerouteが必要です。アプリケーションプロトコルの指定については、アプリケーションプロトコルの設定を参照してください。
ユニバーサル一意識別子の設定
DCE RPCオブジェクトにユニバーサル一意識別子(UUID)を指定できます。UUID値を設定するには、[edit applications application application-name]階層レベルでuuidステートメントを含めます。
[edit applications application application-name] uuid hex-value;
uuid値は16進数です。[edit applications application application-name階層レベルのapplication-protocolステートメントには、値dce-rpcが必要です。アプリケーションプロトコルの指定については、アプリケーションプロトコルの設定を参照してください。UUID番号の詳細については、「http://www.opengroup.org/onlinepubs/9629399/apdxa.htm」を参照してください。
関連項目
アプリケーションセットの設定
定義したアプリケーションを名前付きオブジェクトにグループ化するには、[edit applications]階層レベルでapplication-setステートメントと各アプリケーションに対してapplicationステートメントを含めます。
[edit applications]
application-set application-set-name {
application application;
}
典型的なアプリケーションセットの例については、 例:アプリケーションプロトコルの設定を参照してください。
例:アプリケーションプロトコルの設定
次の例は、ポート 78 で実行される特別な FTP アプリケーションを記述するアプリケーション プロトコル定義を示しています。
[edit applications]
application my-ftp-app {
application-protocol ftp;
protocol tcp;
destination-port 78;
timeout 100; # inactivity timeout for FTP service
}
以下の例は、タイプ8(ICMPエコー)の特別なICMPプロトコル(application-protocol icmp)を示しています。
[edit applications]
application icmp-app {
application-protocol icmp;
protocol icmp;
icmp-type icmp-echo;
}
以下の例は、使用可能なアプリケーションセットを示しています。
[edit applications]
application-set basic {
http;
ftp;
telnet;
nfs;
icmp;
}
ソフトウェアには、よく知られたアプリケーションプロトコルの定義済みセットが含まれています。このセットには、TCPおよびUDP宛先ポートがステートレスファイアウォールフィルターによって既に認識されているアプリケーションが含まれます。
ALGセッションの出力の検証
このセクションには、ALGセッションからの成功した出力例とシステムログ設定に関する情報が含まれています。セッションの結果を比較して、設定が正しく機能しているかどうかを確認できます。
FTPの例
この例では、アクティブな FTP セッション中の出力を分析します。これは、4つの異なるフローで構成されています。2つは制御フロー、2つはデータフローです。この例は、以下の部分で構成されています。
出力例
MS-MPCカード
MS-MPCの場合、 show services stateful-firewall conversations application-protocol ftp 運用モードコマンドの完全なサンプル出力を以下に示します。
user@host>show services stateful-firewall conversations application-protocol ftp
Interface: ms-1/3/0, Service set: CLBJI1-AAF001
Conversation: ALG protocol: ftp
Number of initiators: 2, Number of responders: 2
Flow State Dir Frm count
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13
NAT source 1.1.79.2:14083 -> 194.250.1.237:50118
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12
NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
各フローについて、最初の行は、プロトコル(TCP)、送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、フロー状態、方向、フレーム数などのフロー情報を示しています。
フローの状態は、
Watch、Forward、またはDropです。Watchフロー状態は、ペイロード内の情報について制御フローがALGによって監視されていることを示します。NAT処理は、必要に応じてヘッダーとペイロードに対して実行されます。Forwardフローは、ペイロードを監視せずにパケットを転送します。必要に応じて、ヘッダーに対してNATが実行されます。Dropフローは、5タプルに一致するパケットを破棄します。
フレーム カウント(
Frm count)は、そのフローで処理されたパケットの数を示します。
2行目はNAT情報を示しています。
source送信元NATを示します。dest宛先 NAT を示します。NAT行の最初のアドレスとポートは、そのフロー用に変換される元のアドレスとポートです。
NAT行の2番目のアドレスとポートは、そのフローの変換されたアドレスとポートです。
MX-SPC3カード
MX-SPC3サービスカードでは、 show services sessions application-protocol ftp 運用モードコマンドの完全なサンプル出力を以下に示します。
user@host>show services sessions application-protocol ftp Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239, Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650, Total sessions: 2
各セッションについて:
最初の行は、セッションID、サービスセット名、ポリシー名、セッションタイムアウト、論理システム名、およびその状態などのフロー情報を示しています。
2行目の
Resource informationは、ALG名(FTP ALG)とASLグループID(1)、ASLリソースID(制御セッションの場合は0、データセッションの場合は1)を含め、ALGによってセッションが作成されたことを示しています。3行目
Inは順方向フロー、4行目Outは逆方向フローで、送信元アドレス、送信元ポート、宛先ポート、プロトコル(TCP)、セッションconn-tag、OutInインターフェイスの着信および発信、受信フレーム数、バイト数が含まれます。必要に応じて、ヘッダーに対してNATが実行されます。
FTPシステムログメッセージ
システムログメッセージは、FTPセッション中に生成されます。システムログの詳細については、 システムログメッセージを参照してください。
MS-MPCカード
以下のシステムログメッセージは、FTP制御フローの作成中に生成されます。
ルール システムログを受け入れる:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, Match SFW accept rule-set:, rule: ftp, term: 1Accept Flowシステムログの作成:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, creating forward or watch flowデータフロー作成のシステムログ:
Oct 27 11:43:30 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_FTP_ACTIVE_ACCEPT: proto 6 (TCP) application: ftp, so-2/1/2.0:2.2.2.2:20 -> 1.1.1.2:50726, Creating FTP active mode forward flow
MX-SPC3カードカード
以下のシステムログメッセージは、FTP制御フローの作成中に生成されます。
FTP制御セッション作成のシステムログ:
Mar 23 23:58:54 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 N/A(N/A) ge-1/0/2.0 UNKNOWN UNKNOWN UNKNOWN N/A N/A -1 N/A Mar 23 23:59:00 esst480r junos-alg: RT_ALG_FTP_ACTIVE_ACCEPT: application:ftp data, vms-3/0/0.0 30.1.1.2:20 -> 20.1.1.2:33947 (TCP)
FTPデータセッション作成のシステムログ:
Mar 23 23:59:00 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 N/A(N/A) ge-1/1/6.0 FTP-DATA UNKNOWN UNKNOWN Infrastructure File-Servers 2 N/A
FTPデータセッション破棄のシステムログ:
Mar 23 23:59:02 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed TCP FIN: 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 2954(4423509) 281(14620) 2 FTP-DATA UNKNOWN N/A(N/A) ge-1/1/6.0 No Infrastructure File-Servers 2 N/A
FTP制御セッション破棄のシステムログ:
Mar 23 23:59:39 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed Closed by junos-tcp-clt-emul: 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 23(1082) 18(1176) 45 UNKNOWN UNKNOWN N/A(N/A) ge-1/0/2.0 No N/A N/A -1 N/A
分析
制御フロー
MS-MPCカード
制御フローは、3 ウェイ ハンドシェイクが完了した後に確立されます。
FTPクライアントからFTPサーバーへのフローを制御します。TCP宛先ポートは21です。
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13 NAT source 1.1.79.2:14083 -> 194.250.1.237:50118FTPサーバーからFTPクライアントへのフローを制御します。TCP送信元ポートは21です。
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12 NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
MX-SPC3カード
制御フローは、3 ウェイ ハンドシェイクが完了した後に確立されます。
FTPクライアントからFTPサーバーへの制御セッション、TCP宛先ポートは21です。
Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650,
FTPクライアントからFTPサーバーへのデータセッションは、FTPパッシブモード用です。
Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239,
FTPサーバーからFTPクライアントへのデータセッションは、FTPアクティブモード用です。
Session ID: 549978117, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 22.20.20.3/20 --> 60.1.1.3/6049;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 10, Bytes: 8291, Out: 12.10.10.10/33203 --> 22.20.20.3/20;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 5, Bytes: 268,
データフロー
20のデータポートは、FTP制御プロトコルの過程でデータ転送のためにネゴシエートされます。これらの 2 つのフローは、FTP クライアントと FTP サーバー間のデータ フローです。
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
トラブルシューティングに関する質問
FTP ALGがアクティブかどうかはどうすればわかりますか?
会話の ALG プロトコル フィールドに
ftpが表示されるはずです。制御フローには有効なフレーム数(
Frm count)が必要です。データフロー内の有効なフレームカウントは、データ転送が行われたことを示します。
FTP接続が確立されているのにデータ転送が行われない場合、何を確認すればよいですか?
ほとんどの場合、制御接続はアップしているが、データ接続はダウンしている。
会話の出力をチェックして、制御フローとデータフローの両方が存在するかどうかを判断します。
各フローをどのように解釈すればよいですか?それぞれのフローには何が意味するのか?
FTP 制御フロー イニシエータ フロー - 宛先ポート 21 のフロー
FTP 制御フロー レスポンダー フロー - 送信元ポートとのフロー。21
FTP データ フロー イニシエータ フロー - 宛先ポート 20 のフロー
FTP データ フロー レスポンダー フロー - 送信元ポート 20 のフロー
RTSP ALGの例
次に、RTSP 会話の例を示します。アプリケーションは、制御接続にRTSPプロトコルを使用します。接続が確立されると、メディアはUDPプロトコル(RTP)を使用して送信されます。
この例は以下で構成されています。
MS-MPC の出力例
以下に、 show services stateful-firewall conversations 運用モードコマンドの出力を示します。
user@host# show services stateful-firewall conversations Interface: ms-3/2/0, Service set: svc_set Conversation: ALG protocol: rtsp Number of initiators: 5, Number of responders: 5 Flow State Dir Frm count TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 UDP 1.1.1.3:1028 -> 2.2.2.2:1028 Forward I 0 UDP 1.1.1.3:1029 -> 2.2.2.2:1029 Forward I 0 UDP 1.1.1.3:1030 -> 2.2.2.2:1030 Forward I 0 UDP 1.1.1.3:1031 -> 2.2.2.2:1031 Forward I 0 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5 UDP 2.2.2.2:1028 -> 1.1.1.3:1028 Forward O 6 UDP 2.2.2.2:1029 -> 1.1.1.3:1029 Forward O 0 UDP 2.2.2.2:1030 -> 1.1.1.3:1030 Forward O 3 UDP 2.2.2.2:1031 -> 1.1.1.3:1031 Forward O 0
MX-SPC3サービスカードの出力例
以下に、 show services sessions application-protocol rtsp 運用モードコマンドの出力を示します。
user@host# run show services sessions application-protocol rtsp Session ID: 1073741828, Service-set: sset1, Policy name: p1/131081, Timeout: 116, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 0 In: 31.0.0.2/33575 --> 41.0.0.2/554;tcp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 8, Bytes: 948, Out: 41.0.0.2/554 --> 131.10.0.1/7777;tcp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 6, Bytes: 1117, Session ID: 1073741829, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 1 In: 41.0.0.2/35004 --> 131.10.0.1/7780;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 79200, Out: 31.0.0.2/30004 --> 41.0.0.2/35004;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Session ID: 1073741830, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 4 In: 41.0.0.2/35006 --> 131.10.0.1/7781;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 174240, Out: 31.0.0.2/30006 --> 41.0.0.2/35006;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Total sessions: 3
分析
RTSP 会話は、RTSP 制御接続に対応する TCP フローで構成する必要があります。クライアントからサーバーとサーバーからクライアントの各方向に 1 つずつ、2 つのフローが存在する必要があります。
TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5
イニシエーターフローのRTSP制御接続は、宛先ポート554から送信されます。
レスポンダフローのRTSP制御接続は、送信元ポート554から送信されます。
UDPフローは、RTSP接続を介して送信されたRTPメディアに対応します。
トラブルシューティングに関する質問
RTSP ALGが設定されている場合、メディアは機能しません。どうしようか。
RTSP の会話をチェックして、TCP フローと UDP フローの両方が存在するかどうかを確認します。
ALGプロトコルは
rtspとして表示されているはずです。
注:フローの状態が
Watchとして表示されます。これは、ALG処理が行われており、クライアントが本質的にアプリケーションに対応するペイロードを「監視」または処理しているためです。FTPおよびRTSP ALGフローの場合、制御接続は常にフローWatchです。ALGエラーを確認するにはどうすればよいですか?
以下のコマンドを発行することで、エラーをチェックできます。各ALGには、ALGパケットエラー用の個別のフィールドがあります。
user@host# show services stateful-firewall statistics extensive Interface: ms-3/2/0 Service set: svc_set New flows: Accepts: 1347, Discards: 0, Rejects: 0 Existing flows: Accepts: 144187, Discards: 0, Rejects: 0 Drops: IP option: 0, TCP SYN defense: 0 NAT ports exhausted: 0 Errors: IP: 0, TCP: 276 UDP: 0, ICMP: 0 Non-IP packets: 0, ALG: 0 IP errors: IP packet length inconsistencies: 0 Minimum IP header length check failures: 0 Reassembled packet exceeds maximum IP length: 0 Illegal source address: 0 Illegal destination address: 0 TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0 Land attack: 0 Non-IPv4 packets: 0, Bad checksum: 0 Illegal IP fragment length: 0 IP fragment overlap: 0 IP fragment reassembly timeout: 0 Unknown: 0 TCP errors: TCP header length inconsistencies: 0 Source or destination port number is zero: 0 Illegal sequence number and flags combinations: 0 SYN attack (multiple SYN messages seen for the same flow): 276 First packet not a SYN message: 0 TCP port scan (TCP handshake, RST seen from server for SYN): 0 Bad SYN cookie response: 0 UDP errors: IP data length less than minimum UDP header length (8 bytes): 0 Source or destination port number is zero: 0 UDP port scan (ICMP error seen for UDP flow): 0 ICMP errors: IP data length less than minimum ICMP header length (8 bytes): 0 ICMP error length inconsistencies: 0 Duplicate ping sequence number: 0 Mismatched ping sequence number: 0 ALG errors: BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0 DNS: 0, Exec: 0, FTP: 0 ICMP: 0 Login: 0, NetBIOS: 0, NetShow: 0 RPC: 0, RPC portmap: 0 RTSP: 0, Shell: 0 SNMP: 0, SQLNet: 0, TFTP: 0 Traceroute: 0
システムログメッセージ
システムログ生成を有効にし、システムログを確認することも、ALGフロー分析に役立ちます。このセクションには次の内容が含まれています。
システムログの設定
Junos OS CLIでは、さまざまなレベルでシステムログメッセージの有効化を設定できます。次の構成例に示すように、レベルの選択は、イベントログの具体性と含めるオプションによって異なります。設定オプションの詳細については、 ルーティングデバイス用 Junos OS 運用ライブラリ (システムレベル)またはルーティング デバイス用 Junos OS サービスインターフェイスライブラリ (その他のすべてのレベル)を参照してください。
最上位のグローバルレベルでは:
user@host# show system syslog file messages { any any; }サービスセットレベルでは:
user@host# show services service-set svc_set syslog { host local { services any; } } stateful-firewall-rules allow_rtsp; interface-service { service-interface ms-3/2/0; }サービスルールレベルでは:
user@host# show services stateful-firewall rule allow_rtsp match-direction input-output; term 0 { from { applications junos-rtsp; } then { accept; syslog; } }
システムログ出力
システムログメッセージは、以下の例に示すように、フロー作成中に生成されます。
次のシステム ログ メッセージは、ASP が受け入れルールに一致したことを示しています。
Oct 25 16:11:37 (FPC Slot 3, PIC Slot 2) {svc_set}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: rtsp, ge-2/0/1.0:1.1.1.2:35595 -> 2.2.2.2:554, Match SFW accept rule-set: , rule: allow_rtsp, term: 0
システムログメッセージの完全なリストについては、 システムログエクスプローラを参照してください。