Security Gateway and IPsec
| 作成日 | 1998/Jun/09 |
| 最終変更日 | 2018/Nov/06 |
| 文書サイズ | 24KB |
ここでは、RTのコマンドを紹介しながら、具体的な 利用方法を説明します。 なお、このドキュメントを読む前に、セキュリティ・ゲートウェイ機能の基礎知識を 一読されることをお勧めします。
設定する前には必ず、SAの自動更新機能をoffにし、 古いSAを全て削除して下さい。
#ipsec auto refresh off #ipsec sa delete all自動更新機能をonにして設定すると、設定中にも関わらず、 IPsecの各機能が働いてし まいます。 また、設定が変化するにも関わらず、古い設定に依存したSA が残っていると、災いの 種になるかも知れません。
まず、鍵交換のために必要な事前共有鍵を設定します。 事前共有鍵は、鍵交換の際に 相手を認証するための 情報として用います。 事前共有鍵は、対向のゲートウェイ ごとに設定します。もちろん、相手側でも同じ鍵 を 設定する必要があります。コマンドは、以下のように なります。
#ipsec pre-shared-key 192.168.101.1 text himitsu192.168.101.1は、対向のゲートウェイのアドレスです。 鍵は、テキスト形式か バイ ナリ形式で入力します。鍵の長さは、テキスト形式 の場合、最大32文字、バイナリ形 式の場合、最大32byte です。
鍵交換要求を受け付ける対向のゲートウェイを指定します。 通常は、事前共有鍵を指 定した相手先ゲートウェイの IPアドレスを入力します。
#ipsec ike host 192.168.101.1複数のアドレスを指定することも可能であり、
#ipsec ike host 192.168.101.1 192.168.101.2 ...の形で、10個まで列記できます。 なお、相手先ゲートウェイでも、このコマンドを 設定し、自分側からの鍵交換要求を 受け付けるように しておく必要があります。
SAの寿命を設定します。例えば、
#ipsec sa duration 10000のように設定すると、SAの寿命は生成されて から10,000秒となり、10,000秒が経つと 自動的 に消滅します。あるいは、
#ipsec sa lifetime kilobyte 100のように入力します。この場合、SAによって 100kbyteのデータが処理されたときに、 SAは消滅 します。 なお、一般には「SAの寿命」＝「鍵の寿命」では ありませんが、RTの実装では、SAの 寿命と鍵の寿 命は同じ値を取るものとしています。
SAの属性のうち、ユーザが指定できるものを、 SAのポリシーと呼びます。なお、SAの 寿命も、 ユーザが指定できるので、SAのポリシーですが、 RTの実装ではSAの寿命を他 の属性と区別しています。 SAのポリシーの設定例を以下に示します。
#ipsec sa policy 101 133.176.200.199 ah md5-hmac [引数の説明] 101 ... SAのポリシーを管理するためのID 133.176.200.199 ... 対向のセキュリティ・ゲートウェイのアドレス ah ... AHで用いることを示す識別子 md5-hmac ... AHで用いる認証のアルゴリズムのように設定します。もうひとつの例を示します。
#ipsec sa policy 102 133.176.200.199 esp des-cbc sha-hmac [引数の説明] 102 ... SAのポリシーを管理するためのID 133.176.200.199 ... 対向のセキュリティ・ゲートウェイのアドレス esp ... ESPで用いることを示す識別子 des-cbc ... ESPで用いる暗号アルゴリズム sha-hmac ... ESPで用いる認証アルゴリズム（認証をしない場合は省略可）のように設定します。
以下では、図のようなVPNを構築したい場合を例に して、コマンドと設定例を説明しま す。
----------+-------------------- 192.168.100.0/24
|
| 192.168.100.1
+----+----+
| RT140i |
+----+----+
: pp local = 172.16.1.1 (SGWアドレス)
:
:
:
: pp local = 172.16.1.2 (SGWアドレス)
+----+----+
| RT100i |
+----+----+
| 192.168.101.1
|
----------+-------------------- 192.168.101.0/24
トンネルモードを利用するためには、トンネルインタ フェースという仮想インタフェー
スを用意し、 処理したいパケットがトンネルインタフェースに 流れるように、経路情
報を設定します。
経路表にトンネルインタフェースへ向けられた経路情報が ある場合、LANやPP向けの経
路情報より優先的に利用されます。 トンネルインタフェースに送られた パケットは、
AHかESPを付加されて、再びルーティング テーブルに戻されます。ただし、同じパケッ
トが2回 トンネルインタフェースに送られることはありま せん。
上図の2台のRTの設定は例えば以下のようになります。
[RT140iの設定] #bri local address 1 03-123-4567 #ip lan address 192.168.100.1/24 #ipsec ike host 172.16.1.2 #ipsec pre-shared-key 172.16.1.2 text himitsu #ipsec sa policy 101 172.16.1.2 esp des-cbc md5-hmac #pp select 1 pp1#pp bind bri 1 pp1#isdn remote address call 06-111-9999 pp1#ip pp local address 172.16.1.1/24 pp1#ip pp remote address 172.16.1.2 pp1#pp enable 1 pp1#tunnel select 1 tunnel1#ip tunnel route add net 192.168.101.0/24 2 tunnel1#ipsec tunnel 101 tunnel1#tunnel enable 1192.168.101.0/24へ向かうパケットをトンネルインタフェースに 送り、101番のポリシー によって処理します。すなわち、 DES-CBCという暗号アルゴリズムとHMAC-MD5という認 証アルゴリズム を用いてESPを付加します。
[RT100iの設定] #isdn local address 06-111-9999 #ip lan address 192.168.101.1/24 #ipsec ike host 172.16.1.1 #ipsec pre-shared-key 172.16.1.1 text himitsu #ipsec sa policy 101 172.16.1.1 esp 3des-cbc sha-hmac #pp select 1 pp1#isdn remote address call 03-123-4567 pp1#ip pp local address 172.16.1.2/24 pp1#ip pp remote address 172.16.1.1 pp1#pp enable 1 pp1#tunnel select 1 tunnel1#ip tunnel route add net 192.168.100.0/24 2 tunnel1#ipsec tunnel 101 tunnel1#tunnel enable 1192.168.100.0/24へ向かうパケットをトンネルインタフェースに 送り、101番のポリシー によって処理します。すなわち、 3DES-CBCという暗号アルゴリズムとHMAC-SHAという 認証アルゴリズム を用いてESPを付加します。
ipsec ike hostやipsec pre-shared-keyで設定するアドレスは、 互いに最も近いイン タフェースのアドレスを利用します。 例えば、上図のような環境では、LANのアドレス ではなく、 PPのアドレスを利用します。但し、Unnumberedで接続している 場合は、ip lan(1) addressで設定されたアドレスとなります。 また、トンネルインタフェースは鍵交換の終了後に有効になります。 したがって、鍵 交換のためのパケットがトンネルインタフェースに 流れないように、経路情報を設定 してください。具体的には、 相手先のセキュリティ・ゲートウェイのアドレスに対し て 相互にping応答があることを確かめてください。
トンネルモードの効果を試す場合、RT140iとRT100iの両方で、
#ipsec refresh saと入力します。正常な場合、 10秒程度で、鍵交換が終了し、必要なSAが生成されます。 鍵交換が終了した直後より、トンネルインタフェースが 有効になります。
現在管理されているSAの状態を見るためには、
#show ipsec saと入力します。以下では、この出力結果について 説明します。
# show ipsec sa SA[7] / 寿命: 334(秒), 送受信方向: 送信 相手ホスト: 133.176.200.197 プロトコル: IKE 状態: established idle SPI: 12 34 C6 E8 34 14 CC 49 F9 40 3E 67 94 E5 42 40 鍵 : 27 67 9E 74 7C 6F BB 1D 8D 11 EE A9 08 2A 53 4D ---------------------------------------------------- SA[8] / 寿命: 334(秒), 送受信方向: 送信 相手ホスト: 133.176.200.197, IKE SA : SA[7] プロトコル: AH (モード: transport[1]) アルゴリズム: HMAC-MD5 状態: established idle SPI: 91 2C C0 51 鍵 : 75 38 BF 9F BD 86 62 76 89 F7 32 03 23 4F 00 AA ----------------------------------------------------
ここでは、 AHやESPをトランスポートモードで利用する場合の設定を 説明します。ト ランスポートモードは、RT対RTの通信に 対してのみ有効であり、telnetでの遠隔設定 など特殊な 用途で利用します。また、後述のようにトンネルモード と複合的に利用す ることができます。
#ipsec sa policy 102 133.176.200.199 esp des-cbc sha-hmac #ipsec transport 1 102 tcp * telnetこの例では、このホストから対向のRTである133.176.200.199へ 向かうパケットのうち、 TCPの相手先ポートがtelnetであるような パケットに対して、ESPを付加します。また、 ESPの暗号アルゴリ ズムとして、DES-CBCを、認証アルゴリズムとして、HMAC-MD5を 用 います。 トランスポートモードでは、 ひとつのパケットに複数のAHとESPを付加することが で きます。 トランスポートモードの処理では、ipsec transport の設定をIDの小さいものから順に 調べ、処理中の パケットの内容と比較をします。そして、 IPヘッダの宛先、トランス ポート層（IPヘッダに続く 部分）のプロトコルなどをチェックし、処理が必要と 判断 された場合に、AHかESPを付加します。 ipsec transportの設定が残っている場合には、残り の設定についても順に比較をし、 随時AHやESPを付加 します。 次の例では、
#ipsec sa policy 101 133.176.200.199 esp 3des-cbc #ipsec sa policy 102 133.176.200.199 ah md5-hmac #ipsec sa policy 103 133.176.200.199 esp des-cbc #ipsec transport 1 101 icmp * * #ipsec transport 2 102 icmp * * #ipsec transport 3 103 icmp * *このルータから133.176.200.199へのICMPパケットに 対して、 #ipsec transport 1 101 icmp * *により、
[IPヘッダ][ESP {[ICMP]}]
#ipsec transport 2 102 icmp * *により、
[IPヘッダ][AH][ESP {[ICMP]}]
#ipsec transport 3 103 icmp * *により、
[IPヘッダ][ESP {[AH][ESP {[ICMP]}]}]
のパケットが順に生成されます。
なお、ipsec transportの設定と、SAのポリシーの設定は 一対一に対応している必要は
ありません。例えば
#ipsec sa policy 101 133.176.200.199 esp des-cbc #ipsec transport 1 101 icmp * * #ipsec transport 2 101 icmp * * #ipsec transport 3 101 icmp * *のような設定も可能です。この場合、各ipsec transport の設定に対する3つのSAが生 成され、ICMPのパケットに、3 つのESPが付加されることになります。
ここでは、ひとつのパケットに、トンネルモードと トランスポートモードの両方で、 AHやESPを付加する ための設定について説明します。 このためには、まず、以下に示すパケット処理の流れを 理解する必要があります。
IPパケットの待ち行列
|
|
フィルタ(in)
|
+------------------→|
| |
| トランスポートモードで
| AHやESPを付加
| |
| |
| ルーティング
| |
| 宛先がトンネルI/F
| であるか？
| |
| +------+-------+
| Yes | | No
| | |
| トンネルモードで フィルタ(out)
| AHやESPを付加 |
| | |
| | 各I/Fへパケット
+-------------+ を流す
待ち行列から取り出されたパケットは、フィルタを くぐったあと、必要があればトラ
ンスポートモードで AHやESPが付加されます。
その後、ルーティングの処理に移り、トンネルインタ フェースにルーティングされた
場合には、トンネルモー ドでAHやESPが付加されます。それ以外のパケットは、 その
他のインタフェースに送られます。経路表に トンネルインタフェースへ向けられた経
路情報が ある場合、LANやPP向けの経路情報より優先的に 利用されます。
トンネルモードの処理の済んだパケットは、再びトランス ポートモードの処理に移さ
れます。その後、ルーティング の処理を受けますが、2回目のルーティングでは、 ト
ンネルインタフェースにはルーティングしません。
例えば次の設定で
#ipsec sa policy 101 133.176.200.197 ah md5-hmac #ipsec sa policy 102 133.176.200.197 esp des-cbc #ipsec transport 1 101 esp * * #tunnel select 1 tunnel1#ip tunnel route add 192.168.1.0/24 2 tunnel1#ipsec tunnel 102 tunnel1#tunnel enable 1192.168.1.2へ向けられたパケットが来た場合、 トンネルモードの設定により、
[IPヘッダ(宛先:133.176.200.197)] [ESP {[IPヘッダ(宛先:192.168.1.2)] ...}]
というパケットが生成され、その後、 トランスポートモードの設定により、
[IPヘッダ(宛先:133.176.200.197)] [AH] [ESP {[IPヘッダ(宛先:192.168.1.2)] ...}]
というパケットが生成されることになります。
鍵交換に関係するログは、syslog debug onが設定されているときに 見ることができま す。鍵交換に関係するログは、行頭が[IKE] で表示されます。 (1) 鍵交換の要求を出す側では、
[IKE] initiate ike phase to xxx.xxx.xxx.xxx [IKE] add SA[?] [IKE] finished successfullyまたは、
[IKE] initiate ipsec phase for tunnel[?] [IKE] add SA[?] [IKE] finished successfullyというようなログが出ます。add SAというのは、SAを作ったよ、という 意味ですが、 このログが出た時点では、SAの中身はからっぽです。 鍵交換は、finished successfullyが出た時点で終了し、この時点で 初めて完成されたSAになります。 失敗したときには、timeoutなどの理由表示に加えて、
[IKE] delete SA[?]というログが出ます。すなわち、鍵交換が失敗し、作ったSAが 削除されたことを示し ます。 (2) 鍵交換の要求を受ける側では、
[IKE] initiate ike phase to xxx.xxx.xxx.xxxや
[IKE] initiate ipsec phase for tunnel[?]の行はなく、いきなり
[IKE] add SA[?] [IKE] finished successfullyというログが出ます。以下に、良くあるログの実例を説明します。
[例] >1998/05/15 20:53:55: [IKE] initiate ike phase to 192.168.240.1 >1998/05/15 20:53:55: [IKE] add SA[1] ＃IKEフェーズの鍵交換の要求を出した。 ＃SA(ID=1)を作った。 >1998/05/15 20:54:05: [IKE] add SA[2] >1998/05/15 20:54:06: [IKE] finished successfully ＃鍵交換の要求を受けた。 ＃SA(ID=2)を作った。 ＃鍵交換が成功。 >1998/05/15 20:54:06: [IKE] add SA[3] >1998/05/15 20:54:06: [IKE] finished successfully ＃鍵交換の要求を受けた。 ＃SA(ID=3)を作った。 ＃鍵交換が成功。 >1998/05/15 20:54:15: [IKE] timeout >1998/05/15 20:54:15: [IKE] delete SA[1] ＃SA(ID=1)の鍵交換がタイムアウトで失敗したので、SA(ID=1)を消す。 >1998/05/15 20:54:15: [IKE] initiate ike phase to 192.168.240.1 >1998/05/15 20:54:15: [IKE] add SA[1] ＃IKEフェーズの鍵交換の要求を出した。 ＃SA(ID=1)を作った。 >1998/05/15 20:54:15: [IKE] invalid cookie >1998/05/15 20:54:15: [IKE] failed ＃クッキーが不正である（相手側で以前のSAがまだ消えていない ＃ときに起こりやすい）。 >1998/05/15 20:54:16: [IKE] finished successfully ＃鍵交換が成功。 >1998/05/15 20:54:16: [IKE] initiate ipsec phase for tunnel[1] >1998/05/15 20:54:16: [IKE] add SA[4] >1998/05/15 20:54:16: [IKE] finished successfully ＃IPsecフェーズの鍵交換の要求を出した。 ＃SA(ID=4)を作った。 ＃鍵交換が成功。
寿命の切れたSAは自動的に消滅してしまうので、そのたびに SAを作り直すのは非常に 面倒です。そこで、RTでは、残り寿 命が少なくなったSAや、リブートなどによって消 滅してしま ったSAを自動的に生成する「自動更新機能」を実装していま す。これは、 大きく分けて以下の2つの機能からなります。
送信用SAについて、SAの残り寿 命が少なくなったり、消 滅しているときに、新しいSAを生 成する機能。
必要な受信用SAがないときに、 送信側に対して、新しい SAの生成を促す機能。
自動更新機能を利用するときには、
#ipsec auto refresh onというコマンドを設定します。 なお、自動更新機能を設定しているときに、ネットワークに トラブルが発生すると、 鍵交換の要求がいつまでも反映されず、 回線が接続されたままになる恐れがあります。 そこで、Rev.3.00.10以上のファームウェアでは、一定回数以上、 自動更新に失敗する と、自動更新機能が働かなくなる機能が実 装されました。 自動更新機能が働かなくなると、
stop refreshing SAs(send) stop refreshing SAs(receive)というログが出力されます。両者は、それぞれ送信用SAと 受信用SAの自動更新機能が 停止したことを示します。 なお、一度、停止した自動更新機能を復活させるためには、 以下のどちらかのコマン ドを入力します。
ipsec auto refresh on ipsec refresh sa
セキュリティ・ゲートウェイ間でIPアドレス変換処理(NATなど)が施されると IPsecの通信ができません。 もし、IPアドレス変換処理が施された場合、 IPsecの認証機能により「改竄された」と判断されることになります。
セキュリティ・ゲートウェイ間では、IPアドレス変換処理されない 通信路を確保してください。
RTシリーズでも、セキュリティ・ゲートウェイ機能とNAT機能やNATディスクリプタ機能を併用される時には、 IPsecパケットが通信相手のセキュリティ・ゲートウェイに届けられる経路で、 RTのNAT処理対象になることがあります。 そのような状況が想定される構成のときには、 NATのアドレス変換規則の設定コマンド(nat address global, nat address privateなど)により、IPsecパケットが変換対象にならないよう に設定する必要があります。