Skip to main content.
Google custom search

NetBSD IPsec FAQ

このページは作成中ですので、 コメントや提案を歓迎します。

IPsec FAQ

他のリンク


IPsec FAQ

はじめましょう (トップ)

IPsec (IP security protocol) は、 NetBSD 配布物の一部として含まれており、 IPsecが提供するパケット毎の認証/機密性は、IPsecを使用して通信するpeer間通信を保護します。 IPsecは IPv6とIPv4で利用可能です。

しかしIPsecを使用するには、カーネルの再構成が必要であることに注意して下さい。 それはGENERICカーネルでは有効にはなっていません。

ユーザーランドにはIPsecサポートコードが含まれていますが、 IPsecをサポートするカーネルからサポートしていない カーネルに切り替えても、ユーザーランドの再コンパイルは必要ありません。

注意

私たちは、 IP security という用語は、 IP ファイアウォール、 パケットフィルタリングなどの、より広い概念で用います。

IPsec = AH + ESP + IPcomp + IKE (トップ)

IPsecは以下に挙げられる別々のプロトコルで成り立っています。

  • Authentication Header (AH): 強い暗号チェックサムをパケットに付加することによってパケットの信頼性を保証します。 AHのついたパケットを受け取りチェックサムが正常なら、 あなたとpeerが鍵を共有し他の誰もが鍵を知らないなら、 2つのことについて確信できるでしょう。
    • パケットはpeerによって作成され、パケットは偽造されていません。
    • パケットは転送中に変更されませんでした。
    他のプロトコルと異なり、AHは、IPヘッダーからパケットの終わりまで パケット全体をカバーします。
  • Encapsulating Security Payload (ESP): 暗号化アルゴリズムで暗号化されたパケットの機密性を保証します。 ESPでパケットを受け取って、解読に成功したなら パケットが途中で盗聴されていないと確信できるでしょう。 あなたとpeerが鍵を共有し、他の誰もが鍵を知らないなら。
  • IP payload compression (IPcomp): ESPがパケットに暗号化サービスを提供します。 しかし、暗号化は(ppp compressionのように)伝走路上の圧縮に打撃的な影響を与える傾向があります。 IPcompはESP(IPcompだけを使うことができる)によって暗号化を行う前にパケットを圧縮する方法を提供します。
  • Internet Key Exchange (IKE): これまで書いたように、AHとESPはpeerと鍵を共有することが必要となります。 遠い場所との通信のために、秘密裡に鍵を交渉する方法を提供する必要があります。 IKEはそれを可能にします。

AH、ESP、IPcompはカーネルに実装されています。 IKEはユーザーランドでデーモンプロセスとして実装されています。 カーネルとユーザーランドは、鍵管理テーブルを通して協調しています。

IKEはオプションです。AH/ESPのために手作業で鍵を構成することができます。 しかし、同じ鍵をずっと使い続けることはできないことを理解して下さい。 もし長い間同じ鍵を使うなら、トラフィックが危険にさらされる可能性がますます高くなります。

Note

IPsecプロトコルのセキュリティーは鍵の機密性如何です。 もし鍵が危険にさらされるなら、IPsecプロトコルは安全であり得ません。 設定ファイル、鍵データベースファイルのパーミッションあるいは情報漏洩につながるかも知れないさまざまなことに注意して下さい。

ふたつの RFC が出ています: RFC1825 による古い IPsec と、 RFC2401 による新しい IPsec です。 NetBSD ではいずれも実装していますが、新しい IPsec を使うよう推奨します。


        userland programs               IKE daemon
          ^ | AF_INET{,6} socket          ^ | PF_KEY socket
========= | | =========================== | | ======== Kernel/user boundary
          | v                             | v
        transport layer, TCP/UDP        key management table
          ^ |                             ^ | key information
          | |                             | |
          | v                             | v
        IP input/output logic <-------> AH/ESP/IPcomp logic
          ^ |
          | v
        Network drivers (ethernet)

トランスポートモードとトンネルモード (トップ)

