|
◆ ルートベースVPNとは
ポリシーベースVPNの場合、各ポリシーに個別のVPNが作成されるため、VPN接続する拠点AとBとの間で
例えば10個のポリシーがある場合、VPNも10個存在することになります。一方で、ルートベースVPNでは
ポリシーでVPNを作るのではなく、VPNはトンネルインターフェースを使用して構築し、拠点間でポイント
ツーポイント接続を行います。VPNトンネル経由でトラフィックを転送するように導くのはルーティング。
※ ルートベースVPNでは、VPN環境でRIPやOSPFなどのダイナミックルーティングプロトコルをサポート。
◆ トンネルインターフェースの特徴
トンネルインターフェースは仮想インターフェースであり物理的に存在しませんが、IPインターフェースで
あることからゾーン割り当て、I/F番号、IPアドレッシングと他のインターフェースと同じ構成を必要とします。
トンネルインターフェースは固定IPアドレスを割り当てる構成、Unnumbered の使用構成の2種類があります。
| トンネルインターフェースのIPアドレス |
説明 |
| 固定IPアドレス |
・ トンネルインターフェース用にIPアドレス/マスクを割り当てる。
・ 物理インターフェースとは重複できないIPアドレスである必要がある。
・ アドレス変換を使用したい場合にMIP、DIPアドレスを使用できる。
・ ピアとなるデバイスと、トンネルI/Fは同じサブネットにする必要がある。 |
| Unnumbered |
・ トンネルインターフェース用にIPアドレスを割り当てる必要なし。
・ MIPやDIPアドレスは使用できない。
・ unnumberedにより別のインターフェースのIPアドレスを利用する。
・ unnumberedで使用するI/F、トンネルI/Fのゾーンは同じにする必要。
|
◆ ルートベースVPNの設定
ルートベースVPNの設定は以下の①～④の手順通りです。設定例は上図構成のOSAKA側のSSGを前提。
1. トンネルインターフェースの作成
set interface tunnel.number zone name
set interface tunnel.number ip [ unnumbered interface interface | address/mask ]
SSG5-> set interface tunnel.1 zone Trust
SSG5-> set interface tunnel.1 ip unnumbered interface ethernet0/1
|
2. IKEフェーズ１ - IKEゲートウェイの作成
set ike gateway name address ip [ Main/Aggressive ] 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 |
3. IKEフェーズ2 - AutoKey IKEの作成、バインドインターフェースの指定
set vpn name gateway phase1name sec-level [ standard | basic | compatible ]
set vpn name bind interface tunnel.number
SSG5-> set vpn P2TOKYO gateway P1TOKYO sec-level standard
SSG5-> set vpn P2TOKYO bind interface tunnel.1
|
※ 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 のように設定。
4. ルーティングの設定
set route network interface tunnel.number
⇒ トンネルはポイントツーポイントであるため、ゲートウェイアドレスを指定する必要はない。
| SSG5-> set route 172.16.2.0/24 interface tunnel.1 |
ルートベースVPNの設定は以上ですが、トンネルインターフェースの位置によりポリシーの設定が必要です。
トンネルインターフェースがソースI/Fと同じゾーンにある場合、ingressとegress I/Fが同ゾーンにあるので
ポリシーは不要で、トンネルインターフェースがソースI/Fと異なるゾーンにある場合はポリシーが必要です。
つまり、上図構成のIPsec-VPNの範囲が示す通り、unnumberedの構成ではポリシーが不要だと分かります。
| IPsec-VPNの確認コマンド |
説明 |
| ping |
上図では、ping 172.16.2.5 from e0/1 でトラフィックを生成してトンネルを確立。 |
| get route ip |
上図では、get route ip 172.16.2.5 により、送出I/FがトンネルI/Fであることを確認。 |
| 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 |
| 注意すべき点 |
説明 |
| プロキシIDの不一致 |
ルートベースVPNのプロキシIDはゼロに設定されているため、特にトンネルピアが
ポリシーベース構成を使用している場合、不一致が生じる可能性が高くなる。 |
| プロポーザルの不一致 |
両拠点のSSGで設定しているプロポーザルが完全一致か確認。Custom時は特に要注意。 |
| ポリシーベースのNAT |
トンネルインターフェースにIPアドレスが割り当てられない構成ではNATは正しく動作しない。 |
| イントラゾーンブロッキング |
ingressとegress I/Fが同じならポリシーは不要だがイントラゾーンブロッキングがOFFが前提。 |
| 出力 I/F の不一致 |
outgoing-interface で指定したインターフェースが外側（インターネット側）であるかを確認 |
| ルーティングのチェック |
ルーティングテーブルに宛先ネットワークへの経路情報が存在することを確認。 |
トンネルインターフェースがデータトラフィックのingress I/Fであり、egress I/Fである点を認識しましょう。
トンネル接続をするために、データの生成をする
ためのPINGは以下の通り、ソースを指定して実行
しましょう。ユーザトラフィックがIKEプロセスを
トリガするまでトンネルは確立されないからです。
ping 172.16.2.5 from e0/1
|
|
◆ メインモード（Main）とアグレッシブモード（Aggressive）の違い
対向機器（リモートゲートウェイ）のIPアドレスが分からない場合（動的なグローバルIPアドレス等の場合）
自身の機器でアグレッシブモードを指定します。自身の機器でアグレッシブモードを指定する前提としては
対向機器のIPが分からないので、対向機器（リモートゲートウェイ）からVPN接続を起動する必要があります。
| IKE Phase1 - 2つのモード |
説明 |
| メインモード |
両方のトンネルピアに静的IPアドレスがある場合に使用するモード
|
| アグレッシブモード |
トンネルピアの１つに動的に割り当てられたIPアドレスがある場合に使用するモード
※ トンネル終端のいずれかが動的なIPアドレスを持つ場合、アグレッシブモードを指定。
|
|