|
◆ SSGにおけるIPsec-VPN
SSGでは、IPsec-VPNによるVPN接続が可能です。ただし、SSL-VPNによるVPNは対応していません。
なお、IPsec-VPNの一般的なネットワーク技術は VPNとは をご参照ください。JuniperのVPN方式は、
ポリシーベースVPNとルートベースVPNの2種類があります。ここではポリシーベースVPNを紹介します。
◆ IPsec-VPNで使用するポート番号
IPsec-VPNで使用するプロトコル番号やポート番号は以下の通りです。ポリシー作成時に指定しましょう。
AHは、CiscoでもJuniperでも、IPsec-VPNでは通常は使用されておらず、ESPを使用するのが一般的です。
| IPsecを構成するプロトコル |
プロトコル番号 |
ポート番号 |
| AH |
51 |
- |
| ESP |
50 |
- |
| IKE |
17 ( UDP ) |
500 |
| NAT Traversalの場合 |
17 ( UDP ) |
4500 |
◆ ポリシーベースVPNとは
ポリシーベースVPNは、定義したポリシーに合致するトラフィックをVPNトンネルに従い転送する方式です。
ポリシーベースVPNのためのポリシーのアクションは「permit」ではなくてtunnelキーワードを指定します。
下図は、クライアントPC AからBにパケットを送信した時のポリシーベースVPNにおけるフローとなります。
④を補足すると、正確には「暗号化 ⇒ 認証鍵でハッシュ」というフロー経て④のパケットとなります。次は
上図のVPNパケットがトンネルピア（TOKYOのSSG）に着信した時のパケットフローを確認してみましょう。
◆ ポリシーベースVPNの設定
ポリシーベースVPNの設定は以下の①～④の手順通りです。設定例は上図構成のOSAKA側のSSGを前提。
1. IKEフェーズ１ - IKEゲートウェイの作成
set ike gateway name address ip outgoing-interface int preshare key sec-level [ standard | basic | compatible ]
| SSG5-> set ike gateway P1TOKYO address 2.2.2.2 outgoing-int e0/0 preshare JUNI
sec-level standard |
2. IKEフェーズ2 - IKE VPNの作成
set vpn name gateway phase1name sec-level [ standard | basic | compatible ]
| SSG5-> set vpn P2TOKYO gateway P1TOKYO sec-level standard |
※ Configでは右記のように表示 ⇒ set vpn P2TOKYO gateway P1TOKYO no-replay tunnel idletime 0 sec-level standard
※ proposal をカスタマイズしたい場合 sec-level ではなくて proposal g2-esp-3des-sha g2-esp-des-md5
のように設定します。
※ g2-esp-3des-sh の g2 とは、Diffie-Hellman Group2 のことであり、鍵交換用のグループが Group2
であることを意味します。
3. アドレスブックの作成
set address zone name ipaddress/mask
SSG5-> set address Trust OSAKANW 172.16.1.0/24
SSG5-> set address Untrust TOKYONW 172.16.2.0/24
|
4. ポリシーの作成
set policy [ id number ] from zone to zone source-address dest-address service tunnel vpn name
SSG5-> set policy from Trust to Untrust OSAKANW TOKYONW ANY tunnel vpn P2TOKYO
SSG5-> set policy from Untrust to Trust TOKYONW OSAKANW ANY tunnel vpn P2TOKYO
|
| IPsec-VPNの確認コマンド |
説明 |
| ping |
上図では、ping 172.16.2.5 from e0/1 でトラフィックを生成してトンネルを確立。 |
| get ike cookie |
IKEフェーズ1 の確認。「Active」がカウントされて、各情報が含まれたCookieの生成を確認。 |
| get sa active |
IKEフェーズ2 の確認。「Sta」がA（成功）なのか確認。行き帰りの両トンネルの存在を確認。 |
| get log event |
IKEフェーズ1、IKEフェーズ2 のログを確認。 |
| get event type 536 |
ピアが認識されない、プロポーザルの不一致、プロキシIDの不一致を確認 |
| IKEフェーズ |
トラブルシューティングコマンド |
| IKE Phase 1 |
get ike cookie / debug flow basic / debug ike / get log event |
| IKE Phase 2 |
get sa active / unset ike policy-checking / debug ike / get log event |
IPsec-VPN接続が上手く行われない場合は、以下の5点を再度ご確認下さい。
| IPsec-VPNの確認コマンド |
説明 |
| プロキシIDの不一致 |
プロキシIDの不一致（アドレス帳エントリの不一致）によりIKEフェーズ2でエラーが発生。
⇒ network/length 含めて両拠点のSSGのアドレスブックに対称性があるかを確認しよう。
|
| プロポーザルの不一致 |
両拠点のSSGで設定しているプロポーザルが完全一致か確認。Custom時は特に要注意。 |
| Preshared-keyの不一致 |
両拠点のSSGで設定している事前共有鍵（preshare)が完全一致か確認しよう。 |
| 出力 I/F の不一致 |
outgoing-interface で指定したインターフェースが外側（インターネット側）であるかを確認 |
| ルーティングのチェック |
ルーティングテーブルに宛先ネットワークへの経路情報が存在することを確認。 |
◆ プロキシIDとは
プロキシIDは、VPNピア間でポリシールールを交換するために使用されます。以下の3つの特徴があります。
1. プロキシIDは、ローカルで生成されたIKE Phase2のIKE ID
⇒ プロキシIDはVPNで参照されるSAの識別に使用されます。
2. プロキシIDは、VPNごとに以下の2つの値
⇒ ローカルプロキシID ( ピアのリモートプロキシIDに一致 )
⇒ リモートプロキシID ( ピアのローカルプロキシIDに一致 ）
3. プロキシIDは、ポリシーチェックで使用
⇒ ピアゲートウェイの構成で複数のトンネルがサポートされる場合に使用されます。
⇒ 2つのピア間に1つのポリシーのみ構成されている場合はポリシーチェックを使用不可にできます。
デフォルトでSSGではポリシーチェックが使用可能になっており、プロキシIDにより送信されるポリシーは
ローカルで構成されているポリシーと比較されます。そのため、アドレス帳入力が一致することが重要です。
例えば、ポリシーステートメントで送信元アドレス「192.168.1.0/24」宛先アドレス「192.168.2.0/24」
を使用している場合、SSG-2はポリシーを作成する際に同じアドレスを定義して、使用する必要があります。
SSG-2で 192.168.2.0/24 の代わりに「192.168.2.10/32」と定義している場合、ポリシーステートメント
は一致せずIPsec-VPNは確立されません。このようなプロキシID不一致はVPNの失敗によくあるので要注意。
|