AH, ESP そして IPcompにはトランスポートモードとトンネルモードの2つの操作モードがあります。 トランスポートモードは、通常のピア間の通信を暗号化します。 トンネルモードは、パケットを新しいIPv4/6ヘッダーの中にカプセル化します。 トンネルモードは、VPNゲートウェイで使用できるように設計されています。

[[トランスポートモード]]
my host ======== peer's host
        transport
        mode

packets: [IP: me->peer] ESP payload
                        <---------> encrypted


[[トンネルモード]]
        (a)                  (b)                        (c)
my host ---- my VPN gateway ======== peer's VPN gateway ---- peer's host
                            tunnel mode

packets on (a): [IP: me->peer] payload
packets on (b): [IP: mygw->peergw] ESP [IP: me->peer] payload
                                   <------------------------> encrypted
packets on (c): [IP: me->peer] payload

IPsecポリシー管理 (トップ)

カーネルはパケットをセキュアーにする方法を知っていますが どのパケットがセキュリティーを必要とするか知りません。 我々はどのパケットをセキュアーにするかをカーネルに示す必要があります。 IPsecポリシー設定によりそれらを指定します。

IPsecポリシーは、パケット毎またはソケット型毎に設定できます。

  • パケット毎: パケットフィルターと同じようにカーネルに設定できます。 10.1.1.0/24にメッセージを送っているなら、外向なパケットを暗号化してください というように指定することができます。 これは、IPsecルーターを走らせている時、うまく働きます。
  • ソケット毎: 特定のソケットに setsockopt(2) を使って設定します。 このソケットから外向なパケットを暗号化してくださいのように指定することができます。 これは、IPsec-awareサーバープログラムを走らせたい時、うまく働きます。

IPsecポリシーはパケットに対して使われるプロトコル(AH、ESPまたはIPcomp)を決定します。 パケットに対してAH、ESP、IPcompのどの組み合わせを使用するカーネルなのかを構成することができます。 ひとつのパケットに対して、多数のESPオペレーションのような、 同じプロトコルを複数回にわたって適用することができます。 多数のESPオペレーションが役に立つかどうかはわかりません。しかしテスト/デバッグには興味深いのですが。

IPsecカーネルの設定 (トップ)

作成手順の詳細はNetBSD-currentの追跡を参照して下さい。

  1. カーネル設定ファイルで次の部分を有効にして、新しいカーネルを構築してください。
    options IPSEC
    options IPSEC_ESP
    
  2. 新しいカーネルを構築します。
  3. カーネルを置き換えて、そしてリブートしてください。

ユーザーランドのツールはデフォルトで IPsec サポートを含んでおり、 また、ユーザーランドの再構築は不要です。

さらに、 NetBSD 附属の racoon(8) を使ったり、 security/isakmpd をインストールしたりするのもよいかもしれません。

設定例: ホスト間の暗号化 (トップ)

もしマニュアルで設定した鍵でホスト間の暗号化(トランスポートモード)を行うなら、 下記の構成で充分です。マニュアルで鍵を設定するために setkey(8) を 使用します。

#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use;
EOF

最初の2つの行は、ESPで使用する鍵を設定しています。 4番目の数字は SPI(セキュリティー・パラメーター・インデックス)と呼ばれています。 この値はESPパケットに付加され、受信した側でパケットから鍵を見つけるために送られます。 この値はノード上でユニークである必要があります。

  • 10.1.1.1から20.1.1.1に、鍵hogehogehogehogehogehogeで、 3DES-CBCアルゴリズムを使います。 トラフィックは SPI値9876によって識別されます。
  • 20.1.1.1から10.1.1.1に、鍵0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefで、 3DES-CBCアルゴリズムを使います。

最終行はノードのパケット毎のIPsecポリシーを設定しています。 この設定で、node(10.1.1.1)からpeer(20.1.1.1)に送られるパケットは暗号化されます。鍵はカーネル内部 で構成されます。 この設定は、20.1.1.1から10.1.1.1に届く暗号化されていないパケットを禁止していません。 もし暗号化されていないパケットを拒否したい場合、次の行を追加して下さい。

spdadd 20.1.1.1 10.1.1.1 any -P in ipsec esp/transport//require;

