ALG アプリケーション
アプリケーションのプロパティの構成
アプリケーションのプロパティを設定するには、 階層レベルで ステートメントを含め application ます [edit applications] 。
[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(アプリケーションプロトコル)のどれを設定し、サービス処理用のアプリケーションセットに含めるかを指定できます。アプリケーション プロトコルを設定するには、 階層レベルで ステートメントを含め application-protocol ます [edit applications application application-name] 。
[edit applications application application-name] application-protocol protocol-name;
表 1 に、サポートされているプロトコルのリストを示します。特定のプロトコルの詳細については、「 ALG の説明」を参照してください。
プロトコル名 |
CLI値 |
コメント |
|---|---|---|
ブートストラップ プロトコル (BOOTP) |
|
BOOTP および DHCP(Dynamic Host Configuration Protocol)をサポートします。 |
分散コンピューティング環境 (DCE) リモート プロシージャ コール (RPC) |
|
ステートメントには |
DCE RPC ポートマップ |
|
ステートメントには |
Domain Name System(DNS) |
|
ステートメントに |
Exec |
|
ステートメントに |
Ftp |
|
ステートメントに |
H.323 |
|
– |
IKE ALG |
|
ステートメントには |
Internet Control Message Protocol(ICMP) |
|
ステートメントに |
インターネットORB間プロトコル |
|
– |
Ip |
|
– |
ログイン |
|
– |
Netbios |
|
ステートメントに |
ネットショー |
|
ステートメントに |
ポイントツーポイントトンネリングプロトコル |
|
– |
リアルオーディオ |
|
– |
リアルタイム ストリーミング プロトコル(RTSP) |
|
ステートメントに |
RPC ユーザー データグラム プロトコル(UDP)または TCP |
|
ステートメントには |
RPC ポート マッピング |
|
ステートメントには |
シェル |
|
ステートメントに |
セッション開始プロトコル |
|
– |
Snmp |
|
ステートメントに |
SQLNet |
|
ステートメントに |
トークプログラム |
|
|
トレース ルート |
|
ステートメントに |
Trivial FTP(TFTP) |
|
ステートメントに |
ウィンフレーム |
|
– |
同じサービス セットで 2 NAT が設定されている場合、ステートフル ファイアウォール、NAT、または CoS ルールの下で、ICMP およびトレース ルート用にアプリケーション レベル ゲートウェイ(ALG)を設定できます。これらの ALG は、パケット ゲートウェイ コントローラ プロトコル(PGCP)によって作成されたフローには適用できません。Twice NAT は他の ALG をサポートしていません。NAT は、IP アドレスと TCP または UDP ヘッダーのみを適用し、ペイロードには適用されません。
Twice NAT の設定の詳細については、 Junos Address Aware ネットワーク アドレス指定の概要を参照してください。
ネットワーク プロトコルの設定
ステートメント protocol を使用すると、サポートされているネットワーク プロトコルのどれをアプリケーション定義で一致させるかを指定できます。ネットワーク プロトコルを設定するには、 階層レベルで ステートメントを含め protocol ます [edit applications application application-name] 。
[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) は、アプリケーション定義でネットワーク プロトコルとしてサポートされていません。
デフォルトでは、twice NAT 機能は、ICMP エラー メッセージのペイロードに埋め込まれた IP、TCP、および UDP ヘッダーに影響を与える可能性があります。twice NAT 設定の場合、アプリケーション ステートメントに および protocol udp ステートメントを含めることができますprotocol tcp。Twice 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タイプによってグループ化されます。 パラメータ問題: リダイレクト: 超過時間: 到達不能: |
|
通常、 一致ステートメントと 数値の代わりに、(0)、(8)、(16)、(15)、(17)、(18)、(12)、(5)、(9)、(10)、(4)、(11)、 |
拒否アクションを含む入力ファイアウォールフィルターと、ステートフルファイアウォールルールを含むサービスセットを使用してインターフェイスを設定した場合、ルーターはステートフルファイアウォールルールがパケットに対して実行される前に入力ファイアウォールフィルターを実行します。その結果、パケット転送エンジンがインターフェイスを介してICMPエラーメッセージを送信すると、入力方向に表示されないため、ステートフルファイアウォールルールによってパケットが破棄される可能性があります。
考えられる回避策は、このタイプのフィルターが入力方向のステートフルファイアウォールの後に実行されるため、拒否アクションを実行するための転送テーブルフィルターを含めるか、ローカルで生成されたICMPパケットがステートフルファイアウォールサービスに送信されないようにする出力サービスフィルターを含めることです。
送信元ポートと宛先ポートの設定
TCP または UDP の送信元ポートと宛先ポートは、ネットワーク プロトコルと組み合わせて、アプリケーション定義でのパケット照合の追加仕様を提供します。ポートを設定するには、 階層レベルで および source-port のステートメントを含めdestination-portます[edit applications application application-name]。
[edit applications application application-name] destination-port value; source-port value;
送信元ポートまたは宛先ポートを 1 つ定義する必要があります。通常、この一致を match ステートメントと protocol 合わせて指定して、ポートで使用されているプロトコルを決定します。制約については、 表 1 を参照してください。
数値、または 表 4 にリストされているテキスト同義語の 1 つを指定できます。
ポート名 |
対応するポート番号 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一致条件の詳細については 、「 ルーティングポリシー、ファイアウォールフィルター、およびトラフィックポリサーユーザーガイド」を参照してください。
非アクティブタイムアウト期間の設定
アプリケーションの非アクティブのタイムアウト期間を指定できます。期間中にソフトウェアがアクティビティを検出しなかった場合、タイマーが期限切れになるとフローは無効になります。タイムアウト期間を設定するには、 階層レベルで ステートメントを含め inactivity-timeout ます [edit applications application application-name] 。
[edit applications application application-name] inactivity-timeout seconds;
デフォルト値は30秒です。アプリケーションに対して設定した値は、 階層レベルで設定された [edit interfaces interface-name service-options] グローバル値を上書きします。詳細については、 サービスインターフェイスのデフォルトタイムアウト設定の構成を参照してください。
IKE ALG アプリケーションの設定
Junos OS リリース 17.4R1 以前は、MX シリーズ ルーターの Junos VPN Site Secure IPsec 機能スイートでは、ネットワーク アドレス変換トラバーサル(NAT-T)はサポートされていません。IKE ALG を使用すると、NAT-T に準拠していない IPsec ピア間で、IKEv1 および IPsec パケットを NAPT-44 および NAT64 フィルターを介して渡すことができます。この 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)は、テレフォニー、FAX、ビデオ会議、インスタントメッセージング、ファイル交換などのインターネットサービスに関与するエンドポイント間の通信のための汎用プロトコルです。
Junos OSは、RFC 3261、 SIP:セッション開始プロトコルに記載されている標準に従ってALGサービスを提供します。Junos OSでのSIPフローは、RFC 3665、 セッション開始プロトコル(SIP)基本コールフローの例に記載されています。
Junos OS SIP ALG を実装する前に、「Junos OS SIP ALG の制限」で説明されている特定の制限事項について理解しておく必要があります
NAT を SIP ALG と組み合わせて使用すると、アドレス変換により SIP ヘッダー フィールドが変更されます。これらの変換の説明については、 『SIP ALG とネットワーク アドレス変換の相互作用』を参照してください。
適応サービスインターフェースにSIPを実装するには、 階層レベルで ステートメント[edit applications application application-name]を 値sipで設定しますapplication-protocol。このステートメントの詳細については、「アプリケーション プロトコルの設定」を参照してください。さらに、SIP の実装方法を変更するために設定できる他の 2 つのステートメントがあります。
ルーターが、NATファイアウォールの背後にあるエンドポイントデバイスへの着信SIPコールを受け入れるようにすることができます。ファイアウォールの内側にあるデバイスがファイアウォールの外側にあるプロキシに登録されると、ASまたはマルチサービスPICは登録状態を維持します。
learn-sip-registerステートメントが有効になっている場合、ルーターはこの情報を使用してインバウンドコールを受け入れることができます。このステートメントが設定されていない場合、着信コールは受け付けられません。ファイアウォールの背後のデバイスのみが、ファイアウォールの外側のデバイスを呼び出すことができます。SIP登録を設定するには、 階層レベルで ステートメントを含め
learn-sip-registerます[edit applications application application-name]。[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には適用されません。タイムアウト期間を設定するには、 階層レベルで ステートメントを含め
sip-call-hold-timeoutます[edit applications application application-name]。[edit applications application application-name] sip-call-hold-timeout seconds;
デフォルト値は 7200 秒で、範囲は 0 から 36,000 秒 (10 時間) からです。
SIP ALGとネットワークアドレス変換の相互作用
ネットワークアドレス変換(NAT)プロトコルを使用すると、プライベートサブネット内の複数のホストが単一のパブリックIPアドレスを共有してインターネットにアクセスできます。送信トラフィックの場合、NAT はプライベートサブネット内のホストのプライベート IP アドレスをパブリック IP アドレスに置き換えます。受信トラフィックの場合、パブリック IP アドレスはプライベート アドレスに変換され、メッセージはプライベート サブネット内の適切なホストにルーティングされます。
SIP メッセージには SIP ヘッダーと SIP 本文に IP アドレスが含まれているため、セッション開始プロトコル (SIP) サービスで NAT を使用すると、より複雑になります。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)チャネルとリアルタイム制御プロトコル(RTCP)チャネル用のシーケンシャル ポートを必要とするため、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は元の連絡先、経由、ルート、および記録ルートSIPフィールドをパケットに挿入し直します。
着信コール
着信コールは、パブリック ネットワークからデバイス上のパブリック スタティック NAT アドレスまたはインターフェイス IP アドレスに対して開始されます。静的 NAT は、内部ホストを指す静的に構成された IP アドレスです。インターフェイス IP アドレスは、内部ホストから SIP レジストラーに送信される REGISTER メッセージを ALG が監視する際に、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 は 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 の送信時間を確保します。
コール再招待メッセージ
ReINVITE メッセージは、新しいメディア セッションを通話に追加し、既存のメディア セッションを削除します。新しいメディア セッションが通話に追加されると、ファイアウォールで新しいピンホールが開かれ、新しいアドレス バインドが作成されます。このプロセスは、元のコール設定と同じです。通話から 1 つ以上のメディア セッションが削除されると、BYE メッセージと同様にピンホールが閉じられ、バインディングが解放されます。
通話セッションタイマー
SIP ALG は、Re-INVITE または UPDATE メッセージが受信されない場合、Session-Expires 値を使用してセッションをタイムアウトします。ALG は、INVITE に対する 200 OK 応答から Session-Expires 値 (存在する場合) を取得し、この値をシグナリング タイムアウトに使用します。セッションがタイムアウトする前にALGが別のINVITEを受信すると、ALGはすべてのタイムアウト値をこの新しいINVITEまたはデフォルト値にリセットし、プロセスが繰り返されます。
予防措置として、SIP ALG はハード タイムアウト値を使用して、コールが存在することができる最大時間を設定します。これにより、次のいずれかのイベントが発生した場合にデバイスが保護されます。
通話中にエンドシステムがクラッシュし、BYE メッセージが受信されない。
悪意のあるユーザーが SIP ALG を攻撃しようとして BYE を送信することはありません。
SIPプロキシの実装が不十分な場合、レコードルートの処理に失敗し、BYEメッセージを送信することはありません。
ネットワーク障害により、BYE メッセージを受信できない。
通話キャンセル
どちらのパーティも、CANCEL メッセージを送信して呼び出しを取り消すことができます。CANCEL メッセージを受信すると、SIP ALG はファイアウォールを介してピンホールを閉じ (開いている場合)、アドレス バインドを解放します。リソースを解放する前に、ALG は制御チャネルのエージアウトを約 5 秒間遅らせて、最後の 200 OK が通過する時間を確保します。呼び出しは、487 応答または非 200 応答が到着したかどうかに関係なく、5 秒のタイムアウトが経過すると終了します。
フォーク
フォークを使用すると、SIP プロキシーは 1 つの INVITE メッセージを複数の宛先に同時に送信できます。1 つのコールに対して複数の 200 OK 応答メッセージが到着すると、SIP ALG は受信した最初の 200 OK メッセージでコール情報を解析しますが、更新します。
SIPメッセージ
SIP メッセージ形式は、SIP ヘッダー セクションと SIP 本文で構成されます。要求メッセージでは、ヘッダー セクションの最初の行は要求行であり、メソッドの種類、要求 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 はメッセージがネットワークの内部から送信されたか外部から送信されたかだけでは不十分であることに注意してください。また、呼び出しを開始したクライアントと、メッセージが要求か応答かを判断する必要もあります。
インバウンド要求 (パブリックからプライベートへ) |
宛先： |
ドメインをローカルアドレスに置き換える |
差出人： |
なし |
|
コールID: |
なし |
|
を介して： |
なし |
|
Request-URI: |
ALGアドレスをローカルアドレスに置換 |
|
連絡先： |
なし |
|
レコードルート: |
なし |
|
ルート： |
なし |
|
アウトバウンド応答 (プライベートからパブリックへ) |
宛先： |
ALGアドレスをローカルアドレスに置換 |
差出人： |
なし |
|
コールID: |
なし |
|
を介して： |
なし |
|
Request-URI: |
N/a |
|
連絡先： |
ローカルアドレスをALGアドレスに置換 |
|
レコードルート: |
ローカルアドレスをALGアドレスに置換 |
|
ルート： |
なし |
|
アウトバウンド要求 (プライベートからパブリックへ) |
宛先： |
なし |
差出人： |
ローカルアドレスをALGアドレスに置換 |
|
コールID: |
なし |
|
を介して： |
ローカルアドレスをALGアドレスに置換 |
|
Request-URI: |
なし |
|
連絡先： |
ローカルアドレスをALGアドレスに置換 |
|
レコードルート: |
ローカルアドレスをALGアドレスに置換 |
|
ルート： |
ALGアドレスをローカルアドレスに置換 |
|
アウトバウンド応答 (パブリックからプライベートへ) |
宛先： |
なし |
差出人： |
ALGアドレスをローカルアドレスに置換 |
|
コールID: |
なし |
|
を介して： |
ALGアドレスをローカルアドレスに置換 |
|
Request-URI: |
N/a |
|
連絡先： |
なし |
|
レコードルート: |
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 チャネルをサポートし、通話ごとに合計 12 チャネルをサポートします。
Junos OS SIP ALG の制限
SIP ALG の設定には、次の制限が適用されます。
RFC 3261 で説明されているメソッドのみがサポートされています。
SIP バージョン 2 のみがサポートされています。
TCP は、MS-MPC のシグナリング メッセージのトランスポート メカニズムとしてはサポートされていませんが、次世代サービスではサポートされています。
STUNを使用する場合は、SIP ALGを設定しないでください。 クライアントが STUN/TURN を使用して発信者とレスポンダまたはプロキシ間のファイアウォールまたは NAT デバイスを検出する場合、クライアントは NAT デバイスの動作を推測し、それに応じてコールを発信しようとします。
MS-MPC では、エンドポイント非依存マッピング NAT プール オプションを SIP ALG と組み合わせて使用しないでください。 エラーが発生します。これは、次世代サービスには適用されません。
IPv6 シグナリング データは、MS-MPC ではサポートされていませんが、次世代サービスではサポートされています。
認証はサポートされていません。
暗号化されたメッセージはサポートされていません。
SIP フラグメント化は、MS-MPC ではサポートされていませんが、次世代サービスではサポートされています。
SIP メッセージを含む最大 UDP パケット サイズは 9 KB と想定されます。これより大きいSIPメッセージはサポートされていません。
SIP メッセージ内のメディア チャネルの最大数は 6 であると想定されます。
完全修飾ドメイン名 (FQDN) は、重要なフィールドではサポートされていません。
QoSはサポートされていません。SIP は DSCP 書き換えをサポートしています。
高可用性は、ウォーム スタンバイを除き、サポートされていません。
タイムアウト設定 never は、SIP または NAT ではサポートされていません。
マルチキャスト(フォーク プロキシ)はサポートされていません。
パケット照合のための SNMP コマンドの設定
パケット照合にSNMPコマンド設定を指定できます。SNMP を構成するには、 ステートメントを snmp-command [edit applications application application-name] 階層レベルで記述します。
[edit applications application application-name] snmp-command value;
サポートされている値はget、 、 set、 get-nexttrapです。照合に設定できる値は 1 つだけです。階層レベルのステートメント[edit applications application application-name]はapplication-protocol、 の値snmpを持つ必要があります。アプリケーション プロトコルの指定については、「アプリケーション プロトコルの設定」を参照してください。
RPC プログラム番号の設定
パケット照合に RPC プログラム番号を指定できます。RPC プログラム番号を構成するには、 rpc-program-number ステートメントを [edit applications application application-name] 階層レベルで記述します。
[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値を設定するには、 階層レベルで ステートメントを含め ttl-threshold ます [edit applications application application-name] 。
[edit applications application application-name] ttl-threshold value;
階層レベルのステートメント[edit applications application application-name]はapplication-protocol、 の値tracerouteを持つ必要があります。アプリケーション プロトコルの指定については、「アプリケーション プロトコルの設定」を参照してください。
ユニバーサル一意識別子の設定
DCE RPC オブジェクトのユニバーサル一意識別子 (UUID) を指定できます。UUID値を設定するには、 階層レベルで ステートメントを含め uuid ます [edit applications application application-name] 。
[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-setapplicationことにより、定義したアプリケーションを名前付きオブジェクトにグループ化できます。
[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)、送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、フロー状態、方向、フレーム数などのフロー情報が表示されます。
フローの状態は、 、 、
ForwardDropのいずれかですWatch。フロー状態は
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 informationALG 名 (FTP ALG) と ASL グループ ID (1) と ASL リソース ID (制御セッションの場合は 0、データ セッションの場合は 1) を含めて、セッションが ALG によって作成されたことを示します。3行目
Inは順方向フローで、4行Out目は逆方向フローで、送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、プロトコル(TCP)、セッション接続タグ、インターフェイスのIn着信と発信Out、受信フレーム数、バイトが含まれます。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: 1受け入れフローシステムログの作成:
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。
メモ：ALG 処理が実行されており、クライアントが基本的にアプリケーションに対応するペイロードを「監視」または処理しているため、フローの状態は と表示されます
Watch。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
システムログメッセージの完全なリストについては、 システムログエクスプローラを参照してください。