« 2007年5月 | トップページ | 2007年9月 »

2007年6月の6件の記事

NetScreen-5GT/5XT/5XPの10ユーザーライセンスの動作仕様

NetScreen-5GTなどの5シリーズには10ユーザーライセンスと無制限ライセンス
が存在するが、10ユーザーライセンスの動作仕様について解説する。
尚、10ユーザーライセンス版のNetScreenを購入した場合でも、
無制限ライセンスを後で購入し、そのライセンスキーを投入する事で
無制限ライセンスに変更する事が可能である。

英語表記:
10-user license versions
10 user license versions
The Elite
unlimited user versions

■ VPNトンネル数とユーザ数について
(この内容はScreenOS 5.0,4.0と4.0.0-DIAL2に適用されます。)

全ての NetScreen-5XT/5GT/5XPでは最大10個までのVPN接続数制限があるが、
10ユーザーライセンスのようなユーザ数制限とはお互いに関係無く(非依存)
カウントされます。

■ ユーザ数の数え方(カウント方法)

10ユーザーライセンスの場合、ユーザの単位はtrust zoneに存在する
デバイスのIPアドレスを含むセッションがNetScreeに作成された場合に
そのIPアドレス数(セッション数では無く)でカウントされます。
それらのユーザテーブルは Active User tableで維持管理されます。

■ ユーザ数の数え方の詳細

trust zoneに存在するデバイスのIPアドレスを含むセッションが作成された
際、そのIPアドレスが Active User Tableに追加されます。
これは、セッションの方向性に関わらず、trust zoneから外部へ送信する
トラフィックの送信元IPアドレス、もしくは外部からtrust zoneへ向けて
送信される宛先IPアドレスのIPデバイス数で決定される事を意味します。
逆に言うとtrust zoneのIPアドレスに関するセッションの
IPアドレス数のみカウントされるため外部側デバイスのIPアドレス数は
active user tableには追加されません。
Active user tableに追加されたIPアドレスに関しては、このIPアドレスに
関するセッションが維持されている間中、Active User Tableに残され
このIPアドレスに関するセッションが1つも存在しない状態になった場合に
のみActive User Tableから該当のIPアドレスが削除されます。

10ユーザライセンスのNetScreenは、同時に10人までが
アウトバンドのトラフィックをインターネットに送信できるよう設計
されているため、もし10ユーザーの制限を越えた(Active User tableにて)
場合、11人目のユーザがインターネットへのアクセスを行おうとすると
既に10ユーザーがインターネットとのアクティブなセッションを
持っているとして11人目のユーザのトラフィックはブロックされます。
11人目のユーザは既存の10ユーザのセッションの内、いづれかの
IPアドレスに関する全てのセッションが終了した場合にのみ、
インターネットと通信可能となります。

また、NetScreen上に作成される全てのセッションに関して
trust zoneのIPアドレス数が数えられるため、インターネットへの通信
だけでは無く、VPNトンネルを超える通信やMIP、VIPなどを含めて
IPアドレス数がカウントされます。

無制限ライセンスの場合にはインターネットへ許可されるユーザ数の
チェックは行われません。
(デバイス毎のセッション数の制限は別途存在します。)
NetScreenでは有効なセッションがある限り、全てのユーザが
インターネットと通信でき、何人のユーザ(いくつのIPアドレス)が
ネットワーク(trust zone)に存在するかは全く問題になりません。

■ ユーザ数の数え方の事例

・パターンA
  Trustゾーンから、Untrustゾーンの1つのIPアドレスへの通信
  (Trustゾーン内のクライアントから1つのWebサーバのみへの通信を想定)

  Trustゾーンから同時に10を超えるIPが利用された場合、
  11個目のIPアドレスからのアクセスはブロックされます。

・パターンB
  Untrustゾーンから、Trustゾーン内の1つのIPアドレスへの通信
  (MIP/VIPなどでTrust内のサーバを1台のみ公開している場合を想定)

  TrustゾーンのIPのみカウントするので
  Untrustゾーンの複数のIPアドレスからTrustゾーン内の1つの
  IPアドレスまでのアクセスはUntrustゾーンの端末数に限らず可能。