もう一方の (20.1.1.1) では、次のように設定します。 spdadd 行のアドレスを入れ換える必要がある一方、 add 行は入れ換えないことに注意してください。

#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 20.1.1.1, peer is on 10.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 20.1.1.1 10.1.1.1 any -P out ipsec esp/transport//use;
EOF

ポリシー設定の構文は ipsec_set_policy(3) で述べられています。

回線上の暗号化されたパケットを見るために tcpdump(8) を実行して下さい。 パケットは暗号化されます。それらのパケットを盗聴することはできません。

上記の例は人間が読むことができる鍵を使います。 しかしながら、人間が読むことができる鍵の使用がバイナリー鍵より危険であることから、 実際のオペレーションでは、バイナリー鍵を使用する方がいいでしょう。

鍵の長さはアルゴリズムによって決定されます。 3des-cbcでは、鍵は 192 ビット(=24バイト)でなければなりません。 もしそれより短いまたは長い鍵を指定するなら、 setkey(8) はエラーになるでしょう。

他のアルゴリズムを使う場合、設定はほとんど同じです。 rijndael-cbc (AES としても知られる) を使う場合の例を示します。 rijndael-cbc の秘密鍵は、 128、 192、または 256 ビットとなります。 ここでは、 128 ビットの鍵を使うことにします。

#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
# rijndael-cbc with 128bit key
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E rijndael-cbc "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E rijndael-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use;
EOF

設定例: ホスト間の認証 (トップ)

ESPと同じように、AHを設定することができます。

#! /bin/sh
#
# packet will look like this: IPv4 AH payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga";
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec ah/transport//use;
EOF

設定例: ホスト間の暗号化+認証 (トップ)

もしAHとESP双方で鍵を設定した場合、双方とも使うことができます。 IPsecのドキュメントでは、AHの後にESPを適用することを推奨しています 。

#! /bin/sh
#
# packet will look like this: IPv4 AH ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga";
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use ah/transport//use;
EOF

設定例: IPsec VPN (トップ)

まず最初に、いくつかのIPsec VPN設定に関しての注意点があります。

  • ルーティングの設定は的確に行われていなければなりません。
  • IPsecトンネルデバイスを、同時にNATボックスやフィルタリング防火壁として 振る舞うように使おうとしたりしないでください。 IPsecとNATは本質的に互換性のないプロトコルです。 また、1.5での実装と仕様の制限により、 これはうまく動きません。 我々はこの状況を改善しようとしているところです。詳細については、 "ipfilter との相互の影響" を参照してください。
  • VPNの設定は、それぞれの導入によって異なります。 実際、VPNの意味するものについての明確な定義はありません。 もしもメイリングリストに質問するとしたら、あなたの現在の状況と ネットワークの設定をすべて明らかにする必要があります。

以下の例は以下のようなネットワークの設定を仮定しています。 この例の最終目的は:

  • どうにかして二つのプライベートアドレス空間(10.0.1.0/24および10.0.2.0/24、 あなたの会社の東京支社とニューヨーク本社のようなものと考えてください) の中のマシンを接続すること。
  • 二つの空間の間のトラフィックは、 ゲートウェイ同士の間で安全にやりとりされる必要がある。
  • 太平洋を横断する専用線の料金を払いたくないため、地元のISP (東京とニューヨーク)と契約し、トラフィックはゲートウェイ間をトンネルする。
((( 10.0.1.0/24 )))     東京支店オフィスのVPNネットワーク
  |10.0.1.1
gateway 1
  |20.0.0.1
  |IPsec tunnel
  |20.0.0.2
gateway 2
  |10.0.2.1
((( 10.0.2.0/24 )))     ニューヨーク本社のVPNネットワーク

以下のテキストはgateway 1の設定を示します。

#! /bin/sh
#
# Note that routing should be set up in advance, i.e. for this example:
#       route -n add -net 10.0.2.0 10.0.2.1
#       route -n add 10.0.2.1 10.0.1.1
# packet will look like this: IPv4 ESP IPv4 payload
# the node is on 10.0.1.1/20.0.0.1, peer is on 10.0.2.1/20.0.0.2
setkey -c <<EOF
add 20.0.0.1 20.0.0.2 esp 13245 -E blowfish-cbc "blowfishtest.001" ;
add 20.0.0.2 20.0.0.1 esp 13246 -E blowfish-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec esp/tunnel/20.0.0.1-20.0.0.2/require ;
spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec esp/tunnel/20.0.0.2-20.0.0.1/require ;
EOF

