HOME FreeS/WAN

Linux FreeS/WANによるIPSECサーバの構築

IPSEC(Internet Protocol SECurity)はIETFで検討中の暗号化に関するプロトコルです。IP層のデータグラムレベルで暗号化が行われるため、既存のTCP/IPアプリケーションの通信を暗号化することができます。

Linux FreeS/WANはGNU/Linuxで動作する、IPSECプロトコルを実装したソフトウェアの名称です。FreeのSecure な WAN(Wide Area Network)を実現する、という意味が込められています。

FreeS/WANを利用すると、本社と支店、会社と自宅などをVPN(Virtual Private Network)で結ぶことができます。

FreeS/WANは日本ではまだ利用者はほとんどいない?らしく、それについて解説したページはGoogleで検索しても2ページほどしか見つかりませんでした(2001年9月現在)。FreeS/WANには(英文ですが)非常に丁寧なドキュメントが付属しており、glossary 一つをとっても、素晴らしい出来です(いつか全部訳してみたい...→訳してみました)。他にもFreeS/WANのコンセプトや暗号化に関する歴史(エニグマの話など)も載っており、プライバシーやセキュリティ意識に関しても読むべきところの多い文書となっていますので、ぜひ一読をお奨めします。

ここではこのマニュアルを元に、FreeS/WANのインストールやコンフィグレーションを行う上で気づいた点や補足などを記載してあります。勘違いなどあるかもしれませんが、その際はご指摘いただければ幸いです。

予備知識

FreeS/WANを利用する上で知っておきたい単語や注意事項です。

Security Gateway
FreeS/WANはVPN間でSecurity Gateway(SG)として動作します。つまり、VPNで接続したい環境それぞれにFreeS/WANがインストールされたマシンがゲートウェイになることで動作します。

Routable IP address
一言で言えば、グローバルIPアドレスと同じです。世界でユニークなIPアドレスになります。下記のNon-routable IP address も参照して下さい。

Non-routable IP address
プライベートなネットワーク(社内LANなど)で使用するべきIPアドレスです。利用可能なアドレスの範囲は のいずれかとなっています。このIPアドレスがInternetに流れることはありません(流そうと思ってもルータで捨てられます)。案外これを知らない人が多く、メイルヘッダなどを見ると社内で 100.0.0.1 などのアドレスを使用している会社をちょくちょく見かけます。ちょっと恥ずかしいです。

サブネット(subnet)
論理的に1つのネットワークと見なすIPアドレスのグループです。サブネットの範囲はサブネットマスクによって指定します。サブネットマスクは
10.0.0.0/24
10.0.0.0/255.255.255.0
などと記述することができます(上記は同じ意味)。FreeS/WANでは、VPNの向こう側(つまりプライベートなネットワーク側)をサブネットと呼んでいます。このサブネットは Non-routable IP address にするべきです。

サブネットは変えておく
VPNは、互いのプライベートなネットワークを接続するわけですから、お互いを区別する必要があります。これは、VPN先のそれぞれのサブネットを相手とは違う範囲に設定する必要があるということです。例えば、192.168.0.0/24 と 192.168.1.0/24 などに設定します。

SG間ではping不可
FreeS/WANはSGの間の通信を暗号化します。これは「トンネリング」と呼ばれます。トンネルの向こう側はすなわちサブネットに相当するわけですが、SGと相手側のサブネットで通信することはできません。FreeS/WANの動作確認にはping を利用しますが、SGからサブネットに直接ping を打つことはできません。それを行う場合、トンネリングを複数設定する(SG <---> サブネットのトンネルを設定する)必要があります。これはマルチトンネル(multi tunnel)と呼ばれます。