・パターンC
  Untrustゾーンから、Trustゾーン内の複数のIPアドレスへの通信
  (MIP/VIPなどでTrust内のサーバを福数台公開している場合を想定)

  TrustゾーンのIPのみカウントするので
  UntrustゾーンからTrustゾーン内の10個のIPアドレスまでの
  アクセスは可能だが、Trustゾーン内の11個目のIPアドレス
  に対するアクセスはブロックされます。

■ ScreenOS 2.5以下と2.6以上の仕様の違いについて

ScreenOS 2.5 (NetScreen-5 のみ)以下のバージョンのScreenOSでは
一旦、NS5を通過するユーザのトラフィックが終了した後、
コネクションが終了するまでにに10分間かかります。
例えば、同時に10のコネクションがNS5上で生成され、その後10人目の
ユーザがコネクションを切断した場合、11人目のユーザが外部に
トラフィックを送信できるのはその10分後になります。

この動作仕様はScreenOS 2.6.0以上のScreenOSで変更されており、
ScreenOS 2.6以上では一旦、ユーザがNetScreenを超えるトラフィックを
終了させると、そのセッションは直ぐにクリアされ、そのユーザのIPも
active user tableから除外されます。

■ 10ユーザーライセンスの制限値を超過した場合のログメッセージ
(この内容はScreenOS 4.0以上に適用されます。)

10ユーザーライセンスの10ユーザーの制限値を超過した場合には
以下のログメッセージが記録されます。

   User limit has been exceeded.  User x.x.x.x cannot be added

 ※ここで x.x.x.x には追加できなかったIPアドレスが入ります。

■ 10ユーザーライセンスの制限値を超過した場合のDebugメッセージ
(この内容は少なくともScreenOS 5.0-5.2の5GT及びHSCに適用されます。)

10ユーザーライセンスの10ユーザーの制限値を超過した場合には
デバッグログに以下のメッセージが記録されます。

    packet dropped, nat user limit

■ Active User Table の参照方法
(この内容はScreenOS 4.0以上に適用されます。)

以下のコマンドを入力する事で現在のActive User Tableの中身を
参照する事が可能です。
尚、このコマンドはNetScreen-5XP/5XT/5GTの10ユーザーライセンスでのみ
利用可能でありEliteや無制限ライセンスのバージョンでは利用できません。
※HSCでも利用可能です。HSCは5ユーザの制限があります。

    get active-user

ns5gt-> get active-user
Total 1/10, Free 9:
  192.168.100.1: 1 incoming sessions    0 outgoing sessions

■ 10ユーザーライセンス/無制限ライセンスの判別方法

10ユーザーライセンス/無制限ライセンスを判別するには
以下の方法が利用できる。

WebUI:Configuration > Update > ScreenOS/Keys > License Information
CLI: get license-key

上記いづれかで [Capacity:] の行を参照する

以下、10ユーザーライセンスでのコマンド実行結果である。
Capacityが10 usersとなっているのが判る。

ns5gt-> get license-key
Sessions:           2064 sessions
Capacity:           10 users
           ・
           ・
           ・

■ 参考文献/文書/サイト/URL

How does the 10 user limitation work on the NetScreen-5, 5XP,
and 5XT? (KB ID: KB5566)
http://kb.juniper.net/KB5566

How Does the 10-User Limit Apply to the NetScreen-5XT,
5GT and 5XP? (KB ID: KB4203)
http://kb.juniper.net/KB4203

Why Do I Receive a 'User Limit Has Been Exceeded' Message?
(KB ID: KB6176)
http://kb.juniper.net/KB6176

Only 10 IP Addresses can get out to the Internet
(KB ID: KB5264)
http://kb.juniper.net/KB5264

Why Is the Active Users Report Option Only Available on
Certain Juniper Networks NetScreen Devices? (KB ID: KB6442)
http://kb.juniper.net/KB6442

What Does the Debug Message
"packet dropped, nat user limit" mean? (KB ID: KB7763)
http://kb.juniper.net/KB7763

How Do I Determine Which User License Is Installed on
My Juniper Networks NetScreen-5XP/5XT/5GT? (KB ID: KB6266)
http://kb.juniper.net/KB6266

|

ScreenOSアップデート時の[Shared memory size is too small]のエラー回避方法