(この項は Per Harald Myrvang の寄贈によるものです)

設定例: 葉ノードトンネル (トップ)

トンネルモードは、ある葉ノードからの全トラフィックを次ホップのルーターまで 暗号化し、逆にルーターからのトラフィックは平文化する、 という状況で使うことができます (たとえば、 802.11 WEP では不十分なので、 ワイヤレスノードからルーターまでの間で使うなど) 。

葉ノードでは、以下のように使います:

#! /bin/sh
#
# the node is on 10.0.1.5, router is on 10.0.1.1
setkey -c <<EOF
add 10.0.1.1 10.0.1.5 esp 1011 -E rijndael-cbc "rijndaeltest.001" ;
add 10.0.1.5 10.0.1.1 esp 1012 -E rijndael-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.0.1.5/32 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.1.5-10.0.1.1/require;
spdadd 0.0.0.0/0 10.0.1.5/32 any -P in ipsec esp/tunnel/10.0.1.1-10.0.1.5/require;
EOF

ルーターでは、 spdadd コマンドの outin を逆にします。

IKEによるAH/ESP鍵の設定 (トップ)

まずは下記の設定について説明します:

  • ノード A と B はトランスポートモード ESP を使う。
  • 両端では、すべてのプロトコルについてパケット交換に ESP を使う必要がある。
  • IKE による間は、ノード A と B は、共有された秘密鍵の交換によって、 お互いに認証し合う。

どうか慎重に下記の手順をふんでください。 tcpdump(8) を使い、 2 ノード間でどのようにパケットが交換されているか調べます。 netstat -sn による統計情報も、 カーネルの IPsec 部がどのように動作しているか知るために有用です。

  1. /usr/share/examples/racoon/racoon.conf.sample/etc/racoon/racoon.conf にコピーします。 必要に応じて racoon.conf 中のパラメーターを修正します。 両端で同一の設定を使うことが、 *非常に* 重要です - 両者の racoon.conf の差異がないようにしなければいけません。
  2. racoon は、 IPsec 鍵の交渉をする際、カーネルの IPsec ポリシーの設定に従います。 したがって、 setkey(8) を使い、カーネルの IPsec ポリシーを 設定しなければなりません。 ノード A での IPsec ポリシーの設定は次のようになります。 この例において、 AB は IPv4/v6 の数字アドレスです。
    A# setkey -c
    spdadd A B any -P out ipsec esp/transport//require;
    spdadd B A any -P in ipsec esp/transport//require;
    ^D
    
  3. ノード B での setkey(8) を使った IPsec ポリシーの設定は次のようになります:
    B# setkey -c
    spdadd B A any -P out ipsec esp/transport//require;
    spdadd A B any -P in ipsec esp/transport//require;
    ^D
    
  4. 両ノードにおいて、あらかじめ共有された鍵ファイルを用意します。 ファイルのパーミッションを適切に設定することが 非常に 重要です。さもなければ IPsec を使う意味がありません - CPU 時間を 無駄に使うだけになってしまいます (racoon(8) は、不適切なパーミッションを持つファイルは 読み込みません) 。 繰り返しますが、 AB は IPv4/v6 の数字アドレスです。
    A# cat >/etc/racoon/psk.txt
    B       spamspamspam
    ^D
    A# chmod 600 /etc/racoon/psk.txt
    
    B# cat >/etc/racoon/psk.txt
    A       spamspamspam
    ^D
    B# chmod 600 /etc/racoon/psk.txt
    
  5. racoon を実行します。 デバッグトレースを見たい場合は、下記のような引数を取ります:
    # racoon -f /etc/racoon/racoon.conf -dddddd
    
  6. A と B の間でパケットを交換してみてください。 racoon のメッセージがコンソールに出て、 鍵が確立されます。
    A# ping -n B
    (しばらくしてから、応答が見られるでしょう)
    ^C
    A# setkey -D
    (racoon で交換された鍵が見られるでしょう)
    

