最近、JNCIA-FWVの資格を取得しました。
現行のJNCIA-FWVはScreenOS5.4に準拠した
試験コード：JN0-521になっていたが正答率88%で合格！！
初めて英語の試験を受けたのですが、なんとなくわかるもんですね。
英語の試験という条件の中で88%の正答率なのでまぁまぁ納得しています。
次はJNCIS-FWVを受験したいのですが、NSRPなどが試験範囲となるので
実務でNSRPを経験していないと難しいのかぁ？
会社や自宅にSSG140以上の機種が2台以上ある環境であれば
色々実験できるのになぁ・・・。SSG140かSSG300が2台ある環境が欲しい。
| 固定リンク | コメント (0) | トラックバック (0)
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)に存在するかは全く問題になりません。
■ ユーザ数の数え方の事例
・パターンＡ
Trustゾーンから、Untrustゾーンの1つのIPアドレスへの通信
(Trustゾーン内のクライアントから1つのWebサーバのみへの通信を想定)
Trustゾーンから同時に10を超えるIPが利用された場合、
11個目のIPアドレスからのアクセスはブロックされます。
・パターンＢ
Untrustゾーンから、Trustゾーン内の1つのIPアドレスへの通信
(MIP/VIPなどでTrust内のサーバを1台のみ公開している場合を想定)
TrustゾーンのIPのみカウントするので
Untrustゾーンの複数のIPアドレスからTrustゾーン内の1つの
IPアドレスまでのアクセスはUntrustゾーンの端末数に限らず可能。
・パターンＣ
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
| 固定リンク
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で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
| 固定リンク
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で主にルートベース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)の状態確認をするには
以下の方法が利用できる。
■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)
| 固定リンク
NetScreenではNATの機能がいくつかあるが、そのうち
インターフェースベースのNATモードとポリシーベースのNATモードが
存在する。(これ以外にもMIP、VIPなどもあるが)
ここではインターフェースベースのNATを有効にした場合の動作について
説明する。
英語表記 interface-based NAT , Policy-based NAT
■ NATモードの制限事項
NetScreen-25, NetScreen-50, NetScreen-204, NetScreen-208では
以下のようなインターフェース割り当ての場合にNATモードを利用できる。
Ethernet1 ---> Trust
Ethernet2 ---> DMZ (もしくはCustomゾーン)
Ethernet3 ---> Untrust
■ Untrustインターフェースをnatモードにしても意味は無い
Untrustゾーンに所属するインターフェースはnatモードにしても
設定上可能なだけであり何ら意味は無いそうである。
■ 推奨のNAT構成
JuniperではインターフェースベースのNATに代わり
ポリシーベースのNATを利用する事を強く推奨している。
(routeモードを使いNATは別途ポリシーレベルで管理する方法)
しかし、ポリシーベースのNATはコンフィグレーションに非常に時間がかかる。
コンフィグレーションの時間削減や設定の単純化のためには
インターフェースベースのNATは非常に便利であるため、
これをうまく利用する事がNetScreenを使いこなす上で非常に重要であると
筆者は考えている。
◆ 構成シナリオ１
NS50などのデフォルトの状態
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(nat) DMZ (Trust-VR)
Ethernet3(route) Untrust (Trust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust route
・DMZ --> Untrust route
・Untrust --> Trust route
・Untrust --> DMZ route
◆ 構成シナリオ２
NS50などのデフォルトの状態からUntrustゾーンを
Untrust-VRに所属させた状態。
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(nat) DMZ (Trust-VR)
Ethernet3(route) Untrust (Untrust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust route
・DMZ --> Untrust NAT
・Untrust --> Trust route
・Untrust --> DMZ route
◆ 構成シナリオ３
NS50などのデフォルトの状態からUntrustゾーンを
Untrust-VRに所属させ、Ethernet2をrouteモードに
した場合。
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(route) DMZ (Trust-VR)
Ethernet3(route) Untrust (Untrust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust route
・DMZ --> Untrust route
・Untrust --> Trust route
・Untrust --> DMZ route
◆ 構成シナリオ４
NS50などのデフォルトの状態からethernet2を
DMZでは無くCustomZoneに所属させた状態。
VRは全て同じTrust-VR
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(nat) CustomZone (Trust-VR)
Ethernet3(route) Untrust (Trust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> CustomZone route
・Trust --> Untrust NAT
・CustomZone --> Trust route
・CustomZone --> Untrust route
・Untrust --> Trust route
・Untrust --> CustomZone route
◆ 構成シナリオ５
NS50などのデフォルトの状態からethernet2を
DMZでは無くCustomZoneに所属させ、尚且つ
UntrustゾーンをUntrust-VRに所属させた状態
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(nat) CustomZone (Trust-VR)
Ethernet3(route) Untrust (Unrust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> CustomZone route
・Trust --> Untrust NAT
・CustomZone --> Trust route
・CustomZone --> Untrust NAT
・Untrust --> Trust route
・Untrust --> CustomZone route
◆ 構成シナリオ６
ethernet2をCustomZone1ゾーンへ変更
ethernet4をCustomZone2ゾーンへ変更し
UntrustゾーンをUntrust-VRに所属させた状態
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(nat) CustomZone1 (Trust-VR)
Ethernet3(route) Untrust (Unrust-VR)
Ethernet4(nat) CustomZone2 (Trust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> CustomZone1 route
・Trust --> CustomZone2 route
・Trust --> Untrust NAT
・CustomZone1 --> Trust route
・CustomZone1 --> CustomZone2 route
・CustomZone1 --> Untrust NAT
・CustomZone2 --> Trust route
・CustomZone2 --> CustomZone1 route
・CustomZone2 --> Untrust NAT
・Untrust --> Trust route
・Untrust --> CustomZone1 route
・Untrust --> CustomZone2 route
◆ 構成シナリオ７
Juniper KBに記載されているシナリオ
TrustゾーンはTrust-VRに所属しているが
DMZゾーンはUntrust-VRに所属させTrust、DMZ、Untrustを利用している場合
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust NAT
・Untrust --> Trust route
■ NetScreen-5GT Extendedの場合
NetScreen-5GT ExtendedではCustomゾーンは作成できるが
ethernet2のDMZゾーンのバインドをCustomゾーンへ割当てる事はできない。
◆ NetScreen-5GT Extended 構成シナリオ１
NS5GT Extendedのデフォルトの状態
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(nat) DMZ (Trust-VR)
Ethernet3(route) Untrust (Trust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust route
・DMZ --> Untrust route
・Untrust --> Trust route
・Untrust --> DMZ route
◆ NetScreen-5GT Extended 構成シナリオ２
NS5GT Extendedのデフォルトの状態から
ethernet2のみrouteモードにした場合。
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(route) DMZ (Trust-VR)
Ethernet3(route) Untrust (Trust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust route
・DMZ --> Untrust route
・Untrust --> Trust route
・Untrust --> DMZ route
◆ NetScreen-5GT Extended 構成シナリオ３
NS5GT Extendedのデフォルトの状態から
UntrustゾーンをUntrust-VRに所属させた場合
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(nat) DMZ (Trust-VR)
Ethernet3(route) Untrust (Untrust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust route
・DMZ --> Untrust NAT
・Untrust --> Trust route
・Untrust --> DMZ route
◆ NetScreen-5GT Extended 構成シナリオ４
NS5GT Extendedのデフォルトの状態から
ethernet2のみrouteモードにし
UntrustゾーンをUntrust-VRに所属させた場合
・インターフェースの構成
Interface(mode) Zone Virttual Router
Ethernet1(nat) Trust (Trust-VR)
Ethernet2(route) DMZ (Trust-VR)
Ethernet3(route) Untrust (Untrust-VR)
・トラフィックフローとNATの有無
※NATはNAT有、routeはNAT無
・Trust --> DMZ NAT
・Trust --> Untrust NAT
・DMZ --> Trust route
・DMZ --> Untrust route
・Untrust --> Trust route
・Untrust --> DMZ route
適用ScreenOS：
ScreenOS4.0.0以上
適用機種：
NetScreen-5
NetScreen-5XP
NetScreen-5XT
NetScreen-10
NetScreen-25
NetScreen-50
NetScreen-100
NetScreen-204
NetScreen-208
NetScreen-5200
NetScreen-5400
参考：
How Does the NetScreen NAT When Interface-Based NAT is Enabled? (KB ID: KB6725)
http://kb.juniper.net/KB6725
| 固定リンク
SSG5はバックパネルにUSBポートがあり、そこにUSBメモリーやUSBアダプターを
搭載したコンパクトフラッシュ(Compact Flash)を差し込む事によって
コンフィグやScreenOSの保存媒体として利用できる。
（USBメモリ上に保存されたファイル利用してScreenOSのアップグレードや
証明書ファイルの交換が可能。）
他に、以下の機能もあるようだ。
・ログストレージの容量拡張に利用
・ブート時にプライマリのデバイスが障害を起こしている場合、
セカンダリのブートデバイスとして自動的に認識される
尚、サポートされている規格はUSB1.1のみ。2.0はサポートされていない。
よって、最大12M、最小1.5Mのデバイス速度。
利用するにはUSBメモリーを差し込む(起動前でも起動中でも)だけで
自動認識する。
(利用可能なデバイスには制限や推奨品があるかもしれないが・・・。)
■ USBメモリーをSSG5に挿入する (例ではI-Oデータ製256MBのUSBメモリ)
・挿入するとコンソールに以下のメッセージが出力される。
------------------------------------------------------------------
I-O DATA USB Flash Disk, rev 2.00/2.00, addr 2, SCSI over Bulk-Only
Mount usb device. Please wait...
usb device ready.
------------------------------------------------------------------
・挿入するとログには以下のメッセージが出力される。
YYYY-MM-DD HH:MM:SS notif I-O DATA USB Flash Disk, rev 2.00/2.00,
addr 2 attach success
・挿入するとWebUIには以下のようにデバイス容量が出力される。
Reports > Chassis
Chassis Status:
USB: Inserted; Total Size: 25,298,944 bytes; Free Size: 11,396,608 bytes
・USBメモリが挿入されていない場合のWebUI出力
Reports > Chassis
Chassis Status:
USB: Not Inserted
■ USBメモリー内のファイルを確認する方法
・get file info
上記コマンドでflashメモリとUSBメモリそれぞれのトータル容量と
空き容量を確認できる。
ssg5-isdn-> get file info
There are 51079168 bytes free (62623744 total) on disk "flash:"
There are 11396096 bytes free (25298944 total) on disk "usb:"
・get file
上記コマンドでflashメモリとUSBメモリに保存されているファイルと
その容量が確認できる。
ssg5-isdn-> get file
flash:/crashdump.dmp 16384
flash:/burnin_log3 20480
flash:/burnin_log2 20480
flash:/burnin_log1 20480
flash:/burnin_log0 20480
flash:/envar.rec 79
flash:/ns_sys_config 1031
USB flash device :
usb:/ssg5.cfg 3004
usb:/ssg5-isdn_log.txt 347
■ USBメモリーの利用方法
USBメモリを挿入すると「usb」のデバイス名が利用できる。
USBへのコンフィグバックアップ、USBからのコンフィグリストアなど
様々な利用方法が可能である。
例0：ubs上のファイルからflashへファイルを保存
save {software | config | image-key} from usb filename to flash
例1：flash上のコンフィグをUSBメモリーに保存
ssg5-isdn-> save config from flash to usb <filename>
例2：flash上のScreenOSをUSBメモリーに保存
ssg5-isdn-> save software from flash to usb <filename>
例3：USBメモリー内のファイルを削除
ssg5-isdn-> delete file usb:/filename
■ USBメモリーをSSGから安全に取り外すには
USBメモリーはWindowsと同様にいきなり取り外すと以下のような警告が出る。
usb device is removed illegally!
きちんと取り外すには「exec usb-device stop」コマンドを実行した後に
取り外さないといけない。
ssg5-isdn-> exec usb-device stop
The "USB Mass Storage Device"can now be safely removed from system
この後、取り外すと以下メッセージがコンソール出力され安全に
取り外す事が可能である。
usb device is removed normally!
■ USBメモリーをログ容量拡張のために利用するには
USBメモリーを挿入すると自動的にログファイルがUSBメモリーに
ログファイルが作成され保存され始める。
ファイル名は以下の通りで、ホスト名を変更しても変化は無い。
(get fileで参照)
usb:/ssg5-isdn_log.txt
■ 今後調査が必要な項目
セカンダリーブートデバイスとしての利用方法
log moduleの宛先設定にusbが指定できるがコンフィグに
保存されないため現状では用途不明。今後実験予定
-> set log module name_str level string destination string
-> unset log module name_str level string destination string
以下コマンドはUSBメモリー上のログファイルサイズを制限するための
ものと思われるが詳細は不明。今後実験予定。
-> set log usb filesize <number(unit Mega)>
| 固定リンク | トラックバック (0)
■ NetScreen-25/50/200/500
SSG 5/SSG 20/SSG 140/SSG500 用コンソールDB9ケーブル
NetScreen本体：RJ-45
専用ケーブル：カテゴリー5UTP（ストレートケーブル）/オス・オス
+ DB9アダプター(メス)
■ NetScreen-5GT/5XT用コンソールDB9ケーブル
NS-5GT本体：メス
専用ケーブル：シリアル（ストレートケーブル）/オス・メス
Baud rate: 9600
Parity: None
Data bits: 8
Stop bit: 1
Flow Control: None
デフォルトでは、コンソールタイムアウトが自動的に10分で
タイムアウトする設定になっている。
この設定を削除したり変更するにはset console timeoutコマンドを利用する
0に設定するとコンソールタイムアウト設定が削除される
set console timeout 0
SSG 5のコンソールポートで実験したがCiscoのきし麺ケーブル
(ロールオーバーケーブル＋DB9アダプター)でも接続可能だった。
LANケーブルはSSG純正がストレートに対してCiscoはロールオーバーケーブル
でピン配列が異なるはずだが恐らく、DB9アダプターの変換によって結果的に
同じ接続方式となると考えられる。
■ NetScreen-SecureAccess用コンソールDB9ケーブル
NS-SA本体：オス
専用ケーブル：シリアル（クロスケーブル）/メス・メス
| 固定リンク | トラックバック (0)
NetScreenではICMPリダイレクトはサポートされていない。
通常のルータがICMPリダイレクトを行うような環境でも
NetScreenからはICMP RedirectのICMPトラフィックは送信されない。
NetScreenがICMPリダイレクトを行う事を期待してネットワークを
設計すると、行きのパケットのみNetScreenを通過し戻りのパケットが
NetScreenを通過しない現象が発生する可能性がある。
その場合、NetScreenが許容するセッション数を圧迫する可能性が
あるので要注意。
(行きのパケットをNetScreenが受け取るとNetScreenはセッションを作成
するが、戻りのパケットが戻ってこないとそのセッションを終了できず
デフォルトのセッション保持期限までそのセッションを保持するため)
適用機種：
NetScreen-5
NetScreen-5XP
NetScreen-5XT
NetScreen-10
NetScreen-25
NetScreen-50
NetScreen-100
NetScreen-204
NetScreen-208
NetScreen-500
NetScreen-1000
NetScreen-5200
NetScreen-5400
参考：
Is Icmp Redirect supported on Netscreen Firewall?
http://kb.juniper.net/KB6416
Ciscoテクニカルノーツ：ICMP リダイレクトはいつ送信されるか
http://www.cisco.com/japanese/warp/public/3/jp/service/tac/105/43-j.shtml
| 固定リンク | トラックバック (0)
NetScreenでは
VPNトラフィックが無い場合でもトンネルを維持するための機能として
IKE heartbeatとVPN Monitorの機能が利用できる。
しかし、似通った動作・用途のため利用するケースを混同、困惑しやすい
IKE heartbeatとVPN Monitorについて解説する。
----------------------------------------------------------------------
IKE heartbeatは一般的にポリシーベースVPNのトンネル接続検知と
フェイルオーバーに利用し、 VPN monitorは一般的にルートベースVPNで
VPNのダウンを検知/報告しVPNを再接続するために利用する。
IKE heartbeatはVPNトンネルの可用性を検出するためにLucentが定義した
IKE拡張仕様であり、VPN monitorにはICMPのエコー/レスポンスが用いられる。
このつの手法はいずれもトンネルの障害を検知するという同じ目的を持った
機能でありトラフィックがない場合でもトンネルを自動的に接続し続けようと
する。
IKE heartbeatは最初に実装され、主にポリシーベースVPNでトンネルの
フェイルオーバーを行うためのVPNグループで用いられる。
尚、IKE heartbeatの機能を利用するにはトンネルの両端のデバイス同士が
必ずIKE heartbeatをサポートしなければならない。
VPN Monitorは当初、VPNトンネルの障害をSNMPで報告し、ログイベントに
記録するために開発されたが、その後拡張されIKE heartbeatが持っていた
トンネル再接続の機能も提供できるようになった。
しかし、VPN MonitorはルートベースVPNを利用する際には更に機能的である。
VPN Monitorがトンネルのダウンを検知すれば、仮想のトンネルインターフェ
ースをダウンとする事ができ、それによって、そのインターフェースに関連
している全ての経路情報（ルーティング）もダウンさせることができる。
(あるいは、ダイナミックルーティングプロトコルにそのルートの削除を
知らせる。これは、物理インターフェースのケーブルを引き抜き、、
レイヤ2のリンク状態をダウンさせる事と等しい。）
VPN Monitorは他のベンダーとの相互運用性を高めるためにICMPが
モニタリング用のプローブとして用いられる。
----------------------------------------------------------------------
まとめ
■ IKE heartbeat
・一般的にポリシーベースVPNのトンネル接続検知とVPNグループ利用時の
フェイルオーバーに利用
・VPNトンネルの可用性を検出するためにLucentが定義したIKE拡張仕様
・IKE heartbeatは対向の両方のデバイスでサポート(設定)されないと
利用できない(MUST)
■ VPN Monitor
・一般的にルートベースVPNでVPNのダウンを検知/報告しVPNを再接続
するために利用
・他ベンダの相互運用性のために、ICMPエコー/レスポンスを用いる。
・VPN Monitorは対向デバイスでサポートされていなくても利用できる。
・VPN Monitorがトンネルのダウンを検知し、トンネルインターフェースの
ステータスを変化させる事によって、関連するルーティングも動的に
変化させる事ができる。(Static、Dynamicのルーティング)
参考：
When should I use IKE Heartbeat and when should I use VPN Monitor
http://kb.juniper.net/KB6786
| 固定リンク | トラックバック (0)
NetScreenでのMSS調整方法について記載する
■ "set flow tcp-mss" と "set flow all-tcp-mss"
どちらもNetScreenを通過するトラフィックのMSS値を
変更・修正するために使用される。
また、all-tcp-mssのコマンドはtcp-mssのコマンドを上書きしない。
tcp-mssコマンドはVPNトラフィック
all-tcp-mssは平文の通過トラフィックのみに適用される。
■ set flow all-tcp-mss
NetScreen自身のTCP/IPスタックに適用されNetScreenへの通信と
NetScreenからの通信に使用される。
NetScreenを通過する平文(clear-text)のTCPトラフィックに適用される
(this command is for Clear TCP Traffic)
透過モード(トランスペアレントモード)ではサポートされず
ルートモードのみでサポートされる。
■ set flow tcp-mss
NetScreenを通過するVPNトラフィック(TCP)のみに適用される
(this command is for VPN TCP traffic)
■ set flow all-tcp-mssについて
set flow all-tcp-mssのコマンドは
パケットのフラグメント化が原因でパフォーマンスに影響を及ぼすような
ケースで利用される。このコマンドによりパケットのフラグメント化が
発生しないよう、最大伝送単位(MTU)以下に最大のセグメント・サイズ(MSS)
を十分に低く修正する事ができる。
全てのオーバーヘッドを足したパケットのペイロードサイズはMTUを超過してはいけな い。そうでなければフラグメントが発生するだろう。
オーバーヘッドはmacヘッダー、ethernetヘッダー、CRC、暗号化およびPPPoEを含む。
尚、set flow all-tcp-mssは平文(clear-text)のトラフィックに適用され、
set flow tcp-mssはVPNトラフィックのみに適用される。
PPPoEは大量のオーバーヘッドを追加し、set flow all-tcp-mssが有効になっていない
場合にはフラグメントが発生するため、set flow all-tcp-mssはPPPoE接続環境で
必要になる。
又、経路上のルーターがフラグメントパケットを適切に扱っていないようないくつかの
実例もある。これらの例では、set flow all-tcp-mssは問題解決の助けになるかもしれ ない。例えば、あるウェブサイトへアクセスするが全ての画像イメージが表示されない
ような場合、これはフラグメントの問題が発生している可能性がある。
set flow all-tcp-mssの適用はこの問題を解決するために利用できる。
■ TCP-MSSのデフォルト設定
ScreenOS ≫ 5.1.x ≫ 5.1.0
ScreenOS ≫ 5.0.x ≫ 5.0.0
・全てのNetScreen-5XP, NetScreen-5XT, NetScreen-5GT
tcp-mss 1400がデフォルトで設定されている
・それ以外の全てのNetScreenでは
tcp-mssはデフォルトで設定されていない
・PPPoEの設定を行った場合
set flow tcp-mss 1392
set flow all-tcp-mss 1304
PPPoEインスタンスをインターフェースにバインドした場合、
事前にset flow all-tcp-mssコマンドが設定されていなければ自動的に
set flow all-tcp-mss 1304の設定が追加される。
また、少なくともNetScreen-5GTでPPPoEを有効にした場合
set flow tcp-mss 1392の設定がコンフィグに現れる事を確認している。
これはデフォルトのtcp-mss 1400からPPPoEオーバーヘッドの
8バイトを差し引いた値と考えられる。
■ set flow all-tcp-mssは透過モードでもサポートされますか？
ScreenOS ≫ 4.0.x ≫ 4.0.0
ScreenOS ≫ 5.0.x ≫ 5.0.0
ScreenOS ≫ 4.0.x ≫ 4.0.3
ScreenOS ≫ 4.0.x ≫ 4.0.2
set flow all-tcp-mssのコマンドはトランスペアレント(透過)モードでは
サポートされません。このコマンドはルートモードでのみ適用されます。
■ NetScreenは設定されたMMS値より小さいMSSが定義された
パケットのMSS値を書き換えますか？(LAN間VPN)
ScreenOS ≫ 3.0.x
ScreenOS ≫ 3.1.x
ScreenOS ≫ 4.0.x
ScreenOS ≫ 5.0.x
ScreenOS ≫ 5.1.x
環境：
LAN間VPN
ローカル側のMTUより遠隔地側のほうが小さなMTUを持っている場合
いいえ。設定された値より提案されたサイズが大きい場合のみ、NetScreenは
MSSを修正します。MSSが設定された値より小さい場合、MSSの修正はされません。
参考：
What does set flow all-tcp-mss do?
http://kb.juniper.net/KB6346
Does set flow all-tcp-mss override set flow tcp-mss ?
http://kb.juniper.net/KB7952
Default Settings for TCP-MSS
http://kb.juniper.net/KB7361
TCP-MSS Default Settings
http://kb.juniper.net/KB4586
Is "set flow all-tcp-mss" supported in Transparent Mode?
http://kb.juniper.net/KB6961
Does NetScreen re-write the Maximum Segment Size (MSS)?
http://kb.juniper.net/KB3910
| 固定リンク | トラックバック (0)
NetScreen-SecureAccess(IVE)の設定をバックアップするには
system configuration (system.cfg) のエクスポートだけでは
完全なバックアップにはならない。
IVEの完全なバックアップを取得するには
Configuration (system.cfg) と User Accounts (user.cfg)を
両方ともエクスポートして保存しておき、リストア(復元)をする際には
両方のコンフィグファイルをインポートする必要がある。
尚、バイナリのバックアップファイル(system.cfg user.cfg)には
ログは当然含まれないので注意する事。
■システム設定ファイルのエクスポート
以下の項目をエクスポートしたい場合は、システム設定ファイルを
エクスポートします。
・ネットワーク設定
・クラスタ設定
・ライセンス
・SNMP 設定
システム設定ファイルをエクスポートするには、次の操作を行います。
1. Web コンソールで、Maintenance > Import/Export > Configuration
を選択します。
2. 設定ファイルをパスワードで保護する場合は、Export でパスワードを
入力します。
3. Save Config As をクリックしてファイルを保存します。
■ローカル ユーザー アカウントまたはリソース ポリシーのエクスポート
以下の項目をエクスポートしたい場合は、ユーザー アカウントを
エクスポートします。
・サインイン設定（サインイン ポリシー、サイン インページ、すべての
認証サーバーを含む）
・認証領域
・ロール
・リソース プロファイル/ リソース ポリシー
・ユーザー アカウント
・ミーティング設定
ローカル ユーザー アカウントまたはリソース ポリシーをエクスポート
するには、次の操作を行います。
1. Webコンソールで、Maintenance > Import/Export > User Accountsを選択
2. 設定ファイルをパスワードで保護する場合は、Exportでパスワードを入力
3. Save Config As をクリックしてファイルを保存
参考：
Juniper Article ID: KB7736
http://kb.juniper.net/KB7736
| 固定リンク | トラックバック (0)
インターフェースのSpeed、Duplex設定を行うには
CLIで以下のコマンドを利用します。
(WebUIからは設定不可能です）
-> set interface <interface> phy <duplex> <speed>
NetScreen-5GTのtrustポートは以下コマンドで各ポート単位で設定可能
-> set int trust port <port id> phy<duplex> <speed>
※duplex = half or full or auto
※speed = 10mb or 100mb
インターフェースの設定を確認するには以下のコマンドを利用します。
-> get interface <interface>
NetScreen-5GTのTrustポートを確認する場合
-> get interface trust port <port id 0-4> phy
関連するバグ：
NetScreen-5GTのScreenOS5.0.0ではインターフェースに関するバグがあり
10MBps full duplexの設定をしても10MBps half duplexとなる場合がある。
解決方法は5.0.0r10以上のバージョンにアップグレードする事。
in coll err collisions on line From 5.0.0r10 release notes (actually fixed in r9):
03269 - The Juniper NetScreen-5GT incorrectly auto negotiated to
10MBps half duplex after it had initially set itself to
10MBps full duplex.
その他、
NetScreen-5GTとCatalyst3550との接続時にインターフェース設定の
ミスマッチがある場合リンクが確立しないバグがあった模様
検索キーワード:
インターフェース インタフェース interface 10M/FULL 100M/FULL,
auto-negotiate auto-negotiation auto-nego オートネゴシエーション
半2重 全2重 自動設定 CLI コマンド 設定 インターフェースの設定
参考：
Juniper Article ID: KB5453
http://kb.juniper.net/KB5453
Juniper Article ID: KB6454
http://kb.juniper.net/KB6454
Juniper Article ID: KB5102
http://kb.juniper.net/KB5102
Juniper Article ID: KB4634
http://kb.juniper.net/KB4634
Juniper Article ID: KB4470
http://kb.juniper.net/KB4470
Juniper Article ID: KB7295
http://kb.juniper.net/KB7295
| 固定リンク | トラックバック (0)
Windows 95, Windows 98, と Windows MEは
NetScreen-Remote 8.5までのバージョンでのみサポートされます。
これらのOSはNetScreen-Remote 8.6以降のバージョンではサポートされません。
NetScreen-Remote 8.6以降のバージョンを使うには
以下のオペレーティングシステムのいづれかにアップグレードしてください。
Windows NT
Windows 2000 Professional
Windows XP Professional
検索用キーワード：
NetScreen-Remote VPN Client,NS-Remote,リモート,Windows95,Windows98
OS,ＯＳ,オペレーティングシステム,OSタイプ
参考：
Juniper Article ID: KB8343
http://kb.juniper.net/KB8343
| 固定リンク | トラックバック (1)
ダイヤルアップグループ用のVPNを設定した場合、
ユーザがVPNを切断した後でもinactiveの状態でデフォルト60分間SAが維持される。
inactiveのVPNトンネルもトンネル数としてカウントされるため、
VPNトンネル数の上限となり次のユーザが接続できない現象が発生する事がある。
(特に接続ユーザ数に対して最大VPNトンネル数が少ない機種を利用している場合)
この場合、set ike member-sa-hold-timeでSA保持時間を短く調整する事で
ある程度、VPNトンネル数を有効に利用する事が可能である。
以下は、NetScreen-5GT(ScreenOS5.0.0r11)でVPNトンネル数の上限に達した際に
表示されたエラーの例である。Phase2の確立が完了せずfailedとなっている。
※このとき、原因は不明だがNetScreen-Remote8.1側のログではエラー無く
Phase2のSAが確立されたように表示されていた。
YYYY-MM-DD HH:MM:SS system info 00536 IKE<an.ip.add.ress> Phase 2 msg ID
<>: Negotiations have failed.
YYYY-MM-DD HH:MM:SS system info 00536 IKE<an.ip.add.ress> Phase 2 msg ID
<>: Negotiations have failed
for user <>.
コマンド
set ike member-sa-hold-time <minutes 3～ >
(time to hold a sa for a dialup group member)
set ike member_sa_hold_timeのコマンドはダイヤルアップVPNユーザが
NetScreen-Remoteでの接続状態を切断した後、しばらくの期間
NetScreen側でSA割当てを保持しておく時間(分)の長さを調整するために使用されます。
最小の設定値は3分で、デフォルトは60分です。
ScreenOS4.0.0からは「set ike member-sa-hold-time」に変わりました。
現在のSA保持時間を表示するには以下のコマンドを入力します。
get ike member-sa-hold-time
関連コマンド:
get sa
clear sa <SA ID>
clear ike-cookie <IP ADDRESS>
適用ScreenOS：
ScreenOS 3.0.3以上
適用機種：
NetScreen-5GT
NetScreen-5XP
NetScreen-5XT
NetScreen-25
NetScreen-50
NetScreen-204
NetScreen-208
NetScreen-5200
NetScreen-5400
参考：
Juniper Article ID: KB6762
http://kb.juniper.net/KB6762
| 固定リンク | トラックバック (0)
ScreenOS 5.XでのIPSec VPNトンネルの数え方の解説です
1.ライセンスで許可されるトンネル数の表示
コマンド
> get license-key
get license-keyをCLIでタイプして「VPN tunnels」の行を見ます。
以下の4つの出力方式が存在します。
①1つだけ表示される場合：
全ての種類のIPSecVPNの制限数です。
②２つ表示される場合：
1つはサイト間のVPN制限数、もう一つは追加の
ダイヤルアップグループのVPN制限数
③何も表示されない場合：
VPNは許可されません。(F/W用途のみの製品です)
④unlimited表示の場合：
VPNはプラットフォームの制限数に従います。
2.site-to-site, dynamic-peer, manual-key and dialup-user vpnの許可数は
以下のように決定されます
site-to-site, dynamic-peer, manual-key and dialup-user vpnの許可数は
前述のサイト間VPNの割り当て数が適用されます。
"set vpn gateway .. "のコマンドで作成されたvpn tunnelの設定数だけが
カウントされます。(ポリシーあるいはトンネルインターフェースの数では無く)
またそれは、ポリシーで使用されていないか、トンネルインターフェースに
割り当てられていなくても、トンネル数としてカウントされます。
注：VPN用の「ポリシーサブジェクト」の数はプラットフォームの制限に依存。
3.dialup-group vpn の許可数は以下のように決定されます
まず、ダイヤルアップグループVPNには「ダイヤルアップグループのVPN制限数」
が割当てられます。
もし、これ以上「ダイヤルアップグループのVPN制限数」が利用できない場合、
「サイト間VPNの制限数」が割当てられます。
注：
VPNトンネルの設定数はカウントされません
ユーザコネクション数がカウントされます
各ユーザのSAは1つのVPNトンネルとしてカウントされます
適用ScreenOS：
ScreenOS 5.0
適用機種：
NetScreen-5GT
NetScreen-5XP
NetScreen-25
NetScreen-50
NetScreen-204
NetScreen-208
参考：
Juniper Article ID: KB7114
http://kb.juniper.net/KB7114
| 固定リンク | トラックバック (0)
ScreenOS 4.0以上でのVPNトンネルの数え方の解説です
(ScreenOS5.Xでは数え方が若干異なります。)
IKEのVPNトンネルでは、トンネル毎に複数のポリシーを作成できます。
トンネルに含まれた各ネットワークは1つのSAを構成するでしょう。
したがって、VPNトンネルについて複数のSAを持つことができます。
通常のLAN間VPNトンネルでは、作成されたゲートウェイの数とトンネルの数は等しく
なります。
ダイヤルアップVPNユーザのトンネルの数え方は若干異なります。
ダイヤルアップVPNユーザが作成された時、各ユーザは1つのVPNゲートウェイ
としてカウントされます。
(ダイヤルアップVPNユーザ用のゲートウェイが作成された場合と考えた方が
良いかもしれないが、英語ではWhen creating dial-up VPN usersとなっているため
このまま素直に訳した)
もし、ダイヤルアップVPNグループが利用された場合には、ダイヤルアップグループの
IKEエントリーは1つのVPNゲートウェイとしてカウントされ、そして追加の
ダイヤルアップユーザは別のVPNトンネルを使います。
例えば、NetScreen-5XPで以下のVPNを持つ場合、
・3つのLAN間IKEトンネル、
・2つのマニュアルキーVPNトンネル、
・1つのダイヤルアップVPNグループIKEエントリ(20人のVPNグループ)
ダイヤルアップVPNユーザが接続されていない場合にはトンネルの有効な数は6となります。
NetScreen5XPの制限は、10トンネルなので、ダイヤルアップVPNユーザに残されたのは
4つのVPNとなります。
適用ScreenOS：
ScreenOS 4.0以上
適用機種：
NetScreen-5GT
NetScreen-5XP
NetScreen-5XT
NetScreen-25
NetScreen-50
NetScreen-204
NetScreen-208
NetScreen-5200
NetScreen-5400
参考：
Juniper Article ID: KB4204
http://kb.juniper.net/KB4204
| 固定リンク | トラックバック (0)
・コマンド
Set Flow Path-MTU
・要約
VPN越しにフラグメントが必要なパケットが送られてきた場合に、
送信元のホストに"Destination unreachable - fragmentation required"の
ICMPパケットを送る事で、MTUの問題を解決するよう構成できます。
・詳細
set flow path-mtu コマンドはVPNトンネルのフラグメント問題の処理に利用されます。
(このコマンドは暗号化無しの平文で送られるパケットには適用されません。)
このコマンドは2つのホスト間が通過する全てのリンク上で許可される最小のMTUを
決定します。
もし、トンネルの他方のデバイスからヘッダー内のDFビットをセットしたパケットが
送られてきて、そのパケットがフラグメントが必要なぐらい大きければNetScreenは
そのパケットを破棄するでしょう。(例えば、MicrosoftのNBTなど)
set flow path-mtuコマンドが有効である場合に、もう一方のNetScreen上のホストが
DFビットがセットされたパケットを送った場合には、NetScreenは送信元に
"Destination unreachable - fragmentation required"のメッセージをICMPパケットで
送信します。送信元がそのICMPパケットを受信すると、そのホストはパケットのフラグ
メントを防ぐためにMTUサイズを減少させるでしょう。
適用ScreenOS：
ScreenOS4.0.0以上
適用機種：
NetScreen-5GT
NetScreen-5XP
NetScreen-5XT
NetScreen-25
NetScreen-50
NetScreen-204
NetScreen-208
NetScreen-5200
NetScreen-5400
参考：
Juniper Article ID: KB6200
http://kb.juniper.net/KB6200
| 固定リンク | コメント (0) | トラックバック (0)
NetScreenでVPNを設定している場合、しばしば
「received a packet with a bad SPI.」という旨のログが発生する事がある。
これは、NetScreeが不正なSPI番号のIPSecパケットを検出したことを示す。
原因
・IPSecSAの再生成の際のタイミングの不一致
・NAT越えによるSPIの不一致
・クラッカーからのアタックの可能性（も否定できない）
対策
送信元IPを確認してVPN対向先かどうかを確認する。
VPNの対向先でない場合、攻撃の可能性がある。
VPNの対向先である場合は、以下のいづれかの方法で
エラーの発生を回避する事ができる。(私の推奨は3番の方法)
１．次のコマンドで応急的な処置としてSAをクリアする。
> clear ike all
２．ソフトライフタイムを短くする
> set ike soft-lifetime-buffer <number>
※<number> is time to init IKE before hard lifetime (seconds)
但し、ScreenOS 4.0以上のバージョンでは、
デフォルト値が10秒とあらかじめ低い値に設定されているため
変更する必要はほとんど無い。
３．commit bitをセットする
一番良い方法はcommitビットをセットすることです。
その結果、Netscreenは新しいSPIの生成が完了した事を確認してから
パケットを送ります。
※commit bitの詳細はRFC2408
http://www.ietf.org/rfc/rfc2408.txt?number=2408
>set ike initiator-set-commit
>set ike responder-set-commit
| 固定リンク | コメント (0) | トラックバック (0)
最大接続数は NetScreen25/50以外は、
Site-Site VPN = Remote Access VPN = 両者の総数
NetScreen 25/50 の場合、 Site-Site VPN + Remote Access VPN = 両者の総数
また、NetScreen 25/50 に限り、 ScreenOS Ver 5.0 と 5.1 で VPN 本数が異なる。
■ScreenOS Ver5.0
NetScreen 5GT Site-Site VPN: 10 Remote Access VPN: 10 Total: 10
NetScreen 5GT Ex Site-Site VPN: 25 Remote Access VPN: 25 Total: 25
NetScreen 25 Site-Site VPN: 25 Remote Access VPN: 100 Total: 125
NetScreen 50 Site-Site VPN: 100 Remote Access VPN: 400 Total: 500
■ScreenOS Ver5.1
NetScreen 25 Site-Site VPN: 125 Remote Access VPN: 100 Total: 225
NetScreen 50 Site-Site VPN: 500 Remote Access VPN: 400 Total: 900
| 固定リンク | コメント (0) | トラックバック (0)
Ciscoでは「terminal length 0」のコマンド投入でページ毎の
「more」表示を無くす事ができるが、NetScreenで同じような機能を
有効にするには次のコマンドを投入する。
NOTE:Ciscoのようにグローバルコンフィグの概念が無いので
稼働中のコンフィグに入ってしまう。
(保存したければsaveを実行)
Ciscoではtelnetを切断すれば「terminal length 0」が無効になるので
ある意味便利なのだが・・・。
-> set console page 0
無効にするには(最後の0は不要)
-> unset console page
取得するコンフィグに"set console page 0"を含めたくない場合には
次の２つの方法がある。
方法1：excludeで "set console page 0"が含まれる行を表示させないようにする。
-> get config | exclude "set console page 0"
方法2：saveされたコンフィグのみ表示させる
（set console page 0のコマンド投入後saveせずに下記コマンドを実行する）
-> get config saved
| 固定リンク | コメント (1) | トラックバック (0)
NetScreenで警告やトラフィックのログをメールで送信する際には
メールの送信元アドレスはデフォルトで netscreen_admin@[an.ip.add.ress]となっている。
※an.ip.add.ressは通常Untrust側interfaceのIPアドレスがセットされる。
このままではメールサーバの設定によってはドメイン名部分にIPアドレスを利用する事を許可していない場合などがあり、拒否される事が多い。また、仮にリレーできたとしても後段のメールサーバで拒否されたりスパム判定される可能性が残る。
但し、以下のようにNetScreen自身のホスト名とドメイン名を設定する事でメールの送信元アドレスがFQDNを利用したものへ変化する。
set hostname <hostname>
set domain <domain name>
例：ホスト名：netscreen (set hostname netscreen)
ドメイン名：example.jp (set domain example.jp)
ホスト名とドメイン名を上記のように設定した場合、メールの送信元アドレスは「netscreen@example.jp」となります。
もし、どちらか一方しか設定されていないような場合やデフォルトのホスト名、ドメイン名(デフォルトではドメイン名設定なし) を利用している場合には「netscreen_admin@[an.ip.add.ress]」となるようです。
以上
| 固定リンク | コメント (0) | トラックバック (0)
CCNP BCMSN | Cisco | FOUNDRY | Linux | NetScreen | UNIX | セキュリティ | ルーティング(OSPF) | 学問・資格 | 日記・コラム・つぶやき
