|
Linux-eden >> 第3回 FreeS/WANのインストール |
|
- 解凍
root権限で、 FreeS/WANのソースファイルを /usr/src に解凍します。
|
$ su
# mv freeswan-1.99.tar.gz /usr/src
# cd /usr/src
# tar -zxvf freeswan-1.99.tar.gz
|
- FreeS/WANへのパッチ当て
FreeS/WANに当てるパッチを用意している場合は、このステップで当てます。
詳しい操作については、それぞれのパッチ提供者が提供しているかもしれません。
または、単純に patch コマンドを実行するだけでいいかもしれません。
当てない方はそのまま進みます。
- FreeS/WAN の Make とカーネルパッチ
RedHat8.0でマニュアル通りにやると、make 時に
***ERRORS DETECTED in out.kbuild (examine file for details):
make[4]: *** No rule to make target
`/usr/src/linux-2.4.18-18.7.x/drivers/pci/devlist.h', needed by
`names.o'. Stop.
make[3]: *** [first_rule] Error 2
make[2]: *** [_subdir_pci] Error 2
make[1]: *** [_dir_drivers] Error 2
というエラーが出ます。
正規の手順にはありませんが、これは、make 前に以下のコマンドを実行すれば回避できます。
# cd /usr/src/linux
# make dep && make modules |
これは、新しいカーネルのもたらす混乱かもしれないと思っています。
ひょっとすると、kernel 2.4以降を採用しているほかのRedHat系ディストリビューションでも出るエラーかもしれません。
日本語の資料が一切なかったので、初心者の方は make できてるのか不思議でしかたありません。それとも、こういう用途にはみなさんFreeBSDを使っているのでしょうか？
さて、やっと FreeS/WAN の make の準備が整いました。
FreeS/WANをカーネルモジュールとして make するならば、
# cd /usr/src/freeswan-1.99
# make oldmod
# make minstall |
とします。
# make oldmod 部分は、カーネルのコンフィグレーション手段に応じて、
# make menumod
でもいけます。
このケース（カーネルモジュールとして make）では、再起動しなくても、以下のコマンドでいきなりFreeS/WAN を起動できます。
再起動時は、自動的にIPSECサービスが起動します。
また、静的にカーネルに組み込むのであれば、
|
# cd /usr/src/freeswan-1.99
# make oldgo
# make kinstall
|
を実行し、システムを再起動してから、次項の手順で動作を確認しましょう。
なお、
# make oldgo
の部分は、カーネルのコンフィグレーションの手段に応じて他にも、
menuconfig を使用するなら make menugo
xconfig を使用するなら make xgo
config を使用するなら make ogo
などの方法が使用できます。
make Xgo | make Xmod 中のエラーは、freeS/WAN ソースディレクトリの out.kbuild に出力されます。
|
# ./utils/errcheck out.kbuild
|
を実行して、何も出力されなければ、make xxxgo | make xxxmod は成功しています。
- 動作確認
ipsec verify コマンドで動作の確認ができます。
以下のような結果が出れば、カーネルへの組み込みと、インストールが成功しています。
# ipsec verify
Cheking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking for pluto is running [OK]
DNS checks.
Looking for forward key for foo.bar.com [OK]
Looking for KEY in reverse map: nn.mm.oo.pp.in-addr.arpa [OK]
Does the machine have at least one non-private address [OK]
|
ここでOKが出ない場合は、その項目について、確認して再度、ipsec verify コマンドを実行してください。
ただし DNS の設定によっては、DNS Checks 以降は OK が出ないこともあるでしょうが、今回に関して言えば、そのままでも構いません。
|
余談：DNS checks で key のチェックが行われる理由
ふつう IPSec では、それぞれのVPNトンネル毎に管理者が設定を書かないといけません。
FreeS/WAN では、これを、DNS の TXT レコード、KEY レコードをうまく利用して不要にする方法を実装しています。
これは、「Opportunistic Encryption (OE)」と呼ばれており、特定の条件を満たしたお互い同士は、特に設定をしなくても、IPSec
によるセキュアな通信が可能になるというものです。
正直、流し読みしただけですので、合ってるかどうかは分かりませんが。。。。。不特定多数との通信において、経路上での盗聴・改ざんの防止と、完全性の保持までは行えるのではないかと思います。
ちょっと違いますが、まあ近いモデルとしては、HTTPS を挙げてもいいと思います。
技術的には、おそらく、DNS のレコードに公開鍵でも登録しているのでしょう。
ものすごい単純な発想なのに、なんかすごいなあ。と久しぶりに思いました。
あとは、DNS の KEY レコード発行を第３者の認証局が行うようになると、、、、とか考えてくと、かなり面白い未来が見えてきます。
IPv6時代が始まってから15年もすると、ひょっとすると、DNS認証を利用したレイヤー3個人認証と課金のフレームワークができてて、上位アプリケーションがその認証・課金フレームワークを使ってたりして・・・・・
これとP2Pとかがつながるとスゴイ世界になりそうですね。個人同士で、パケットを売り合うことができるようになるかもしれません。まだまだIT革命はこれからかもしれません。
おっと妄想が暴走してしまいました。本題に戻りましょう。
|
ここまでで、インストールは完了です。
次のページでは、IPSec のネットワーク的な特徴から、ファイアーウォール側で必要な設定について考えてみましょう。
 |
3/11
|
 |
|
|
|
Linux-eden へ
戻る
ひろもの国へ戻る
|