racoon は、ポリシー定義に基づいて鍵を交渉します。 ポリシー定義を変更することで、これ以外のケースに対しても容易に設定できます。 次の例は、下記の状況向けに鍵を設定するものです:

  • A はメールサーバー。 A は、 A に POP プロトコル (TCP ポート 110) で接触する すべてのクライアントに、トランスポートモード AH を使わせたい。 B は、 A と接触したいクライアント。
    1. A でのポリシー設定は、ローカルトラフィックに対しては AH を使いません (racoon は自分自身とは鍵の交渉をできないことに注意)。 ポリシーの順序はたいへん重要です。 この順序を変えると、この設定は機能しなくなるでしょう。
      A# setkey -c
      spdadd A[110] A tcp -P out none;
      spdadd A A[110] tcp -P in none;
      spdadd A[110] 0.0.0.0/0 tcp -P out ipsec ah/transport//require;
      spdadd 0.0.0.0/0 A[110] tcp -P in ipsec ah/transport//require;
      ^D
      
      B# setkey -c
      spdadd B A[110] tcp -P out ipsec ah/transport//require;
      spdadd A[110] B tcp -P in ipsec ah/transport//require;
      ^D
      
    2. ポリシー設定以外の部分は、前の例と同様に設定します。

設定するうえでなにか問題があったら、フルデバッグログ (racoon -dddddd) をしっかり見て、どこが原因か調べてください。 いかなる設定の違いも、交渉の失敗につながります。

ブート過程で IPsec 手動鍵とポリシーを設定する (トップ)

rc.conf(5) には、 ipsec という IPsec 用のエントリーがあります。 ipsec=YES とすると、ブート時に、すべてのネットワークが有効になってから 次のコマンドを実行します:

/sbin/setkey -f /etc/ipsec.conf

たとえば、 /usr を暗号化して NFS マウントすることができます。 /etc/ipsec.conf の内容は、正当な setkey(8) コマンドでなければ なりません; 上記の設定例から、 setkey -c <<EOFEOF の部分を除いた部分のようにします。

ipfilter との相互の影響 (トップ)

NetBSD は、 Darren Reed による ipfilter、 ipf(4) を実装しています。 ipf(4) はパケットをふるいにかけ、また、 IPsec ポリシーの作用は本質的に パケットフィルターと同じものです。 したがって、これらの実装は機能的に衝突します。 ipf(4)/IPsec 相互の影響は、以下のとおりとなっています: ipf(4) は、ネイティブのワイヤーフォーマットのパケットのみを監視します。 ipf(4) は、入ってくるパケットは IPsec の処理前のものを、 出てゆくパケットは IPsec の処理後のものを監視します。

この処理順序のもとでも、以下のことを知っておいてください:

  • IPsec パケットに ipf(4) を通過させたくても、これを ipf(4) ルールから 外すべきではありません。 IP パケットに適切な通過プロトコル番号 (ESP は 50、 AH は 51) を振る必要があります。

    注意

    プロトコル番号は、 TCP/UDP ポート番号とはまったくの別物です。

  • トンネルデバイス (gif(4) および ipip(4)) から来るパケットは、依然として ipf(4) を通過します。 これらのパケットには、 ipf.conf(5) でインターフェース名ディレクティブを 使って見分けるようにする必要があるかもしれません。

処理順序 (トップ)

下記の図は、受信側の新しい処理順序をまとめたものです。

入ってくる場合の処理:
        userland programs               IKE daemon
          ^ AF_INET{,6} socket            ^ | PF_KEY socket
========= | ============================= | | ======== Kernel/user boundary
          |                               | v
        transport layer, TCP/UDP        key management table
          ^                               ^ | key information
          |                               | |
          |                               | v
  +-----IP input/output logic <-------> AH/ESP/IPcomp logic
  v       ^          ^                      |
tunnel    |          +----------------------+ decapsulated IPsec packets
devices   |
  |     ipfilter rule
  |       ^
  +------>|
          |
        Network drivers (ethernet)