WebUIを利用してScreenOSを 5.2.0r3 から 5.3.0系(5.3.0r6)
へアップデートしようとすると以下のようなメッセージを出力し
アップデートが失敗する事があります。

Shared memory size (9988000) is too small for file size (10122557)

この問題はWebUIで5.2.0r3から5.3.0系へアップデートする場合に
発生しますが、TFTPでアップデートする場合には発生しません。

この問題を解決するには、
まず最初に、5.2.0r3 から 5.3.0r1へのアップグレードを実施し、
その後に 5.3.0系 の上位リビジョン(5.3.0r6など)へアップグレード
してください。

■ 参考:

Upgrading from 5.2.0r3 to 5.3.0r6 via WebUI Fails with the error
"Shared memory size is too small" (KB ID: KB9443)
http://kb.juniper.net/KB9443

|

NetScreen/SSG ポリシーベースVPNで生成されるProxy-IDの確認方法

NetScreen/SSGのポリシーベースVPNでVPN接続する際に
Proxy-IDのミスマッチが発生する事がある。
これは、ポリシーにアドレスグループを使用した場合などには
想定したProxy-IDとは異なるProxy-IDが生成される事が
あるからである。

■ ポリシーによって生成されるProxy-IDの確認方法

ポリシーベースVPNの場合に生成されるProxy-IDは
以下のコマンドで確認する事ができる。

    get policy id <number>

上記コマンド投入し、出力された中に
proxy id: の項目があるのでその値を確認する。

■ 参考:

IKE Phase 1 successful, Phase 2 fails due to proxy-id mismatch
(KB ID: KB5049)
http://kb.juniper.net/KB5049

|

NetScreen/SSG Proxy-ID に関するエラーログメッセージ

Event Log Error Message: No Policy Exists for the Proxy ID
Event Log Error Message: because the peer did not send a proxy ID.

NetScreen/SSGでのVPN接続の設定後、ログに
   [ No Policy Exists for the Proxy ID ] や
   [ because the peer did not send a proxy ID. ]
と表示されてVPN接続が確立されない問題について解説する。

■ [ No Policy Exists for the Proxy ID ]エラーログの内容と意味

NetScreenのログに以下のようなメッセージが出力されている場合は、
IKEのPhase2ネゴシエーションの際に、対向のデバイスから送信された
Proxy-IDがローカル側のデバイスのProxy-IDとマッチしていない事を示す。

    No Policy Exists for the proxy id

通常、Proxy-ID( local network, remote network, service port, etc.) は
ローカルとリモートのVPNの両端同士でマッチする必要がある。
(local idとremote idは自デバイスから見て構成するので逆になる)

■ [ because the peer did not send a proxy ID ]エラーログの内容と意味

NetScreenのログに以下のようなメッセージが出力されている場合は、
IKEのPhase2ネゴシエーションの際に、Proxy-IDが対向の
デバイスから送信されていない事を示す。

Rejected an IKE packet on ethernet3 from 1.1.1.1:500 to 2.2.2.2:500
with cookies xxxxxxxxxxxxxxxa and xxxxxxxxxxxxxxb because the peer did
not send a proxy ID.
IKE<1.1.1.1> Phase 2 msg ID <xxxxxxxx>: Negotiations have failed.

例えば、YAMAHAのRTXシリーズなどは、デフォルトでは
Proxy IDを送信しない仕様の為、特に注意が必要である。

YAMAHAでProxy IDを送信するよう設定するには以下コマンドを入力する。
YAMAHAにはProxy IDの Service に該当する設定は無いがNetScreen側の
Proxy IDの Service が 少なくとも ANY の値であれば問題無くマッチする
事が確認できている。

   ipsec ike remote id gateway_id ip_address/mask
   ipsec ike local id gateway_id ip_address/mask

■ 解決方法 (通常の方法)

ローカルとリモートのNetScreen上のProxy-IDの値を合わせる。
すなわち、ポリシーベースVPNではポリシーを適切に設定し、
ルートベースVPNではProxy-IDを手動で適切に設定する。
リモート側にProxy-IDが設定されていない場合には、ローカル側と
合わせるように適切にProxy-IDを構成する。
もしくは、対向のデバイスからProxy-IDの値が送信されていない場合には
Proxy-IDを送信するように設定する。

