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 コードとICMP タイプの設定
- 送信元ポートと宛先ポートの設定
- 非アクティブ タイムアウト期間の設定
- IKE ALG アプリケーションの設定
- SIP の設定
- パケット マッチングのための SNMP コマンドの設定
- RPC プログラム番号の設定
- TTL しきい値を構成する
- ユニバーサル一意識別子の設定
アプリケーション プロトコルの設定
application-protocolステートメントでは、サポートされているアプリケーションプロトコル(ALGs)のうち、どのアプリケーションプロトコル(ALGs)を設定し、サービス処理用のアプリケーションセットに含めるかを指定できます。アプリケーション プロトコルを設定するには、[edit applications application application-name]階層レベルで application-protocol ステートメントを含めます。
[edit applications application application-name] application-protocol protocol-name;
表 1 は、サポートされているプロトコルの一覧を示しています。特定のプロトコルの詳細については、 ALGの説明を参照してください。
プロトコル名 |
CLI値 |
コメント |
|---|---|---|
ブートストラップ プロトコル(BOOTP) |
|
BOOTPおよびDHCP(Dynamic Host Configuration Protocol)をサポートします。 |
分散コンピューティング環境 (DCE) リモート プロシージャー コール (RPC) |
|
|
DCE RPC ポートマップ |
|
|
ドメイン生成アルゴリズム(DNS) |
|
|
エグゼクティブ |
|
|
FTP |
|
|
H.323 |
|
– |
IKE ALG |
|
|
Internet Control Message Protocol(ICMP) |
|
|
インターネットORB間プロトコル |
|
– |
IP |
|
– |
ログイン |
|
– |
NetBIOS |
|
|
ネットショー |
|
|
ポイントツーポイントトンネリングプロトコル |
|
– |
RealAudio(リアルオーディオ) |
|
– |
リアルタイム ストリーミング プロトコル(RTSP) |
|
|
RPCユーザーデータグラムプロトコル(UDP)またはTCP |
|
|
RPC ポート マッピング |
|
|
貝 |
|
|
セッション開始プロトコル |
|
– |
SNMP |
|
|
SQLNetの |
|
|
トークプログラム |
|
|
トレースルート |
|
|
トリビアルFTP(TFTP) |
|
|
WinFrame(ウィンフレーム) |
|
– |
同じサービス セットで Twice NAT が設定されている場合、ステートフル ファイアウォール、NAT、または CoS ルールの下で、ICMP およびトレース ルート用のアプリケーション レベル ゲートウェイ(ALG)を設定できます。これらの ALG は、パケット ゲートウェイ コントローラー プロトコル(PGCP)によって作成されたフローには適用できません。Twice NATは他のALGをサポートしていません。NATは、IPアドレスとTCPまたはUDPヘッダーのみを適用し、ペイロードは適用しません。
Twice 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のIP |
|
– |
OSPF |
|
– |
プロトコル独立マルチキャスト(PIM) |
|
– |
リソース予約プロトコル(RSVP) |
|
– |
TCPの |
|
|
UDP |
|
|
使用可能な数値の完全なリストについては、RFC 1700, Assigned Numbers (for the Internet Protocol Suite)を参照してください。
IP バージョン 6 (IPv6) は、アプリケーション定義のネットワーク プロトコルとしてサポートされていません。
デフォルトでは、Twice NAT 機能は、ICMP エラー メッセージのペイロードに埋め込まれた IP、TCP、および UDP ヘッダーに影響を与える可能性があります。 protocol tcp ステートメントと protocol udp ステートメントを application ステートメントと一緒に 2 回デバイスからも削除されます含めることができます。Twice NAT の設定の詳細については、 Junos Address Aware ネットワークアドレッシングの概要を参照してください。
ICMP コードと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 一致ステートメントと組み合わせて指定し、ポートで使用されているプロトコルを決定します。制約については、 表 1 を参照してください。
数値を指定することも、 表 4 にリストされているテキスト同義語の 1 つを指定することもできます。
ポート名 |
対応するポート番号 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ポリシーの一致基準を定義の詳細については 、ルーティングポリシー、ファイアウォールフィルター、およびトラフィックポリサーユーザーガイドを参照してください。
非アクティブ タイムアウト期間の設定
アプリケーションの非アクティブのタイムアウト期間を指定できます。実行時間内にソフトウェアがアクティビティを検出しなかった場合、タイマーが切れるとフローは無効になります。タイムアウト時間を設定するには、[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データトラフィック)のアイドルタイムアウトを秒単位で指定します。この時間内に IPsec データ トラフィックが ESP セッションで渡されなかった場合、セッションは削除されます。デフォルトは800秒です。
[edit applications application junos-ike] user@host# set child-inactivity-timeout seconds
SIP の設定
Session Initiation Protocol(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]階層レベルで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 System Basics and Services Command Reference」を参照してください。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 メッセージには 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ヘッダーフィールドの情報に基づいてネゴシエートされた動的に割り当てられたポート上のデバイスを介してメディアを許可します。また、このピンホールにより、着信パケットが Contact、Via、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 は 200 OK の送信時間を確保するためにコールの破棄を 5 秒間遅らせます。
Call Re-INVITEメッセージ
再招待メッセージは、新しいメディアセッションをコールに追加し、既存のメディアセッションを削除します。新しいメディア セッションがコールに追加されると、ファイアウォールに新しいピンホールが開き、新しいアドレス バインドが作成されます。このプロセスは、元のコール セットアップと同じです。1 つ以上のメディア セッションがコールから削除されると、ピンホールが閉じられ、BYE メッセージと同様にバインディングが解放されます。
コール セッション タイマー
SIP ALG は、Re-INVITE または UPDATE メッセージが受信されない場合、Session-Expires 値を使用してセッションをタイムアウトします。ALG は、INVITE に対する 200 OK 応答から Session-Expires 値 (存在する場合) を取得し、この値をシグナリング タイムアウトに使用します。セッションがタイムアウトする前にALGが別のINVITEを受信すると、すべてのタイムアウト値がこの新しいINVITEまたはデフォルト値にリセットされ、このプロセスが繰り返されます。
予防措置として、SIP ALG はハード タイムアウト値を使用して、コールが存在できる最大時間を設定します。これにより、次のいずれかのイベントが発生した場合にデバイスが確実に保護されます。
通話中にエンドシステムがクラッシュし、BYEメッセージが受信されない。
悪意のあるユーザーは、SIP ALG を攻撃しようとして BYE を送信することはありません。
SIPプロキシの不備な実装は、Record-Routeの処理に失敗し、BYEメッセージを送信しません。
ネットワーク障害が発生すると、BYE メッセージを受信できません。
通話のキャンセル
どちらの当事者も、CANCEL メッセージを送信することで通話を取り消すことができます。CANCEL メッセージを受信すると、SIP ALG はファイアウォールを介したピンホール (開いている場合) を閉じ、アドレス バインディングを解放します。リソースを解放する前に、ALG は制御チャネルのエージングアウトを約 5 秒間遅らせて、最後の 200 OK が通過する時間を確保します。5 秒のタイムアウトが経過すると、487 応答と 200 以外の応答のどちらが到着したかに関係なく、呼び出しは終了します。
フォーク
フォークにより、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アドレスをローカルアドレスに置き換えます |
|
接触： |
何一つ |
|
Record-Route: |
何一つ |
|
ルート： |
何一つ |
|
アウトバウンド応答 (プライベートからパブリックへ) |
宛先： |
ALGアドレスをローカルアドレスに置き換えます |
差出人： |
何一つ |
|
コールID: |
何一つ |
|
経由： |
何一つ |
|
Request-URI: |
該当なし |
|
接触： |
ローカル アドレスを ALG アドレスに置き換えます |
|
Record-Route: |
ローカル アドレスを ALG アドレスに置き換えます |
|
ルート： |
何一つ |
|
送信要求 (プライベートからパブリックへ) |
宛先： |
何一つ |
差出人： |
ローカル アドレスを ALG アドレスに置き換えます |
|
コールID: |
何一つ |
|
経由： |
ローカル アドレスを ALG アドレスに置き換えます |
|
Request-URI: |
何一つ |
|
接触： |
ローカル アドレスを ALG アドレスに置き換えます |
|
Record-Route: |
ローカル アドレスを ALG アドレスに置き換えます |
|
ルート： |
ALGアドレスをローカルアドレスに置き換えます |
|
アウトバウンド応答 (パブリックからプライベートまで) |
宛先： |
何一つ |
差出人： |
ALGアドレスをローカルアドレスに置き換えます |
|
コール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では、エンドポイントに依存しないマッピング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を設定するには、[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
各フローの 1 行目には、プロトコル(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
各セッションについて:
1行目には、セッションID、サービスセット名、ポリシー名、セッションタイムアウト、論理システム名、状態などのフロー情報が表示されます。
2行目の
Resource informationは、ALG名(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
システムログメッセージの完全なリストについては、 システムログエクスプローラを参照してください。