下記の図は、送信側の新しい処理順序をまとめたものです。

出てゆく場合の処理:
        userland programs               IKE daemon
            | AF_INET{,6} socket          ^ | PF_KEY socket
=========== | =========================== | | ======== Kernel/user boundary
            v                             | v
        transport layer, TCP/UDP        key management table
            |                             ^ | key information
            |                             | |
            v                             | v
  +---->IP input/output logic <-------> AH/ESP/IPcomp logic
  |         |                           (incl. IPsec tunnel encapsulation)
tunnel      |
devices     |
  |     ipfilter rules
  |         |
  +---------+
            v
        Network drivers (ethernet)

ありがちな落とし穴と、デバッグの技巧 (トップ)

  • 下記の三つのものを混同している人たちがいます。 他の実装との相互運用をしようとする場合には、これらを混同しないよう注意してください。 もしこれらを混同していたら、相互運用の設定など永遠に できないでしょう。 ドキュメンテーションでも、これらを間違った用語で使っていることがあります (はあ…) 。
    • IPsec with manual key (手動鍵による IPsec)
      NetBSD の場合、この方法は、 IPsec 秘密鍵の設定に setkey(8) を使います。 IPsec 秘密鍵は時間が経っても変更されません。
    • IPsec with IKE, with pre-shared secret (あらかじめ決めた文字列を使った IKE による IPsec)
      NetBSD の場合、これは racoon(8) を使います。 あらかじめ決めた文字列によって通信相手との認証をします。 racoon(8) は IPsec 鍵を動的に交渉して、 それをカーネルインストールします。 IPsec 秘密鍵は定期的に変更されます。
    • IPsec with IKE, with certificates (証明書を使った IKE による IPsec)
      NetBSD の場合、これは racoon(8) を使います。 証明書ファイルによって通信相手との認証をします。 racoon(8) は IPsec 鍵を動的に交渉して、 それをカーネルインストールします。 IPsec 秘密鍵は定期的に変更されます。
  • IPsec の設定は、 *容易なものではありません* 。 うまく使うためには多くの障害がありますし、 IPsec のもつ盗聴への 対抗性ゆえにデバッグは非常に難しいものです。パケットトレースをもとに 何が起きているか推測することは、基本的にできません。 設定しようとする前に、本や標準文書/RFC を読むなり、コンサルタントを 雇うなり何なりするようにしてください。
  • ネットワークのデバッグには、常に tcpdump を走らせます。 たとえトラフィックが暗号化されていても、パケットが実際に経路上に あるかどうかの情報は得られるでしょう。
  • netstat(1) はあなたの味方です。 netstat -sn を実行して IPsec パケットの数を確認します。
  • racoon(8) の実行で問題があったら、最大限の デバッグ出力をするようにして実行し、その出力を見てください。 (コマンドライン引数 -dddddd)
  • あなたの NetBSD デバイスは、通信相手のデバイスとの相互運用のため、 間違いなく本当に厳密に同一に設定する必要があります。 パケットは、相手方が期待しているものと厳密に同一のプロトコルと 暗号化アルゴリズムによって生成されなければなりません。 これができていないと、追跡することが非常に難しいエラーに見舞われます。 IPsec においては、暗号化/認証の失敗はパケットの欠落として現れます。 このため、設定を失敗すると、パケットがエラー表示を伴わずに 消えてなくなることになります。 このパケットの内容は、すでに解読不能になっているので、 tcpdump(8) はたいして役に立ちません。 他の相手方を伴う設定は、くれぐれも慎重にするようにしてください。
  • IKE 交渉は net.key.larval_lifetime sysctl MIB (デフォルトでは 30 秒) の範囲内で完了しなければならないため、 遅いマシンでは鍵の交渉ができないかもしれません。 本当に遅いマシンをお使いなら、この変数値を増やしてみてください。

