IPsec 相互接続の手引き


1. はじめに

IKEをサポートする製品の多くはRFC2401〜RFC2409に対応しているものの、 実際に相互接続をしてみると、必ずしも簡単には接続できないように思われます。 相互接続を難しくしている要因には幾つかありますが、主なものとして、 設定の難しさ、ログの分析の難しさ、実装の問題があります。

1.1. 設定の難しさ

IKEには、ID、アルゴリズム、PFSなどのパラメータがありますが、 IKEのパラメータには、 あまりネゴシエーションの余地がないという特徴があります。 つまり、ユーザは、これらのパラメータの意味を把握して、 正しく設定する必要があります。

また、IKEには、1点の設定ミスが致命的になるという特徴もあります。 IKEは、安全に鍵を交換するために多くのチェックを実施しますが、 ただ1つのチェックを失敗しただけで鍵交換を止めてしまいます。 したがって、設定を調整するプロセスは、針の穴を通すように感じられます。

1.2. ログの分析の難しさ

相互接続の問題点を把握するためには、 ログを分析することが最も効率のよい方法だと思われます。 しかしながら、必ずしも必要なログがすべて出力されるとは限りません。 また、出力されたとしても意味が分からないこともあります。

したがって、仕方がないので設定をさまざまに変更し、 想定されるパラメータの組み合わせをすべて試すことがよくあります。

1.3. 実装の問題

実装に何らかの問題があって、 どのように設定を工夫しても接続できないこともあります。 これは、実装の変更を待つ以外に方法はありませんが、 必ずしも一方的に実装を責めることができない場合があります。 特に、RFCの記述が明確でないところは、 実装にばらつきがあることが分かっています。

この文書では、以上の点を考慮して、 相互接続を試みるときに注意すべき点を記述します。 コマンドの設定例などは、すべてRev.8.01.19に基づいていますので、 古いファームウェアでは、コマンドの書式などが異なる場合があります。

2. 準備

まず、相互接続を試みる前に、 知っておくべきことや準備すべきことを説明します。

2.1. 他社製品の調査

まず、製品の基本的な仕様を確認する必要があります。RFCについては、 RFC2401〜RFC2409に対応していればよいと思われます。 これらよりも古いRFCとしてRFC1825〜RFC1829がありますが、 RTシリーズはこれらのRFCには対応していません。

IKEのパラメータについては、実装によってばらつきがありますが、 パラメータの数が多いため、 パンフレットなどにすべてを記載しないことが多いようです。 IKEに関する主なパラメータは次のとおりです。

パラメータの項目パラメータ内容
認証方式      
暗号アルゴリズム
ハッシュアルゴリズム
PFSのon/off(有無)
DH(Diffie-Hellman)グループ
ISAKMP SAの寿命
IPsec SAの寿命
交換モード(exchange mode)
IDの種類
Vendor ID

ポイントは、これらのパラメータを設定する方法と、 設定可能な値を知っておくことです。 また、設定できないパラメータがある場合には、 その値は固定になっているはずなので、その値を知る必要があります。 なお、分からないパラメータについては、 後述の標準的な値を設定することで接続できることがあります。

パラメータの呼称にはばらつきがあり、たとえば、認証方式については、 「認証の方法」「Authentication Method」などと表記されます。 また、「DHグループ」については、単に「グループ」と書く場合があります。

交換モードは、鍵交換の方法のバリエーションで、 メインモード(main mode)、アグレッシブモード(aggressive mode)、 ベースモード(base mode)、クイックモード(quick mode)などの種類があります。

2.2. RTシリーズ

RTシリーズについても、必要な情報を説明します。まず、認証方式については、 pre-shared-key(「事前共有鍵」、「共有キー」などの呼び方がある) をサポートしています。 IKEには、主に4つの認証方式がありますが、 pre-shared-key以外の認証方式はサポートしていません。

暗号アルゴリズムについては、DES-CBC、3DES-CBC、AES-CBCをサポートしており、 ハッシュアルゴリズムについては、MD5とSHA-1をサポートしています。 SHA-1は単にSHAと表記されることもあります。 なお、RTシリーズはSHA-2には対応していません。 AES-CBCの鍵の長さは128ビットにのみ対応します。

PFSについてはon/offの両方に対応しています。 DHグループについては、MODP768(グループ1)とMODP1024(グループ2)に対応しています。 SAの寿命については秒寿命とバイト寿命の2種類を自由に設定することができます。

交換モードについては、メインモード、アグレッシブモード、 クイックモードをサポートしています。

IDについては、少し複雑なため、後で説明します。Vendor IDは、 実装の識別子として特殊な用途で使用されるものですが、 RTシリーズはVendor IDを受け付けず、送信もしないので、 対向の製品では、Vendor IDを送信しないように設定する必要があります。 Vendor IDに関する設定項目がない機種では、特に配慮する必要はないと思われます。

パラメータ RTシリーズの選択肢 RTシリーズのコマンド
認証方式 pre-shared-key ipsec ike pre-shared-key
暗号アルゴリズム DES-CBC, 3DES-CBC ipsec ike encrypt (フェーズ1)
ipsec sa policy (フェーズ2)
ハッシュアルゴリズム MD5, SHA-1(SHA) ipsec ike hash (フェーズ1)
ipsec sa policy (フェーズ2)
PFSのon/off(有無) on, off ipsec ike pfs
DH(Diffie-Hellman)グループ 768bit(グループ1), 1024bit(グループ2) ipsec ike group
ISAKMP SAの寿命 秒寿命, バイト寿命 ipsec ike duration isakmp-sa
IPsec SAの寿命 秒寿命, バイト寿命 ipsec ike duration ipsec-sa
交換モード(exchange mode) main mode, aggressive mode, quick mode -
IDの種類 後述 ipsec ike local id
Vendor ID 受け付けない&送信しない -

