えーと、タイトルは単にちょっとかましたかっただけで、ほとんどギャグです。本気にして「俺もこいつもあいつも使っているぞ！」とか教えてくれなくても結構です。但し、文中に当方の理解不足による間違った記述が散在している可能性が大いにありますので、気付かれた方は筆者にメールでご教示いただけると助かります。またこの文章は IPsec のインストール・運用のガイドを目指したものではありません。文中に有用な文章へのリンクをいくつかはっていますので、詳細はそちらを参照ください。
少し前に Red Hat Linux 7.2 マシンを NAT ルータにし、同時に IPsec セキュリティゲートウェイにする機会があった。IPsec は FreeBSD でいろいろ試していたが、Linux 上での運用経験はなかった。ご存知の通り FreeBSD の IPsec スタックは KAME プロジェクトの成果物であり、デフォルトでは IPsec 機能はオフになっているものの、既に OS に取りこまれているので導入は比較的容易だった。自動鍵交換（IKE）を使わないなら、root になって setkey 数発で IPsec 通信を行えるのに少し感激した覚えがある。
Linux における IPsec スタックが FreeS/WAN プロジェクトによって作られていることは知っていた。そこからダウンロードする前に、FreeS/WAN について日本語で詳述しているページはないかなと探してみたのだが、思ったよりも少なかった。例えば後で取り上げる文章には、以下のような記述がある。
FreeS/WANは日本ではまだ利用者はほとんどいない？らしく、それについて解説したページはGoogleで検索しても２ページほどしか見つかりませんでした(2001年9月現在）。
利用者が多くない原因となると、IPsec 自体の問題と FreeS/WAN 側の問題を分けて考える必要があるだろう。
前者についてだが、まずお断りしておかないといけないのは、完全なセキュリティプロトコルというものは存在しないということである。それぞれ一長一短があり、利用者の事情に応じて適切に使い分けたり組み合わせればよいのである。以上の前提を踏まえた（予防線を張った）上で、特に問題なのは、
の二つだと思う。「NAT 技術との噛みの悪さ」についてはよく言われることである。現状プロバイダに直接パソコンをつなぐというのでもなければ、IP マスカレードなどの NAT の利用は必須といってよい。NAT 技術の問題についてもいろいろ言われているので改めてここに書く必要はないが、内部ネットワークの端末を隠蔽し、外部からの通信開始を防ぐというセキュリティ上の効用（と呼べるのかも疑問があるが）をもたらす NAT 技術が、IPsec というセキュリティプロトコルの導入を阻害するのは皮肉である。もちろん端末同士で直に VPN を張るトランスポート・モードもあるが、元々はセキュリティ・ゲートウェイ（≒ルータ）同士で VPN を張り、安全な LAN 間通信を行うトンネル・モードを主としている気配がある。それにケチがつくとなると致命的だ。
しかし話が前後するが、Linux においてはこれはそれほど深刻な問題ではない。始めに書いたように、筆者は Red Hat Linux 7.2 マシンを iptables で NAT ルータにし、同時に IPsec セキュリティゲートウェイとして利用している。iptables の FORWARD ルールポリシーが ACCEPT ならば、特に iptables 側に余計なチェーンを加えることなく NAT と IPsec VPN は共存可能である。
また、組織の外からの攻撃だけでなく内部からの攻撃にも注意しなければならないという意識が大分広まりつつあるが、その場合例えば LAN 内でも主要なサーバとの通信をすべて暗号化するといったニーズは出るはずで、その場合 IPsec トランスポート・モードの利用が広がるとも思うのだが。
あまり言われないことであるが、IPsec という技術の「目に見えにくさ」のほうが実は大きな問題なのかもしれない。
例えばメールを暗号化する必要があれば PGP を使うだろう。ウェブ上で商売をやり、顧客の情報を入力してもらうページは SSL で安全性を確保するだろう。このように、セキュリティソリューションは具体的なアプリケーションと結びついていたほうが利用者にとって分かりやすい。IPsec には残念ながらそれがない。
しかし、はっきりいってこれは言いがかりである。IPsec は先に挙げたプロトコルより低いネットワーク層（IP層）でセキュリティを実現するプロトコルなのだから。ただ汎用性があり自由度が高い分、セキュリティポリシーを決めるところから必要になるため設定が複雑になりやすくもあるということは、racoon（KAME の IKE デーモン）の作者である坂根昌一さんによる「IPsecはどこに行く」にも触れられている。
また2000年の Internet Week の 6Bone-JP BOF において坂根さんは「毎日使おうIPsec」で SSH を比較対象としているが、現状では汎用性と具体性をうまく両立できている SSH に全然負けているように思う。そういえばこの発表の後の質疑の時間に、「結局 IPsec 何に使ってる？」と itojun さんと kazu さんという二大巨頭が顔を見合わせる瞬間があったっけ。
それでは FreeS/WAN 固有の問題となると何があるのだろうか。
まずはインストールの難しさがある。これは僕自身が特に苦労したのでそう思うのだろうが、カーネルの再構築まで必要になるものなので、普通のアプリケーションのようには簡単にはいかない。IKE は別にしても、IPsec 本体は *BSD のようにカーネル組み込み済みならばなあとは思う。
ただ状況は変わりつつある。僕が FreeS/WAN 関連のドキュメントを探すのを待っていたかのように（そんなわけないって）、@IT において宮本久仁男さんが FreeS/WAN の導入に関する「FreeS/WANによるIPSecの導入と運用」という文章を書かれている（前編、後編）。
宮本さん（wakatono さん、と書いたほうが良いのかな？）が書かれる文章は一貫して高品質で安定感があり、技術の本質をとらえながら細部への目配りも的確なので安心して読むことができる。また氏は上にリンクを示した文章の後も、FreeS/WAN と他の IPsec スタックとの相互接続について連載を続けているので、まだ読んだことがなく IPsec に興味のある方は、ワタシの駄文など読んでいる暇があったらそちらを先に読みたまえ（何故か偉そうに書いてみる）。
また IPsec 関係の RFC 日本語訳を数多く手がけられてきた馬場達也さんによる『マスタリングIPsec』という翻訳本以外では初の決定版と言える書籍も出ている。
さてその文章・書籍を参照し、FreeS/WAN（バージョンは1.95）のインストールはうまく………いかなかった。残念なことに。
宮本さんの丁寧な文章でも十全でないところに FreeS/WAN のインストールの難しさがある。僕が対象にした Red Hat Linux 7.x 系では、/usr/src/linux というシンボリックリンクが標準ではできない（そのかわりに /usr/src/linux-2.4 がある）…程度で詰まる人は FreeS/WAN のインストールなどやるべきではないのだが、その他にも Red Hat 7.x だと最初に make mrproper を叩いてカーネルの環境設定をデフォルトに戻しておく必要があるし、これは FreeS/WAN の問題ではなく Red Hat 側の問題だと思うが、/sbin/kernelinstall スクリプトの最後に LILO 前提の記述があるため、ブートローダに GRUB（がデフォルトだと思うんだけど…）を使っているとカーネルの再構築に失敗したように見えるという罠もあった。
当方は Red Hat Linux 7.2 以外の環境でインストールを行ってないので、これがVine Linux など他の Red Hat 系ディストリビューションにも当てはまる話かは分からない。また、馬場さんのほうにはワタシが連絡したので、『マスタリングIPsec』のサポートページにそのことについて記述が入っている。馬場さんの場合、最新版のカーネルソースに適用したので上の問題が顕在化しなかったとのことで、普通はまあそうしますわな（当方は事情があって Red Hat をインストール時のカーネルに FreeS/WAN を入れなければならなかった）。
make mrproper の件は、「FreeS/WANによるIPSECサーバの構築」という文章で知った。冒頭で引用した文章もここからのもので、Red Hat Linux の NAT ルータに FreeS/WAN をインストールしてセキュリティ・ゲートウェイにするという当方の要件にジャストミートするこの文章には特にお世話になった。この場を借りて特にお礼を言いたい。余談であるが、このサイトの作者はかの『時計じかけのオレンジ』の失われた最終章の翻訳などもなされていて、なかなかの才人とお見受けする。
それに実は、僕が上に挙げた問題は、FreeS/WAN 付属のドキュメントを探せばほとんどすべて対処法が載っていることである。フリーソフトウェアのドキュメンテーションについてはいろいろ言われるが、FreeS/WAN はその点間違いなく優等生といえる。というか、はっきりいって圧巻といえる量で、これだけで FreeS/WAN 単体に留まらず、IPsec 自体の教科書にもなるくらいだ。そしてこの優秀さが日本における FreeS/WAN 普及の妨げになってきたとワタシは思うのだ。
優れたドキュメンテーションが普及の妨げになったと書くと頭がおかしいのでは思われるかもしれないが、「日本における」というのがポイントである。
例えば LDP を見ても、IPsec（FreeS/WAN）を中心的に扱った HOWTO 文書は存在しない（結果、JF で翻訳されない）。これは付属ドキュメントが膨大なため、改めてスタートアップ用 HOWTO を書こうと誰も思わないからではないだろうか。ワタシのように英語のドキュメントに対する抵抗感が比較的小さい人間でも、この膨大さを前にすると「引いて」しまうところがある。せめて FreeS/WAN FAQ だけでも JF に翻訳があればと思う。言いだしっぺの法則を適用すればワタシがやらにゃならんのだが…時間が取れない…こんな駄文を書く時間ならあるのだが（後記：上で紹介した文章の作者でもある abuyon 氏による日本語訳が公開されている！）。
あと折角の機会なので FreeS/WAN の設定面についての不満も書いておこう。FreeS/WAN の設定を行う場合、VPN 通信を行う二点間を絵に描き、左と右に分けて設定を行うのだが、このコンセプト自体が個人的には謎である。つまり、ワタシが IPsec 通信の片方の当事者だとしたら、「右、左」という考え方ではなく「おれっちの LAN（or 端末）とてめえのとこの LAN（or 端末）」という考え方をするのが自然だと思うのだが。自分側と相手側とでどちらを左（右）として考えるのかを合わせておかないといけない…とものの本には書いてあったりするのだが、それが絶対かというと実はそうでもなく、自分側のネットワーク設定を右としようが左としようが、FreeS/WANのほうで自動的に検出してくれる（はずだ）。それなら尚更「俺、お前」モデルのほうが直感的に理解しやすい上に厳密に適用できると思うのだが。
あとトンネルモードを利用する場合、設定項目にセキュリティ・ゲートウェイの一つ上位のゲートウェイのアドレスがあるのも謎としか言いようがない。何ゆえ通常のルーティング処理にまかせられないのか。
また標準で DES など弱い暗号アルゴリズムを利用できないというのも、事前に知らないと相互接続しようとしてハマるポイントだろう。現在大抵の IPsec 製品で DES だけでなく 3DES もサポートしているのでそちらは問題ないのだが、IKE における Oakley グループ1がサポートされないというのはちょっと厳しいと思う。
当然ながら元々そういうプロジェクトの方針なのだから仕方ないとも言えるのだが、DES-CBC にしろ Oakley グループ1にしろ IPsec/IKE の RFC で実装 MUST の技術なのだよね…。現在の IPsec の仕様を定めた RFC が公開された1998年末の時点で、既に DES は安全な暗号アルゴリズムでなくなっていたはずだが、このように仕様と現実の実装とでは禿離、もとい乖離が生じてしまっている。
FreeS/WAN をインストールした後だが、CENTURY SYSTEMS 製の IP ルータ XR-300 と対向で LAN 間 VPN 通信を行っている。この製品のページを見れば分かる通り、この製品自体 OS は Linux で、IPsec スタックは FreeS/WAN なので相互接続の問題はなく、その後の運用では大した問題は起こっていない。
XR-300 ではなくこっち側の設定の問題として、man /etc/ipsec.conf の記述と異なり IKE のデフォルトの認証方式が事前鍵共有方式でなく RSA 鍵交換になってるぞゴルァとか、同じく man /etc/ipsec.conf には IPsec-SA の有効期限の上限（24時間）についての記述はあるが、下限についての記述がなく、どんどんこの値を短くしていって途中から挙動がおかしくなったかと思ったぞウリャとかあったが、後者についてはそんなことして遊ぶほうがイカンのである（18分が下限らしい）。
さてここからは FreeS/WAN、並びに IPsec からは話が逸れるのだが、以前から気になったいたことを書いておく。
XR-300 を使っていて、CENTURY SYSTEMS のほうで FreeS/WAN に何か手を加えているのだろうかというのが気になった。Linux カーネルはもちろんのこと FreeS/WAN のライセンスも GNU GPL なので、購入者であるワタシは GPL 部分ソースコードの公開を要求できるはずである。早速 CENTURY SYSTEMS のサポートにメールを出したのだが、待てども待てども返事が来ない。仕方なく電話して尋ねたところ、カーネル部分については同じく Linux をターゲットにした MA-300 のソースコードを公開しており、それとほぼ同じだからそっちを参照してくれとのこと。しかし、ワタシが見たいのはアプリケーション周りなんだよね、そっちも GPL 部分は公開するんだよねと粘ると、はい近いうちに公開予定ですとの回答であった。
で、その電話のやり取りから数ヶ月経ったが、未だ公開される気配はない。こっちとしても死ぬほど見たいとかいうのでないからそれ以上のアクションを起こすつもりもないが、大体製品として出荷しているもののソースコードなのだからちゃんとまとめられているはずであるし、公開するだけなら一日もあれば可能なはずだ。これはまあ、そういうつもりなのだと判断するより他はない。
しかし、CENTURY SYSTEMS はカーネル部分やハードディスクイメージなどをちゃんと公開しているだけまだ良心的といえる。組みこみ分野における Linux の導入も各所で進んでいるが、自分達が Linux を使っていることすら公表しないところだってある。
この文章を書くために普段見ない２ちゃんねるのハード板をチェックしたところ既に指摘されていたので、ワタシが書かなくても知っている人は多いだろうと判断して実名を挙げるが、例えばメルコのブロードバンドルータ BLR3-TX4 がそうである。これの OS は Montavista の Hard Hat Linux 2.0 なのだが、サポートページやマニュアルを見ても、どこにも Linux を使っているという記述がない（もしあるなら当方の見落としですので、謝罪して訂正します）。つまり CENTURY SYSTEMS の場合と異なり、製品購入者がその製品のソースコードを要求できることすら知らされないわけだ。これって GNU GPL 的にオッケー…なわけないと思うのだが現実問題どうなのだろう。