既知の問題 (トップ)

  • カーネル IPsec ポリシーエンジンの制限のため、トンネルモード AH は、期待通りには動作しません。 トンネルモード AH は使わないようにしてください。
  • IPsec と ipf(4) のコードは、うまく協調しません。 詳細は "ipfilter との相互の影響" を参照してください。
  • IPsec ポリシールールは、 tcp/udp 以外のプロトコル仕様に対しては 十分テストされていません。安全側を取る場合にはプロトコル any (= アドレスマッチのみ) を使ってください。この問題は、すべての パケットフィルター一般についていえるものです - 通常のパケットフィルター 記述は、ヘッダーチェインに関してうまくふるまいません。

標準化、互換性への適合 (トップ)

KAMEのIPsecの実装(NetBSDツリーに含められる)が、最新のIPsec標準に適合しています。 KAME の NetBSD 実装ノート には、実装するための包括的な標準化文書があります。

他の実装との互換性が、さまざまな場所で確認されました。 KAME の NetBSD 実装ノート に含まれる実装は、過去に互換性は確認されたものです。 しかし、互換性のテスト後にコードは変更される可能性がありますので、互換性がなくなっている可能性もありますので注意して下さい。 NetBSDデバイスとpeerデバイスがある特定の構成のみで互換性をとることも可能です。

もし他の実装でNetBSDデバイスを設定する場合、そのIPsecの仕様/実装には多くの難点があることに注意してください。 互換性を取るためにはpeerのデバイスと同じデバイスでNetBSDデバイスの構成を設定する必要があります。

他のIPsecスタックとのAPI互換性 (トップ)

IPsecの知識がありユーザーランドのコードを書きたいなら、あなたはIPsecプラットフォーム間のAPI互換性について知りたくなるでしょう。

我々はカーネル内に鍵データベースを操作するために RFC2367 PF_KEY APIを持っています。 このAPIの基本的な部分は他のUNIXベースのIPsecスタック上で利用可能であり、そしてある程度(例えば、OpenBSDが同様にPF_KEY APIを実行する)の互換性があるかも知れません。 かめIPsecスタックが、他のグループがそうするのと同じように、ある特定の方法でこれを拡張します。 拡張された部分は他の(非かめ)IPsecスタックと両立できません。

IPsecポリシー管理APIの仕様書ドキュメントはありません。 それ故に、IPsecポリシー管理APIで(非かめ)IPsecスタックとの互換性を想定することができません。

設定ファイルの書式の標準がありません。 NetBSD 以外の IPsec デバイスとの間で設定をコピーしたい場合は、設定ファイルの書式を変換する必要があるでしょう。

NetBSDとFreeBSDは同じ原点(かめ)からIPsecコードベースを共有するため、API互換性があります。 しかしながら、異なった日付のかめコードをマージした時点で、NetBSDとFreeBSDのIPsecコードには違いが生じます。 標準的なユーザーランドアプリケーションがその違いを認識する必要はありません。 ただし、 IPsec key management daemons の実装をするのであれば、 PF_KEY API の差異を考慮する必要があるでしょう。

  • NetBSD 1.5 は2000年6月初旬にかめIPsecスタックを取り込んでいます。
  • FreeBSD 4.0-RELEASE は1999年12月初旬にかめIPsecスタックを取り込んでいます。
  • マニュアルでのipsec鍵設定、 AH/ESPオペレーションまたは ipsec_set_policy(3) APIはカーネルにおける相違はありません。
  • PF_KEYソケット、libipsec API、PF_KEYラッパー関数などには違いがあります。 直接PF_KEYソケットを操作する (racoon(8) のようなIKEデーモンや setkey(8)のような鍵設定プログラム) アプリケーションを実装する際に、その違いは辛いかもしれません。

NetBSD 1.4 から 1.5 までの NetBSD-current の開発において、 KAME の IPsec 部分を 3 度にわたって導入しました。 この導入には、後方非互換な API の変更を含んでいます。 1.4 から 1.5 までの NetBSD-current を使う場合は、 それが最新のコードを使っているか確認してください。 NetBSD 1.5 では、 NetBSD 1.5 で提供される API について、 完全なバイナリー互換または API バージョンチェックを実現する予定です。

書籍その他の読みものは ? (トップ)

文字どおり、山ほどの書籍が出ています。


他のリンク

雑多なリンク (トップ)


Back to NetBSD ドキュメンテーション: ネットワーク