■ Proxy-IDチェック機能の無効化 (推奨されない)

デフォルトでは、"set ike policy-checking"のコマンドが有効になっており
この場合、Proxy-IDが必ずマッチしている事が必須となる。
但し、この設定は以下のコマンドを実行する事で無効化する事もできる。

   unset ike policy-checking

上記コマンドでProxy-IDのチェックを無効化した場合、Proxy-IDの
チェック無しにPhase2のネゴシエーションが完了しVPN接続が確立する。

しかし、Proxy-IDは別のレベルでのセキュリティを提供しているため
Juniperはこの"policy-checking"を無効にする事を推奨していない。
また、1つの対向IPsecゲートウェイに対し、1つのVPNポリシーが
構成されている場合のみ、ポリシーのチェックを無効化する事ができる。
もし、1つの対向IPsecゲートウェイに対して複数のポリシーが存在する場合
Proxy-IDが無いと複数のIPsecSAを判別する手段が無くなるため
ポリシーチェック機能は無効化すべきでは無い。
さもないと、以下の警告メッセージが出力される。

"If more than one policy is desired per Gateway, policy checking must
first be enabled by executing the "set ike policy checking" command."

メッセージ日本語訳
"もし、1つのゲートウェイに対して2つ以上のポリシーを構成したいので
あれば最初に"set ike policy checking"を実行しポリシーのチェックを
有効化しなければなりません。"

※more than one policy は直訳すると「1つ以上のポリシー」だが
 意訳すると「1つよりも多くのポリシー」と考えるため
 「2つ以上のポリシー」と訳した。

■ 参考:

Event Log Error Message: No Policy Exists for the Proxy ID
(KB ID: KB6744)
http://kb.juniper.net/KB6744

YAMAHA Network Equipment コマンドリファレンス

|

NetScreen/SSG Proxy-IDとは何ですか?

NetScreenやSSGで主にルートベースVPNを構築する際には
Proxy-IDを手動で設定する必要がある。
このProxy-IDとは何のために用いられ、どのように設定すべきかを解説する。

■ Proxy-IDとは

Proxy-IDはIKEによるVPNネゴシエーションのPhase2で利用される。
ルートベースVPNの設定を行う場合にはVPNゲートウェイの両端に
手動で設定する必要があるが、ポリシーベースVPNの設定の場合には
トンネルポリシーの中で使用される 送信元IP、宛先IP、サービス
を利用して自動的に構成される。

IKEのPhase2ネゴシエーションの際、お互いに設定されたProxy-IDを
相手側に送信し合う事でローカル側とリモート側に構成されている
Proxy-IDを検証する。

■ 事例:ポリシーベースVPN構成の場合

Source        Destination      Service   Action
10.1.1.0/24   192.168.1.0/24   ANY       Tunnel (INCOMING)

上記のようなIncomingのトンネルポリシーを作成した場合、
このデバイスは以下のような Proxy-ID をIKEのPhase2で利用する事になる。
(これは自動で生成されるものなので手動で Proxy-IDを設定する必要は無い)

Local Proxy ID  :  10.1.1.0/24
Remote Proxy ID :  192.168.1.0/24
Service         :  Any

対向のNetScreenとIKE/IPsecのネゴシエーションを行ない、
VPN接続を確立するにはこの Proxy-ID と対向デバイスから
受信した Proxy-ID が必ずマッチしなければならず、これは
とても重要な要素である。
例えば、上記のような例の場合にIKEのPhase2が正常に完了するためには
対向のNetScreenデバイスでOutgoingのトンネルポリシーは以下のように
構成されなければならない。
そうでないとVPN接続が確立しないはずである。

Source          Destination   Service   Action
192.168.1.0/24  10.1.1.0/24   ANY       Tunnel (OUTGOING)

■ ポリシーベースVPNにアドレスグループを利用した場合の注意事項

ポリシーベースVPNのためのポリシーにアドレスグループや
サービスグループを利用した場合には Proxy-IDは
0.0.0.0/0 や 0.0.0.0/32 になるので注意が必要である。