IPSECクライアントソフト
本店と支店など、それぞれSGが固定で設置された環境の場合、互いにFreeS/WANをインストールすればことは足りますが、出先からノートPCなどでSG経由社内ネットワークに入りたい場合もあるでしょう。この場合、ノートPCにGNU/Linuxをインストールしている強者はいいのですが、Windowsなどの場合、SGとなるFreeS/WANがありません。この場合、別途IPSECプロトコルをサポートしたVPN用のソフトをWindowsマシンにインストールする必要があります。ただ、Windows2000には標準でIPSEC機能が実装されているので、設定次第でFreeS/WANと接続することも可能のようです。こちらは後日試したいと思ってます。
追記 ('01/10/10)
Windows2000でFreeS/WANと接続することはできました。が、これはあくまでSG(FreeS/WAN)とWindows2000の間をIPSECで接続するだけで、その先にあるVPNにアクセスするようにはできないようです(確証は無し)。残念。

追記('02/3/20)
http://www.furukawa.co.jp/network/sec/client/client.html こういうソフトもあるようです。やっぱり別にこういうのを買わないといけないのでしょうかね・・・?

追記('02/3/29)
FreeS/WANにパッチを当てることで Windows2000(Professional)と接続し、Windows2000からSGの先のVPNにアクセスできるそうです(tomo 様、情報提供ありがとうございました)。参考URL:http://vpn.ebootis.de/

私はまだ試せていませんが(実際は試したが失敗した)、近いうちに結果を報告します。なお試そうと思う方はFreeS/WANのバージョンを最新(1.96)にして試した方がいいと思います(私の場合 1.91にパッチを当てたら、もともと正常だったVPNの認証がエラーになるようになってしまったので)。

制限事項

IPSECにもできないことがあります(FreeS/WANマニュアル Limitation of IPSECより)。

システムが安全であることが前提
IPSECの利用にはSGがセキュリティ的に安全であることが必要です。例えばSGに誰でもtelnetできてしまうとか、rootのパスワードもrootであるとか(!)、デーモンにセキュリティホールがあるような場合、IPSECではそれを防ぐことはできません。まあこれは当たり前といえば当たり前の話です。

end-to-endを暗号化するわけではない
end-to-endとは、自分と実際の通信相手を指します。例えば自分のデスクトップPCから遠隔地の相手のデスクトップPCまでの間がそうです。IPSECではSG間をトンネリングします。例えばSGとして動作しているメイルサーバがあっても、そのメイルサーバの転送先のメイルサーバがSGでないなら、その間は暗号化されません。また、SGから内側(社内LANなど)の通信が暗号化されるわけではないので、デスクトップPCから出したメイルは、SGにたどり着くまでは盗み見ることができてしまいます。

IPSECは万能ではない
IPSECは全ての上位プロトコルの機能を提供するわけではありません。例えば電子署名(誰かが承認したことを示すコンピュータ上の署名)されたドキュメントが必要な場合、電子署名を行うソフトウェアが別に必要になります。

IPSECはマシンを認証するのであってユーザではない
IPSECでは強力な認証システムを使用していますが、これはあくまで相手のSGを認証するのであって、それを使用するユーザではありません。社内に極秘のデータベースがあり、それをIPSECで認証した接続先からアクセスされるような場合、その向こう側でアクセスしている人間が正当な人間なのかどうかはIPSECではわからないということです。

DoSは防げない
Denial of Service(サービス不能攻撃。相手マシンに異常なパケットを大量に送るなどして本来のサービスを妨げる行為)を防ぐことはできません。

トラフィック解析は防げない
IPSECでは本来のパケットのヘッダを暗号化し、SGに送るためのヘッダを付け加えます(これが無いとルータはどこへ送っていいかわからない!)。これをキャプチャすることで、SGの相手が誰なのか、ぐらいはわかってしまいます。これにより、相手SGのセキュリティーホールをつくことが可能になるかもしれません。

「なんだ、こんなんじゃ使えないじゃん」と思いましたか?
いいえ、そんなことはありません。ここに挙げた制限はIPSEC上の問題というよりもそれを取り巻く環境に依るもので、メイルを暗号化したければPGPがありますし、要は使い方次第ということです。

準備

準備するものはそう多くはありません。ネットワークカードが付いたGNU/LinuxがインストールされたPC互換機とFreeS/WANのソースぐらいです。遠隔地同士を接続するのですから、それぞれでインターネットへの接続回線が必要になります。

PC互換機

MMX Pentium 200MHz、メモリ64MB、HDD 500MBもあれば十分動作してくれます。というか、これが私の使っているシステムです(実際はHDDは3GBあるけど)。ただし動作確認のためには相手が必要になるので、実質的にはFreeS/WANがインストールされたPCが2台、さらに実際のクライアントとその通信相手用にもう2台必要になります。

ネットワークカード

IP Masqueradeしているなら2枚のネットワークカードが入っているはずです。この場合、IPマスカレードとFree/SWANを1つのPCで稼働させることができます。1枚のネットワークカードでもIPSECサーバとして利用することが可能です(後述)。

GNU/Linux

いろんなディストリビューションがありますが、私は諸処の事情から Red Hat Linux7.1を使用しています。もちろん他のGNU/Linuxでも大丈夫なはずです。

※重要
FreeS/WANはLinuxカーネル2.4.2では動作しませんでした。Red Hat Linux7.1には標準で2.4.2のカーネルが付属しているため、これを上位のバージョンにアップデートする必要があります。
いろんなページを調べましたが、2.4.3が一番安定した動作実績があるようです(私も2.4.3を使っています)。(これがわかるまで半月ぐらい悩んだ....涙)

追記('02-1-18)
Red Hat Linux7.2 に標準添付のカーネル2.4.7-10 でも動作することを確認しました。

FreeS/WANのソース

http://www.freeswan.org/download.html からダウンロードするだけです。2001年9月16日現在のバージョンは1.91となっています。

追記('02-3-29)
1.91と1.94の間で相互接続が可能なことを確認しました。

インターネット回線

ADSLなり専用線なり常時接続の環境があればOKです。動的にIPアドレスが変わるような環境でも、ダイナミックDNSなどを利用すれば使用できます。ただし特にフレッツADSL/ISDNでは通信中であっても勝手に自動切断されて再接続後のIPアドレスが変わってしまうらしいので利用は難しくなるかもしれません。もっともこれではそもそもIPSECに限らずサーバとしての利用がおぼつきませんが...。

カーネルへの組み込みとビルド

カーネルのコンパイルですが、上述の様にkernel2.4.2の場合はkernel2.4.3にアップデートします。具体的な方法はJFなどを参考にして下さい。この時注意点として、/usr/src/linux/Makefile の頭の方にある

EXTRAVERSION = -2 (空欄の場合もある)

という記述を

EXTRAVERSION = -010916

などのように、現在の日付か何かに変更することを忘れないで下さい。これを忘れると、現在のカーネルモジュールが上書きされることがあります(というか、FreeS/WANに限らずカーネル再構築の時の注意点です。新カーネルを make bzdisk でFDで試してるから大丈夫と思って make modules ; make modules_install してエラい目にあった人がいます(オレ))。
また、Red Hat Linux7.1ではmake menuconfig の前に一度だけ、 make mrproper を実行する必要があるようです。

まずは再構築したカーネルで無事ブートすることが確認できたら、FreeS/WANのインストールを行います。正式マニュアルに従えば、ダウンロードしたtarballを

/usr/src/freeswan-1.91

として展開します。FreeS/WANを /usr/src/linuxの下にインストールするのは避けて下さい。リンクが混乱します。また、別ディレクトリから cp -R でコピーすることも避けて下さい。シンボリックリンクファイルがコピーされません。

次にカーネルにIPSEC機能を追加するためのスクリプトを実行します。rootになったら、

# cd /usr/src/freeswan-1.91
# make menugo

でカーネルのコンフィグレーション画面が起動されます。起動したら、"Networking Options --->" を見てみましょう。下の方に、"<*> IP Security Protocol (FreeS/WAN IPSEC)"という項目が追加されているはずです。項目には全部 [*]が付いていますが、そのままでOKです。追加されていることを確認したらそのまま Exitし(2回)、変更を保存します。すると、自動的にカーネルとFreeS/WANのコンパイルが始まります。時間はマシンスペックにもよりますが、30分もあれば終わるでしょう。

コンパイルの結果はカレントディレクトリの out.kbuild というファイルに出力されます。エラーがあったかどうかは、

# ./utils/errchk out.kbuild

を実行し、何も出力されなければエラーなくコンパイルは終了しています。エラーがあった場合はその内容をチェックします。FreeS/WANとカーネルのバージョンがうまく合わなかった場合などエラーになる場合がありますが、この場合別バージョンのカーネルを試すなどの処置が必要になります。

次に、

# make kinstall

を実行します。これで新カーネルとモジュールのインストールが完了します。エラーがあったかどうかは

# ./utils/errchk out.kinstall

で同様に確認できます。make kinstall は、

make
make install
make modules
make modules_install

を実行するのと等価なので、これを手動で実行してもかまいません。make install が実行されるので、ハードディスクブートに使用するカーネルが上書きされる点に注意して下さい。不安なら/etc/lilo.conf を書き換えて、旧カーネルでもブートできる設定にしておいた方がよいでしょう。例えば、

/etc/lilo.confの内容:
              :
              :
image=/boot/vmlinuz-2.4.2-010622
        label=linux.old
        read-only
        root=/dev/hda5

image=/boot/vmlinuz-2.4.3-010830
        label=linux
        read-only
        root=/dev/hda5

などです。次にシステムリブートしてブートメッセージを確認します。ブート時に各種デーモンを起動していく中にIPSECが追加されているはずです。warningが出るかもしれませんが、これはコンフィグレーションが正しくないだけでカーネルへの組み込みは正常に完了しています。起動時にIPSECが[NG]にならなければ大丈夫です。ブートしたら rootになって、

# ipsec --version

と実行してみましょう。インストールが完了していればコマンドが実行されるはずです。

なお、SGではパケットをフォワードするので、パケットフォワードが有効になっている必要があります。無効の場合は

# echo "1" > /proc/sys/net/ipv4/ip_forward

を実行しておきます。さらにFreeS/WAN 1.95 では rp_filter も Disableにしておく必要があります。

# echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter
# echo 0 > /proc/sys/net/ipv4/conf/ipsec0/rp_filter
# echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

を実行しておきます(/proc/sys/net/ipv4/conf/default/rp_filter に 0 を書いておけば ipsec0 の Disableは不要な気もしますが一応念のため実行します。というか、ipsec0 のインターフェイスは ipsec を起動した時点で動的に生成されるため、デフォルト値をDisableにしておく必要があります)。

コンフィグレーション

想定するネットワーク環境

以下は今回設定するネットワーク環境の図です。

*********************************************************************************************
left subnet ============ NAT box ---------- SG1 ------- router --<Internet>...
172.16.0.0/16   172.16.0.3 | 4.3.2.2       4.3.2.1      4.3.2.8

   ...<Internet>---- ADSL modem ----------------- SG2/NAT box ============= right subnet
                アドレス不定(mydomain.dyndns.org)     | 192.168.0.1        192.168.0.0/24
*********************************************************************************************

SG1, SG2はFreeS/WANがインストールされたLinuxマシンです。SG2では同時にIP MasqueradeによるNATも行っています。左側のネットワークではSG1とNATマシンは別になっていますが、これを右側と同様にNAT+FreeS/WANのSGとして構築することも可能です。

※注意点
NATより内側にSGを設定するのはうまく動作しません。これは、NAT boxでパケットが書き換えられてしまうためです。従って、NAT boxとSGを別々のマシンで動作させる場合、外側(グローバルIPが割り振られる)にSGを設置する必要があります。とはいうものの、工夫次第でNATの内側にSGを置くこともできるようです。Ipsec practical configurations for Linux Freeswan 1.x.を参考にして下さい。

追記('02-3-26)
NATされた内側に設置されたSGでも通信できることを確認しました。具体的には So-net ADSL 8Mコースを利用している環境と接続できました。詳細はこちら(現在のページの説明全部を読んでいることを前提として記述しています)。

コンフィグレーションファイルの設定

コンフィグレーションは/etc/ipsec.conf で行います。ipsec.conf の中は大きく分けて config セクションと conn セクションに分かれます。
config では、FreeS/WAN全体の設定を行い、conn セクションで個別にネットワークの設定を行います。 conn セクションを複数定義して複数のVPNを設定することもできます。
ipsec.conf ファイルはFreeS/WAN がインストールされたマシンにそれぞれ必要です。まずはどちらかのSG向けに作成し、それを相手にもコピーして必要な部分を書き換える方がよいでしょう。以下は上図SG2の/etc/ipsec.conf です(SG1側も後で示します)。

以下で、それぞれのセクションの設定項目をみていきます。実際のipsec.conf の内容と照らし合わせて、必要な部分を書き換えます。ここではコメント(#で始まる行)は省略しています。

config セクション
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        uniqueids=yes
interfaces=%defaultroute
IPSECで使用するネットワークインターフェイス名です。interfaces=eth0 などと明示的に指定してもよいですが、%defaultroute と書くと「よきにはからって」くれます。私の場合、ADSLモデムによるPPPoE 接続なので ppp0 と書けば良さそうなものなのですが、なぜか %defaultroute にしないと認識してくれませんでした。FreeS/WANが認識している各種デフォルト値は、
# ipsec showdefaults

で確認することができます。

klipsdebug=none, plutodebug=none
klips とは、Kernel IP Securityの略で、IPSECをサポートしたカーネルのことです。plutoは鍵交換による認証プロトコル(IKE)を行うためのデーモンです。つまり、
plutoで認証→OK→KLIPSでパケット暗号化→通信
という流れになります。ここではそれぞれのデバッグメッセージの有無を指定します。デバッグメッセージの有無は ipsec コマンドで動的に変えれられますので、ここでは none のままでも大丈夫です。

plutoload=%search, plutostart=%search
それぞれ、起動時にロード・使用するコネクション名を指定します。%seachを指定すると全てのコネクションが指定されます。

uniqueids=yes
コネクションを確立した時に、それを識別するIDを常にユニーク(唯一)なものにするかを yes / no で指定します。多分、どっちでもいいです。
conn セクション

conn セクションはデフォルトも含め、複数定義されます。下記の conn %default には全てのコネクション定義のデフォルトとなる値を設定します。例えば認証の方式などが含まれます。

conn %default
        keyingtries=0
        authby=rsasig
keyingtries=0
相手SGとの接続のリトライ回数を指定します。0で"Never Give Up"です。設定が確認できていないうちは無駄なトラフィックを避けるため、5とかに指定しておきます。

authby=rsasig
相手SGとの認証方式を指定します。RSA方式と shared secrets方式を選ぶことができます。認証方式については後述します。

次は実際のコネクション定義です。sample という部分がコネクションの名称です。

conn sample
        left=4.3.2.1
        leftnexthop=4.3.2.8
        leftsubnet=172.16.0.0/16
        leftrsasigkey=省略
        right=mydomain.dyndns.org
        rightnexthop=%defaultroute
        rightsubnet=192.168.0.0/24
        rightrsasigkey=省略
        auto=start

このleft, rightという接頭語は、VPNとして接続する互いのSG上の設定を示します。ここでは上図のネットワークをそのまま「left」、「right」としています。このleft, rightは便宜上の取り決めであって、どっちが右でも左でもかまいません。要はどちらかを左と決めたら相手は右、ということです(政治的党派でも互いにそう「決めつけて」ますね。:-))。

left=4.3.2.1
上述の図の「左側」のネットワーク上にあるSG1のグローバルIPアドレスあるいは正式なドメイン名(FQDN)を書きます。

leftnexthop=4.3.2.8
leftで記述したマシンのゲートウェイとなるマシンやルータのIPアドレスです。自マシン側のアドレスが分からない場合は %defaultroute にし、相手側のアドレスが分からない場合は記述しなくても大丈夫のようです。

leftrsasigkey=省略
left で記述したマシンのRSA公開鍵です。詳しくは後述します。

leftsubnet=172.16.0.0/16
VPNで使用するサブネットマスクです。相手側VPNとは異なるサブネットにする必要があります。

right=mydomain.dyndns.org
上述の図の「右側」のネットワーク上にあるSG2のグローバルIPアドレスあるいはFQDNを書きます。個人向けADSL接続サービスなどでIPアドレスが動的に変わる場合、相手から見て自分が特定できないと困るので、ここでは DynDNSのダイナミックDNSサービスにより取得したドメイン名を記述してあります(注意:mydomain.dyndns.org は例です。必ず自分で取得したドメインを利用して下さい。DynDNSで無料で取得できます。

'02-3-14 追記
少々誤解していました。無理にドメインを取得しなくても、ここを %any と記述すれば「誰の挑戦でも受ける」設定になります(もちろん相手の認証は別途行われますがいくぶんセキュリティは低下すると考えるべきです)。某ISPのように強制的&定期的にIPアドレスが変わってしまう場合、ドメインとIPアドレスの対応が取れなくなり、以降接続できなくなるので、その場合は %any としておきます。これは接続される側(後述する auto=add 側)の設定で、接続する側は関係ありません。FreeS/WANのマニュアル Configuration -> Example Setups -> Road Warrior の記述も参考にして下さい。
なお、FreeS/WANは接続時に動的に ipsec0 ネットワークI/Fデバイスを生成しますが、接続状態でその大元のネットワークI/Fデバイス(例えばppp0)の切断&再接続が行われた(そしてIPアドレスが変わった)場合、IPアドレスが一致しなくなるため、以降ネットワークが使えなくなるようです。というわけで上記の %any の設定も PPPoEではうまくいかないかもしれません。

rightnexthop=%defaultroute
leftnexthop と同じです。PPPoEの場合動的にアドレスが変わるので、%defaultroute にしています。

rightsubnet=192.168.0.0/24
leftsubnet と同様で、右側VPNで使用するサブネットマスクです。

rightrsasigkey=省略
rightで記述したマシンのRSA公開鍵です。詳しくは後述します。

auto=start
このコネクション定義を自動的にロード及び実行するかどうかの指定です。add=start と書いた側が接続しにいきます。auto=add とすると接続待ち状態で待機します。普通、片方を start にしたらもう片方は add にします。接続確認時は add 側SGを起動した後に start 側SGを起動して、よけいなエラーを表示させないようにして確認した方がよいでしょう。

認証方式

FreeS/WANでは相手SGを認証するために2つの認証方式を選択できます。それがshared secrets と RSA です。

shared secrets は pre-shared secrets とも呼ばれ、あらかじめキーとなる文字列をお互いに決めておき、それを認証に使うものです。共通鍵認証方式とも呼ばれます。共通鍵認証では単に自分の文字列と相手が持っている文字列が等しいかを調べるだけで、その文字列がバレたら簡単に詐称されてしまいますので、テスト時以外は使用しない方がよいと思います。
RSA は 公開鍵認証方式と呼ばれるもので、あらかじめ計算によって作成した公開鍵と秘密鍵のペアを使用して暗号化を行うものです。

データを送る側は相手の公開鍵で暗号化し、受け取る側は自分の秘密鍵で復号化します。

公開鍵で暗号化したものはそれに対応する秘密鍵でしか復号化できないため、第三者が公開鍵を盗んでも解読できないようになっています。

認証情報の設定

shared secretsの場合
/etc/ipsec.secrets ファイルに共通鍵の情報を設定します。例えば、
# sample /etc/ipsec.secrets file
4.3.2.1 mydomain.dyndns.org: PSK "himitudesuyo"
では、SG間の共通鍵は "himitudesuyo" という文字列になります。これをお互いの ipsec.secrets に記述することで、相手SGを認証します。

RSA の場合
設定には /etc/ipsec.conf と /etc/ipsec.secrets を使用します。公開鍵の情報を ipsec.conf に、秘密鍵を ipsec.secrets に記述します。
FreeS/WANをインストールした直後には、ipsec.secrets ファイルは既に作成されていたと思うので、その場合は下記手順3から行います。

手順:
  1. # ipsec rsasigkey --verbose 2048 >mykey
    を実行。これで鍵が作成される。マシンスペックによっては数分かかることもあります。

  2. /etc/ipsec.secrets を作成し、以下を記述して保存します。
    : RSA   {
    ここにmykeyファイルの内容を全部コピー
    }
  3. /etc/ipsec.secrets の、#pubkey=................ で始まる行の=から右全部を /etc/ipsec.conf 内のrightrsasigkey(自分が right の場合)=の右側にコピーして保存。leftrsasigkey は、left で同様にして作成したキーを記述する。

  4. 完了。

反対側VPNの設定

ほとんど上記の場合と同じです。環境によっては全く同じものでも大丈夫です。ただし、 %defaultroute などの記述は、そのマシン上での値として展開されるため、互いに異なるハードウェア環境の場合はうまく動作しません。実際私の場合も、一方はEthernet、一方はPPPoEなので、お互い違う設定になっています。以下にleft, rightそれぞれの設定を示します。

SG1側(left) ipsec.conf SG2側(right) ipsec.conf
# basic configuration
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        uniqueids=yes

# defaults for subsequent connection descriptions
conn %default
        keyingtries=5
        authby=rsasig

# sample VPN connection
conn sample
        left=4.3.2.1
        leftnexthop=%defaultroute
        leftsubnet=172.16.0.0/16
        leftrsasigkey=abcdef...省略
        right=mydomain.dydns.org
        rightsubnet=192.168.0.0/24
        rightrsasigkey=ghijkl...省略
        auto=add
# basic configuration
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        uniqueids=yes

# defaults for subsequent connection descriptions
conn %default
        keyingtries=5
        authby=rsasig

# sample VPN connection
conn sample
        left=4.3.2.1
        leftnexthop=4.3.2.8
        leftsubnet=172.16.0.0/16
        leftrsasigkey=abcdef...省略
        right=mydomain.dyndns.org
        rightnexthop=%defaultroute
        rightsubnet=192.168.0.0/24
        rightrsasigkey=ghijkl...省略
        auto=start

動作確認

コンフィグレーションファイルが作成できたら動作確認を行います。両方のSGで以下を実行します。

# /etc/rc.d/init.d/ipsec restart

でFreeS/WANを再起動することで、コンフィグレーションが有効になります(実際はコンフィグレーションだけのリロードもできますが、慣れないうちは再起動した方が確実&楽です)。

起動したら、

# tail -f /var/log/secure

を実行します。全てがうまくいけばどちらのSGでも、

Sep 30 20:39:13 mydomain Pluto[6569]: Starting Pluto (FreeS/WAN Version 1.91)
Sep 30 20:39:14 mydomain Pluto[6569]: added connection description "sample"
Sep 30 20:39:14 mydomain Pluto[6569]: listening for IKE messages
Sep 30 20:39:14 mydomain Pluto[6569]: adding interface ipsec0/ppp0 210.12.22.192
Sep 30 20:39:14 mydomain Pluto[6569]: loading secrets from "/etc/ipsec.secrets"
Sep 30 20:39:15 mydomain Pluto[6569]: "sample" #1: initiating Main Mode
Sep 30 20:39:17 mydomain Pluto[6569]: "sample" #1: STATE_MAIN_I4: ISAKMP SA established
Sep 30 20:39:17 mydomain Pluto[6569]: "sample" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS
Sep 30 20:39:18 mydomain Pluto[6569]: "sample" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

のようなメッセージが表示されるはずです。認証が完了したかどうかは

# ipsec look

# ipsec auto --status

で確認できます。この時点では認証が完了しただけなので、実際にVPN間で通信ができるかどうかは別です。確認は、SGではなく、VPN内のマシンから相手VPN内のマシンに直接、

# ping 172.16.0.1

などを実行して確認します。

つながらない!

うまく接続されない場合は以下を確認します。

ファイヤーウォールの設定

NATしている場合や社内LANと外の間にファイヤーウォールがある場合、VPN間のパケットを通すようにする必要があります。Kernel 2.4の場合、ipchains あるいは iptables で設定します。

# iptables -A FORWARD -s 192.168.0.0/24 -d 172.16.0.0/16 -j ACCEPT
# iptables -A FORWARD -s 172.16.0.0/16 -d 192.168.0.0/24 -j ACCEPT
あるいは
# ipchains -A forward -b -s 192.168.0.0/24 -d 172.16.0.0/16 -j ACCEPT

を実行します。IPマスカレードしている場合は、この定義はそれらより前で定義する必要があります。ここでは全てのパケットを通していますが、より高いセキュリティのためには個別にパケットのフィルタリングルールを追加する必要があります。
なお、ipsec.conf の中に leftfirewall=yes(あるいは rightfirewall=yes)という記述を追加すると上記に相当する処理(実際にはipfwadmを使う)を行ってくれるようですが、iptablesを使っている場合は ipfwadm が使えないのでうまく機能しません。好みの問題ですが、leftfirewall(rightfirewall) は使わずに本来のファイヤーウォールの定義でフィルタリングした方が一元管理できるので楽だと思います。このへんを細かく定義(FreeS/WAN動作時のみ有効なフィルター定義など)をしたい場合はマニュアル内を updown script で検索して調べて下さい。

認証の確認

認証が失敗する場合(上記のPluto のメッセージが表示されない)、ipsec.conf 内の鍵の設定誤りが考えられます。値を確認するか、shared secrets による認証を試してみて下さい。その場合、ipsec.conf 内の authby=と leftrsasigkey=, rightrsasigkey= の行の先頭に#をつけてコメント化すればshared secrets による認証となります。上記を参考にして共通鍵を設定します。

デバッグメッセージの有効化

それでも認証がうまくいかない場合は

# ipsec plutodebug --all

を実行した後、相手側のSGを

# /etc/rc.d/init.d/ipsec restart

により再起動し、/var/log/messages, /var/log/secure の内容を確認します。

認証は完了しているなら、

# ipsec klipsdebug --all

を実行した後、ping を実行してみます。デバッグメッセージが大量に出力される中に、なんらかのエラーが出力されているはずです。そのエラーメッセージを元にGoogle などで検索を掛けてみましょう。誰かが同じ質問を行っているかもしれません。

デバッグメッセージの出力は

# ipsec plutodebug --none
あるいは
# ipsec klipsdebug --none

で止めることができます。

パケットのダンプ

SG上でtcpdump コマンドを実行して、どこまでパケットが来ているかを調べます。

# tcpdump -i ipsec0 -n
21:34:50.157708 172.16.0.3 > 192.168.0.7: icmp: echo reply (DF)
21:34:51.153274 192.168.0.7 > 172.16.0.3: icmp: echo request
21:34:51.155861 172.16.0.3 > 192.168.0.7: icmp: echo reply (DF)
21:34:52.152480 192.168.0.7 > 172.16.0.3: icmp: echo request
21:34:52.154979 172.16.0.3 > 192.168.0.7: icmp: echo reply (DF)

通信できれば、VPNのアドレスのパケットとして表示されます。

※SG上で tcpdump すると、なぜかすぐにはパケットが表示されない場合があります。何度か試すか、少し(数十秒)待った方がいいです。確実なのは同ネットワーク内のマシンでtcpdump するかパケットアナライザを使うことです。

VPN内マシンのルーティング情報およびルータのルーティング情報

VPNにあるマシンは自分側のSGと通信できる必要があります。route コマンドでデフォルトルータがSGになっているか、あるいはSGと同じネットワークのルータになっているか確認します(SGとNAT boxを分けている場合)。後者の場合、そのルータのデフォルトゲートウェイはSGにしておく必要があります。これは、ルータが送出するパケットはSGを経由しないと暗号化されないためです。まとめると、それぞれのデフォルトゲートウェイは

VPN内PC -> ルータ(NAT boxなど) -> SG -> 外部ルータ -> Internet

というパケットの流れになるように設定する必要があります。1台でNAT/SGを勤めるPCの場合は気にする必要はありません。

利用方法

基本的に ping が通れば、それ以外のサービスも利用可能になっているはずです。例えば相手VPN内にあるサーバにも直接 telnet できます。ネットワークコンピュータにアクセスしたい場合は、

Windows2000の場合:
\WINNT\system32\drivers\etc\lmhosts
Windows95/98の場合:
\Windows\lmhosts
に、

172.16.0.3        server1

などと書いておけばアクセスできます。


HOME FreeS/WAN