Security Gateway and IPsec release 3
| 作成日 | 2000/Jul/07 |
| 最終変更日 | 2018/Nov/06 |
| 文書サイズ | 21KB |
最近のIKEの実装を概観すると、多くの実装がRFC2401〜RFC2409に対応しており、 潜在的には相互接続性は高いと思われる。しかし、実際に相互接続を試みると、 必ずしも簡単に接続できないことが多いようである。 接続を難しくする要因は幾つかあるが、主なものとして、 以下の3つを挙げることができる。
IKEには、ID、アルゴリズム、PFSなどのパラメータがあるが、これらのパラメータには、 あまりネゴシエーションの余地がないという特徴がある。つまり、 ユーザは、これらのパラメータの意味を把握して的確に設定する必要がある。 また、IKEには、1点の設定ミスが致命的になるという特徴もある。 IKEは、安全に鍵を交換するために多くのチェックを実施するが、 ただ1つのチェックでも失敗すれば鍵交換が失敗するため、 設定を調整するプロセスは、しばしば針の穴を通すように感じられる。
相互接続の問題点を把握するためには、ログを見るのが最も効率の良い方法であると思われる。 しかし、他社の製品の中には、必要なログがほとんど出力されないものや、 意味不明なログばかりが出力されるものがある。残念ながら、 これらの製品を相手にトラブルシューティングをするのは至難である。 このようなときには、しばしば、 考え得るパラメータの組み合わせを試して反応を見るという原始的な方法に頼らざるを得ない。
実装に何らかの問題があって、どのように設定を工夫しても接続できないこともある。 これは、実装の変更を待つ以外に方法はないが、 必ずしも一方的に実装を責めることができない場合もある。 特に、RFCの記述の不明確な部分については、 現在でも実装にばらつきがあることが分かっている。
このドキュメントでは、以上の点に考慮して、 相互接続を試みるときに注意すべき点を記述する。 コマンドの設定例などは、すべてRev.4.00.33以降のファームウェアに基づく。 詳しいコマンド仕様については、 リリース3 コマンド仕様を参照していただきたい。
ここでは、相互接続を試みる前に知っておくべきことや準備すべきことを説明する。
まず、製品の基本的な仕様を確認する必要がある。RFCについては、 RFC2401〜RFC2409あたりに対応していれば良い。 もしくは「IPsec version 2」や「IKE対応」というキーワードがあれば、 接続できる可能性がある。 なお、古いRFCにRFC1825〜RFC1829というものがあるが、 RTシリーズはこれらのRFCには対応していない。
IKEのパラメータについては、実装によってばらつきがあるが、 数が多いため、パンフレットなどに全てを記載しないことが多い。 以下に、IKEに関する主なパラメータを挙げる。
パラメータの項目 パラメータ内容 認証方式 暗号アルゴリズム ハッシュアルゴリズム PFSのon/off(有無) DH(Diffie-Hellman)グループ ISAKMP SAの寿命 IPsec SAの寿命 交換モード(exchange mode) IDの種類 Vender ID
重要なことは、これらを設定する方法と設定可能な値を知ることである。 製品によっては設定できないパラメータがあるかも知れないが、 その場合には値が固定になっているはずであるから、その値を知ることが望ましい。 ただし、分からない場合には、 後述の標準的な値を設定することで接続できることが多いため、 完全に調査しておく必要はない。
なお、これらのパラメータの呼称は様々である。例えば、認証方式については、 「認証の方法」であるかも知れず、 海外製品ならば「Authentication Method」であるかも知れない。 「DHグループ」については、単に「グループ」と呼ぶ場合もある。
交換モードは、鍵交換の方法のバリエーションであり、 メインモード(main mode)、アグレッシブモード(aggressive mode)、 ベースモード(base mode)、クイックモード(quick mode)などの種類がある。 相互接続では、メインモードとクイックモードを選ぶのが無難である。
RTシリーズについても、必要な情報を説明しておく。まず、認証方式については、 pre-shared-key(「事前共有鍵」、「共有キー」などの呼び方がある)をサポートしている。 IKEには、主に4つの認証方式があるが、pre-shared-key以外の認証方式はサポートしない。
暗号アルゴリズムについては、DES-CBCと3DES-CBCをサポートしており、 ハッシュアルゴリズムについては、MD5とSHA-1をサポートしている。細かいことであるが、 SHA-1は単にSHAと表記されることもある。PFSについてはon/offの両方に対応している。 DHグループについては、768bit(グループ1)と1024bit(グループ2)に対応している。 SAの寿命については秒寿命とバイト寿命の2種類を自由に設定することができる。
交換モードについては、メインモードとクイックモードをサポートしている。 最近のファームウェアでは、アグレッシブモードもサポートしているが、相互接続試験では、 使用しないほうが無難である。
IDについては、少し複雑であるため、後で説明する。Vender IDは、 実装の識別子として特殊な用途で使用される。 RTは基本的にVender IDを受け付けず、送信もしないため、 対向の製品では、Vender IDを送信しないように設定する必要がある。 Vender IDに関する設定項目がない機種では、特に配慮する必要はないと思われる。
パラメータ RTシリーズの選択肢 認証方式 pre-shared-key 暗号アルゴリズム DES-CBC, 3DES-CBC ハッシュアルゴリズム MD5, SHA-1(SHA) PFSのon/off(有無) on, off DH(Diffie-Hellman)グループ 768bit(グループ1), 1024bit(グループ2) ISAKMP SAの寿命 秒寿命, バイト寿命 IPsec SAの寿命 秒寿命, バイト寿命 交換モード(exchange mode) main mode, quick mode
アグレッシブモードは相互接続に向かないIDの種類 後述 Vender ID 受け付けない&送信しない
2.で説明したパラメータに注意しながら、設定を行う。基本的には、 両者のパラメータが一致するように設定する。寿命についても一致させることが望ましい。 設定できないパラメータについては、固定の値になっていると思われるので、 その値を知る必要がある。分からない場合には、 以下に示す標準的な値に設定すれば接続できる可能性が高い。
パラメータ 相互接続しやすいパラメータ 認証方式 pre-shared-key (テキストまたはバイナリ) 暗号アルゴリズム DES-CBC ハッシュアルゴリズム MD5 PFSのon/off(有無) off DH(Diffie-Hellman)グループ 768bit(グループ1) ISAKMP SAの寿命 28800秒 IPsec SAの寿命 28800秒 交換モード(exchange mode) main modeとquick mode
アグレッシブモードは相互接続に向かないIDの種類 後述 Vender ID 送信しない
次に、pre-shared-keyの設定を行う。これは、両方の機器に同じ文字列、 またはバイナリ列を設定する。製品によっては、どちらか一方しか設定できないものもある。 RTシリーズでは、文字列の場合は32文字、 バイナリの場合は32バイトまでの長さで設定できる。以下に設定例を示す。 バイナリの鍵には、先頭に'0x'を付ける必要がある。 コマンドの詳細は こちらで確認していただきたい。
IKEには、フェーズ1とフェーズ2という2つの鍵交換のプロセスがあり、 それぞれのプロセスで、IDが交換される。このうち、設定に配慮する必要のあるものは、 フェーズ 2で交換されるIDである。 フェーズ 2のIDは、ESPやAHのトラヒックを識別するために使われるものであるが、 幾つかの種類があり、実装によってはサポートしていないものもあるため、 配慮が必要である。経験的には、 タイプ1(ID_IPV4_ADDR)とタイプ4(ID_IPV4_ADDR_SUBNET)が多いように思われるので、 これらを選択すれば相互接続できる可能性が高い。
タイプ1はIPsecの通信をする特定の機器のIPアドレスを指定するものであり、 タイプ4は通信をする機器の属するネットワークを指定するものである。 多くの実装では、自分側のIDと相手側のIDを設定する。これらは以下の図で示すように、 互いに同じものが設定されなければならない。
自分側のID: タイプ1, 192.168.0.2 自分側のID: タイプ4, 192.168.1.0/24
相手側のID: タイプ4, 192.168.1.0/24 相手側のID: タイプ1, 192.168.0.2
+-------------+ +-------------+
| IKE gateway | <---------------------> | IKE gateway |
+------+------+ IKE +-------+-----+
| |
| |
-----+------+------ -----+-----+------ 192.168.1.0/24
| |
host 192.168.0.2 host
また、実装によっては、IDを交換しない方が良好に相互接続できるものがある。 もし「IDを送信しない」という設定が可能な製品であれば、 RTについても送信しないように設定して接続する価値がある。
RTシリーズでIDを設定するためには、ipsec ike local idコマンドと ipsec ike remote idコマンドを用いる。前者は自分側のIDを設定するコマンドであり、 後者は相手側のIDを設定するコマンドである。 IDを送信しないときには、これらのコマンドを設定してはならない。 逆に、IDを送信するときには、両方のコマンドを設定する必要がある。 IDとして、タイプ1のIDを送信するときには、IPアドレスのみを設定する。また、 タイプ4のIDを送信するときには、ネットマスクを付加する。以下に例を挙げる。
何よりもまず、2つの機器が相互に通信できることを確認する必要がある。 IKEの通信は、UDPの500番ポートを使用するため、最低限、 この通信が実施できなければ無意味である。firewall系の製品の場合、 アクセスコントロールが厳しくて面倒なこともあるが、互いにpingを打つなどして、 通信できることを確認しておく。
一方の機器を始動側(initiator)、 もう一方を応答側(responder)と決めて試験を実施し、 その後、始動側と応答側を交代して同じ試験を実施する。 失敗したときには再挑戦することになるが、 このときに古いSAが残っていると、鍵交換の挙動が変わってしまう可能性があるので、 それらを消してから再挑戦することが重要である。
失敗したときには、ログを取って解析する。RTでは以下のように、 IKEの全てのログが出力されるような設定をしておく。
ipsec ike log 1 key-info payload-info message-info
ここで、key-infoは、Diffie-Hellman値などの鍵の計算結果を表示するための キーワードであり、payload-infoは、 IKEメッセージに含まれる各ペイロードの処理結果を表示するためのキーワードである。 また、message-infoは、送受信したIKEメッセージを表示するためのキーワードである。
キーワード ログ内容の説明 payload-info IKE messageを構成するpayloadの解析結果を出力します。 payloadとは、IKEに関する情報の単位であり、普通、1つの IKE messageは、複数のpayloadが連結されて作られています。 key-info 鍵に関係する情報を出力します。例えば、DH(diffie-hellman)の 値、SKEYID、DESのIVなどです。 message-info 送受信されたIKE messageを16進数を出力します。
対向の製品についても、できる限りログを取ることが望ましい。
IKEやIPsecの相互接続試験では、 pingやFTPで通信できるか否かを調べて相互接続性を判定することが多いようであるが、 これは目標設定が高過ぎるように思われる。もちろん、 1回の試行でpingやFTPが可能であれば、それが一番すばらしいが、 現実には、鍵交換が失敗したり、鍵交換が成功しても、 ESPやAHの設定を間違えているために通信できないことが多いものである。
相互接続のゴールは、もちろん相互接続を達成することであるが、 IKEの相互接続では、目先のゴールを目指して少しずつクリアしていくことを提案したい。 メインモードとクイックモードを使用するならば、 全部で9つのIKEメッセージが送受信されて鍵交換が完了するが、 実際に幾つのメッセージが送受信されたかを調べ、それを達成度と考えるのである。
トラブルの種類は多岐に渡り、全てを網羅することが難しいため、 良くある問題について説明する。
始動側が鍵交換を開始したにもかかわらず、応答側が全く反応しない場合であり、 多くは応答側の設定の問題か、通信路の問題である。多くの製品は、 鍵交換の相手を指定することができるので、その指定が間違っていないことを確認する。 応答側には、全くログが出力されないか、「鍵交換の要求が拒否された」というような メッセージが出力されるはずである。
一方の機器が送信した提案が、他方の機器で受理されない場合である。 始動側と応答側はともに提案を送信するので、 両方の機器が相互に提案を受理しなければ、鍵交換は成立しない。 提案を拒否した機器のログには、 「提案(proposal)が選ばれなかった」 というような意味のメッセージが出力される可能性がある。 なお、提案を拒否された側の機器には、何のログも表示されないことがあるので、 注意が必要である。この場合には、単に再送を繰り返していることが多い。
確認すべき点は、パラメータの整合性である。3.で説明したパラメータについては、 再確認が必要である。パラメータを揃えることは良いアプローチであるが、 他の値に変更することで解決できる可能性もある。 例えば、IDとしてタイプ1を設定していたら、 これをタイプ4に変更したり、IDを送信しないようにすることが有効であるかも知れない。 寿命の値や、PFSの値などを試みる価値もある。 パラメータを変更するときには、両方の機器で同じように変更するべきである。
復号化とは、暗号化(encryption)の逆で、暗号化されたメッセージを元に戻すことである。 IKEのメッセージは、初めから数えて3番目以降については、暗号化されて送信される。 したがって、このメッセージを受信した機器は、これを復号化する必要があるが、 しばしば、復号化に失敗することがある。
この現象は、判別と対策が難しいことが多く、面倒なものである。まず、 この現象の見分け方は、始動側において、3番目に送信したメッセージが 繰り返し再送されていることである。このとき、応答側のログを見ると、 何らかのエラーメッセージが出ていると思われる(機種によっては出ていない場合もある)。 エラーメッセージの種類は様々であり、あまり特徴的なものはない。 RTシリーズの場合には、 「フォーマットがおかしい」などの意味のメッセージが出力される可能性が高い。
対策としては、pre-shared-keyの見直しをする必要がある。 特に長い鍵を設定しているときには、入力ミスの可能性もある。 それ以外には、実装に起因する場合が多い。 つまり、頑張っても報われないことが多い。
相手の機器が送信したIDを受理できないことによって、鍵交換が失敗する場合である。 この現象が起きるのは、ほとんどフェーズ2であり、 フェーズ1で起きることはあまりないようである。 フェーズ2に入っていることを確認するためには、ログを見るか、SAのリストを見ると良い。 ログが少ない機器でも、フェーズ1とフェーズ2が終了したときには、 ログを出力するのが普通であるし、フェーズ1が終了していれば、 1つのSAが生成されているはずである。
対処は、IDの設定を再確認することである。IDを送信しないように設定できる場合には、 送信しないことで、回避できることもある。なお、これまでのところでは、 パラメータを揃えることを強調しているが、IDに関しては、 必ずしもこの戦略は妥当ではなく、 一方のみを送信しないように設定するだけで済む場合もある。