特にルートベースVPNのNetScreenとポリシーベースVPNのNetScreenを
VPN接続するにはポリシーベースVPNで構成されたNetScreen側が
送信する Proxy-ID の値を明確に確認する事が重要となり、
ルートベースVPN側のNetScreenではその値に合わせて
Proxy-ID の設定をすれば良い。

■ 事例:ルートベースVPN構成の場合

ルートベースVPNで構成する場合のProxy-IDの設定は単純である。
ルートベースVPNの場合にはNetScreenが対向デバイスにVPNトンネルを
介してパケットを送出するには「ルーティング」が利用されるため
もはや作成したポリシーとProxy-IDには関係が無い。
例え、VPN接続拠点とのポリシーを記述したとしてもProxy-IDは
自動で生成されなくなっている。
そのためルートベースVPNの場合 Proxy-ID を手動で設定する必要がある。

では、どのような Proxy-ID を設定すべきだろうか?

答えは、
   極論で言えばマッチすれば何でも(任意の値)良い。
   マッチさえすればVPN接続は確立するのである。

例えば、一方のNetScreenが以下のような設定であるならば

Local Proxy ID  :  1.1.1.1/32
Remote Proxy ID :  1.1.1.1/32
Service         :  Any

他方のNetScreenも以下のようなProxy-IDを設定すれば
VPN接続は確立できる。

Local Proxy ID  :  1.1.1.1/32
Remote Proxy ID :  1.1.1.1/32
Service         :  Any

ここで、1.1.1.1は対向のNetScreenデバイスにとって
何の関係も無い(該当IPを持っている必要は何ら無い)
IPアドレスであってもマッチさえすれば問題は無い。
但し、Proxy-IDは対向との設定がマッチする事を
確認する一種の認証機能でもあるため実際には
NetScreenが隣接するネットワークを設定した方が
(より実情に近い値を設定した方が)良いだろう。

例えば、一方のNetScreenが以下のような設定であるならば

Local Proxy ID  :  192.168.100.0/24
Remote Proxy ID :  172.16.200.0/24
Service         :  Any

他方のNetScreenは以下のようなProxy-IDの設定

Local Proxy ID  :  172.16.200.0/24
Remote Proxy ID :  192.168.100.0/24
Service         :  Any

■ 参考:

What is a Proxy-ID? (KB ID: KB5565)
http://kb.juniper.net/KB5565

Cannot communicate between policy-based VPN and route-based VPN
(KB ID: KB7163)
http://kb.juniper.net/KB7163

|

NetScreen/SSGでVPN(IPSec SA)の状態を確認する方法

NetScreen/SSGでVPN接続(IPSec SA)の状態確認をするには
以下の方法が利用できる。

■WebUI
        VPNs > Monitor Status

■CLI(telnet,ssh,consoleから)
        get sa
          [
          id id_num |
          active | inactive
          [ stat ] |
          stat
          ]

■CLI例
        get sa            全ての SA を表示
        get sa active     アクティブな SA のみ表示
        get sa inactive   アクティブでない SA のみ表示
        get sa stat       SAの状態(送受信バイト数など)を表示
        get sa id id_num  SAのIDを指定してSAの詳細を表示
                          [id_num] には SA のIDを入力する
                      例えば get sa id 0x1など
                          (最近のOSではget sa id 1などでもO.K)

では、get saで出力されたフィールドの状態を見て
SAがアクティブなのかそうでないのかや、VPN Monitor機能でトンネルの状態が
アップ/ダウンしているかなどをどのように見れば良いのかを解説する。
ここではCLIでの出力を解説するがWebUIのMonitor Statusで確認できる情報も
同様の考え方で理解する事ができるはずである。

■get sa コマンドの2通りの出力例
  ※SPIの値はxで隠してあるが実際には8桁の16進数で表示される

ns-> get sa
total configured sa: 1
HEX ID    Gateway Port Algorithm     SPI      Life:sec kb    Sta PID vsys
00000001< 1.1.1.1 500  esp:3des/sha1 xxxxxxxx expir    unlim I/I 2 0
00000001> 1.1.1.1 500  esp:3des/sha1 xxxxxxxx expir    unlim I/I 1 0