3. 相互接続

3.1. 基本的なパラメータの設定

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の種類後述
Vendor ID送信しない

次に、pre-shared-keyの設定を行います。これは、両方の機器に同じ文字列、 またはバイナリ列を設定します。製品によっては、 どちらか一方しか設定できないものもあります。 RTシリーズでは、文字列の場合は32文字、 バイナリの場合は32バイトまでの長さが設定できます。

[設定例]

# ipsec ike pre-shared-key 1 text himitsu
# ipsec ike pre-shared-key 1 0x1234567890

3.2. IDの設定

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
          |                                                 ネットワーク
        端末 192.168.0.2

また、実装によっては、IDを交換しない方が良好に相互接続できるものがあります。 もし「IDを送信しない」という設定が可能な製品であれば、 RTシリーズでも送信しないように設定することができます。

RTシリーズでIDを設定するためには、ipsec ike local idコマンドと ipsec ike remote idコマンドを使います。 前者は自分側のIDを設定するコマンドで、 後者は相手側のIDを設定するコマンドです。 IDを送信しないときには、これらのコマンドを設定せず、 IDを送信するときには、両方のコマンドを設定します。 IDとして、タイプ1のIDを送信するときには、IPアドレスのみを設定し、 タイプ4のIDを送信するときには、ネットマスクを付加します。

[設定例]

# ipsec ike local(remote) id 1 clear ; 送信しないとき
# ipsec ike local(remote) id 1 192.168.0.2  ; タイプ1のIDを送信するとき
# ipsec ike local(remote) id 1 192.168.1.0/24 ; タイプ4のIDを送信するとき

3.3. 接続

一方の機器を始動側(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進数を出力します。

対向の製品についても、できる限りログを取るようにします。

4. トラブルシューティング

トラブルの種類は多岐に渡り、全てを網羅することが難しいので、 よくある問題について説明します。

4.1. 鍵交換の要求の拒否

始動側が鍵交換を開始したにもかかわらず、応答側がまったく反応しない場合で、 多くは応答側の設定の問題か、通信路の問題です。 応答側には、まったくログが出力されないか、 「鍵交換の要求が拒否された」というようなメッセージが出力されます。

鍵交換の相手を指定する設定を見直し、 ルータのIPアドレスが間違っていないことを確認します。 また、相手のルータに対してpingなどを送信し、 基本的な接続性があることを確認します。

4.2. 提案(proposal)の拒否

一方の機器が送信した提案が、他方の機器で受理されない場合です。 始動側と応答側はともに提案を送信するので、 両方の機器が相互に提案を受理しなければ、鍵交換は成立しません。 提案を拒否した機器のログには、 「提案(proposal)が選ばれなかった」 というような意味のメッセージが出力されます。 なお、提案を拒否された側の機器には、何のログも表示されないことがあるので、 注意が必要です。この場合には、単に再送を繰り返していることが多いと思われます。

この場合には、まず、パラメータの整合性を確認します。 3.で説明したパラメータについては、再確認が必要になります。 あるいは、他の値に変更することで解決できる可能性もあります。 例えば、IDとしてタイプ1を設定していたら、 これをタイプ4に変更したり、 IDの送信を止めてみます。 また、寿命の値や、PFSの値などを変更してみる価値もあります。 パラメータを変更するときには、両方の機器で同じように変更します。

4.3. 復号化(decryption)の失敗

復号化とは、暗号化(encryption)の逆で、 暗号化されたメッセージを元に戻すことです。 IKEのメッセージは、初めから数えて3番目以降については、 暗号化されます。 したがって、このメッセージを受信した機器は、 これを復号化する必要がありますが、 しばしば、復号化に失敗することがあります。

この現象は、判別と対策が難しいことが多く、面倒なものです。まず、 この現象の見分け方は、始動側において、 3番目に送信したメッセージが繰り返し再送されていることです。 このとき、応答側のログを見ると、 何らかのエラーメッセージが出ていると思われますので、それを確認します。 エラーメッセージの種類は様々であり、あまり特徴的なものはありません。 RTシリーズの場合には、 「フォーマットがおかしい」などの意味のメッセージが出力されます。

対策としては、pre-shared-keyの見直しをする必要があります。 特に長い鍵を設定しているときには、入力ミスの可能性があります。 それ以外には、実装に起因する場合が多いので、 ファームウェアを入れ替えない限り解決しないことが多いようです。

なお、アグレッシブモードを使う場合には、 ipsec ike payload typeコマンドで3を設定することで解決することがよくあります。

4.4. IDの拒否

相手の機器が送信したIDを受理できないことによって、鍵交換が失敗する場合です。 この現象が起きるのは、ほとんどフェーズ2で、 フェーズ1で起きることはあまりありません。 フェーズ2に入っていることを確認するためには、 ログを見るか、SAのリストを見ます。 ログが少ない機器でも、フェーズ1とフェーズ2が終了したときには、 ログを出力するのが普通で、フェーズ1が終了していれば、 1つのSAが生成されています。

対処としては、IDを送信しないように設定できる場合には、 送信しないことで回避できることがあります。なお、この文書では、 パラメータを揃えることを強調していますが、IDに関しては、 一方のみを送信しないように設定するだけですむことがあります。


IPsec機能のトップページへ

[関連ドキュメント]


※「戻る/進む」はブラウザの履歴が使用されます
[ RTpro / ヤマハ / 技術資料 / 設定例集 / RT's FAQ / マニュアル ]