ns-> get sa
total configured sa: 1
HEX ID    Gateway Port Algorithm     SPI      Life:sec kb    Sta PID vsys
00000001< 2.2.2.2 500  esp:3des/sha1 xxxxxxxx 3596     unlim A/- 2 0
00000001> 2.2.2.2 500  esp:3des/sha1 xxxxxxxx 3596     unlim A/- 1 0

ns-> get sa
total configured sa: 3
HEX ID    Gateway  Port Algorithm     SPI      Life:sec kb    Sta   PID vsys
00000006< 3.3.3.3  500  esp:3des/sha1 xxxxxxxx   881    unlim A/U   -1 0
00000006> 3.3.3.3  500  esp:3des/sha1 xxxxxxxx   881    unlim A/U   -1 0
00000002< 4.4.4.4  500  esp:3des/sha1 xxxxxxxx  1399    unlim A/U   -1 0
00000002> 4.4.4.4  500  esp:3des/sha1 xxxxxxxx  1399    unlim A/U   -1 0
00000007< 0.0.0.0  500  esp:3des/sha1 xxxxxxxx expir    unlim I/I   -1 0
00000007> 0.0.0.0  500  esp:3des/sha1 xxxxxxxx expir    unlim I/I   -1 0

複数のVPNトンネルが構成されている場合にはリモートゲートウェイのIPアドレスの列を
確認する事でどのゲートウェイとのトンネル状態かを示すSAかを確認できる。

■Sta のフィールドは2つの事柄を表現している

   1. 最初の文字列はVPNトンネルがActiveもしくはInactiveを表示
      (A=Active I=Inactive)

   2. 2つめの文字列は(/の後ろ側)はVPN Monitor機能のリンク状態を表示
      (U=Up D=Down -=VPN Monitor is not configured)

■staフィールドに表示される値

I/I: VPN tunnel は Inactive状態 (activeではない)
A/-: VPN tunnel は Active状態  但し、VPN Monitorは構成(設定)されていない
A/U: VPN tunnel は Active状態  であり、VPN MonitorでUpを検出している状態
A/D: VPN tunnel は Active状態  但し、VPN MonitorはDownを検出している状態
        VPN Monitorが送信した ping のレスポンスを受信していない状態。
        これは、対向のNetScreen/SSGが ping にレスポンスを返さない設定に
        なっている可能性がある。または、対向のデバイスがNetScreen/SSGでは
        無く異なるベンダ製の機器である可能性もある。

・A/- か A/U であればVPNトンネルは正常にアップしている状態と考えられる。
・I/I であればVPNトンネルは正常にアップしておらずトンネルを越えて
  データの送受信ができない。
・A/D であればSA自体は正常にアップしているがVPN Monitorがダウンしていれば
  tunnelインターフェースがDownするのでデータの送受信はできないかもしれない

もし、以下のようにフィールドのヘッダー行しか出力されない場合には
SA自体が生成されておらずアクティブなVPNは存在しない。
これは、VPN接続の設定構成自体が完了していない事を示す。

Paris-> get sa
total configured sa: 0
HEX ID    Gateway Port Algorithm     SPI      Life:sec kb    Sta PID vsys

■get saコマンド出力の全てのフィールドについての解説

HEX ID     --16進数で表現されたSAのID番号
              "<" や ">"はSAの方向を示す
Gateway    --対向ゲートウェイのIPアドレス
Port       --ポート番号
Algorithm  --Phase2で使用されている暗号化アルゴリズム
SPI        --SPI値 (SAの識別子)
Life:sec kb -SAの残り寿命を示す expirは寿命が尽きている事を示す
              secには残り秒数、kbには残りのキロバイト数が表示される
              (NetScreenのデフォルトのPhase2パラメータでは秒数で
               SAの寿命を構成するようになっている)
Sta        --VPNトンネル(SA)の状態を示す
PID        --ポリシーベースVPNで構成された場合は該当する
              Policy IDを示す
              ルートベースVPNで構成された場合は[-1]と表示される
vsys       --該当SAが稼動しているvsysを示す

参考:

How do I tell if a VPN Tunnel SA (Security Association) is active?
(KB ID: KB6134)

http://kb.juniper.net/KB6134

|

« 2007年5月 | トップページ | 2007年9月 »