リッチなサーバ構築(仮)

常時接続環境をお持ちで,俗にブロードバンドルータと呼ばれる機器を使用して インターネットへ自宅のコンピューターを接続しているという方. 自宅でサーバを立ててみたいと思いませんか.…というより,立てると便利ですよ〜.
当研究所のサーバは一台のPCにいろいろな機能をリッチに詰め込み, とても便利に使ってます.下記に列挙したこれほどまでにリッチな機能は ブロードバンドルータに真似できまい.(特に最後の2つは!)
このページでは,一台のノートPCにFreeBSDというUnix(UNIX系OS)をインストールし, リッチなサーバへと仕立てていく方法を紹介します.

このページの内容は,紹介する順番もランダムで内容も簡素です.わかりにくい かもしれません….ここの内容はそのうち一冊の本にまとめられる予定であり, そのプロトタイプ的な位置付けにあります.
また,各種のソフトのインストール法や設定法を紹介するだけでなく, ブロードバンドルータに比べた設定の面倒臭さを埋めるためのオリジナルCGIも 公開しようと考えています.

基本的にFreeBSDを前提とし,また一台でリッチに全てを行うことを前提に 話を進めるつもりですが,Linuxが好きだという方も, 複数のPCで構築しようと考えているかたもつまみ食い的に利用すれば 役に立つと思います.
例えば,ファイアウォールとNATはせっかくだから今あるブロードバンドルータに…, それ以外の機能はLinuxで…なんてケースもOKです.

こんなことやります…


リッチなサーバは危険なの!?

「一台のコンピューターにいろんなサービスを行わせるような使いなどもってのほか! 危険だ!!」という意見があります.当研究所が構築しているリッチなサーバはまさにこのようなサーバであり,その意見によれば危険ということになります.確かにサーバをリッチにすることによって危険度が増すことはわかります.従って私も,サーバを立てることを業務として請け負った場合にはこのような立て方をするつもりはありません.
ならば,

ここで紹介する『リッチなサーバ』は『百害あって一利無し.実践する意味など全く無い….』ということで終〜了〜.
という結論に至るのはちょっと待ってください.まずはなぜ危険と言われるのかを説明させて下さい.
危険,危険…と言ってもサーバをリッチ化することが即危険に繋がるというわけではないのです.サーバをリッチ化することは,
RAID 0を実践するようなものだからなのです.RAID 0はハードディスクを並列に使うことで容量とスピードの増加という利便性を得ますが,ハードディスクのどれか一台でも壊れれば全てのデータを失いかねない危険性も受け入れなければなりませんね.リッチなサーバも利便性と同時に危険性を受け入れるわけです.どういう危険性かというと,もしいくつものサービスを動かしている中でたった一つのサービスにセキュリティホールが存在し,それが実は重大なものであってサーバの管理者権限(root)を奪われてしまうと,他のサービスも不正侵入者の手中に収められてしまいますので,サーバ全体が危機にさらされるようになってしまいます.その危険性はサーバのデータが全て失われるだけにとどまらないかもしれません.場合によっては,あなたが構築なさったサーバを利用して第三者に攻撃を仕掛けるために利用され,管理不行届としてその被害者からあなたが責任を取らされる可能性すらあります.これがもし複数のサーバを用意してサービスを分散させていたとしたら,一つのサーバが危険にさらされても他のサーバはとりあえず即危険というわけではありませんし,ファイアウォール等でそれぞれのサーバにそれぞれ必要なパケットしか通さないようにしておけば,一台のサーバが第三者にできる悪行などたかが知れているかもしれません.こういう意味で一台でいろんなサービスを行っているサーバは危険性が高いと言われるわけです.

こういう言い方をすると反論を受けるかもしれませんが,セキュリティへ掛けるコストは,あたかが守りたいもの価値(あるいは被害に遭った時に奪われる価値)に見合う量だけ掛けるべきなのです.解りやすい例を挙げて説明しますと,10,000円の価値しかないものをドロボーから守るために100,000円の金庫を買うのは全くのナンセンスだということです.サーバ構築も同じことで,サーバを複数にするためのコンピューター購入資金と,サーバに不正侵入された場合に発生するであろう被害額をよく考慮すべきなのです.
業務としてサーバ構築をする場合,サーバは基本的にお金が絡む用途に使用することになるので不正侵入された場合の被害額は大きくなります.しかし自宅で使用する場合は必ずしもそういうわけではありませんのでリッチなサーバは大いに考慮の余地があります.また被害額は日頃からの管理体制がしっかりしていれば低額で済むことでしょう.管理体制といっても大したことはありません.下記のたった3つさえ守ればいいのです. 趣味でサーバを立てている私は,管理するのもまた趣味になっていますので管理はしっかりしている方だと思います.そのようなわけで当研究所では総合的に判断してリッチなサーバを構築しています.
というわけで本ドキュメントではリッチなサーバを構築する方法を書いていますが,業務で立てようとしている方や,(趣味でも)セキュリティの強固なサーバを立ててみたいとお思いの方にはお勧めしません.しかしながら,それはここに書いてある方法を100%マネするようにはしない方がいいという意味であり,大いに参考にはなるものと思っています.より安全なサーバを構築したいのであればサーバを複数用意し,そのそれぞれのサーバで,このドキュメントの内容を参考にすればいいのです.本ドキュメントを参考にし,あなたなりの(安全性も含めた)便利なサーバを是非構築して下さい.


FreeBSDのインストール

そのうちここにも簡単に書く予定ではいますがまだ何も書いていません.ここなどのように非常に丁寧に解説しているページがあるのでさすがにここのクォリティにはかなわないかなあと….ただ,私なりにFreeBSDのインストールのしかたで思うところがあるのでそういう部分については書こうと思ってます.(いやもちろんこの方の方法に,異議があるわけじゃないです.)
今はとりあえず,FreeBSD のインストールに関連したリッチなはなしを書きます.

スクリーンセーバー

FreeBSDのインストールを進めていくとやがて"System Console Configuration"という画面に到達します.この画面では
番号 項目名 概要
1 Exit この画面を終了する
2 Font フォントの種類を替える(あまり意味なし)
3 Keymap キーボードの配列指定(日本語キーボードならもちろん"Japanese 106")
4 Repeat キーボードを押しっぱなしにした時のリピート間隔(あまり意味なし)
5 Saver スクリーンセーバー(好みに応じて)
6 Screenmap フォントに応じて替える必要があるが(フォントがデフォルトならそのままでOK)
というメニューがあって,日本なら設定が必須なのは3くらいで後はデフォルトでいいのですが,スクリーンセーバーというのは結構気になりませんか? というかFreeBSDインストール経験者ならかつてきっと気になったことがあるはず!

10種類くらいあって,どれを使ってもいいのですが(機種によってはうまく表示されないものもあります),ここで選択する時はプレビューが表示できないのでどれが自分にとってお気に入りかさっぱりわかりません.
インストール後に替えられないこともないのですが,設定値はシェルスクリプトである/etc/rc.confに変数として書かれているので,/etc/rc.confを直接いじろうにも他のスクリーンセーバーを指定したい場合に何という文字列を書けばよいのかわからない.かといって/stand/sysinstallを使うのも面倒だし,それにここで設定すると/etc/rc.confはどんどん汚くなっていく….
だいいち,/etc/rc.confに書いたってそれを有効にするには再起動をしなければならずそれもまた面倒臭い!! それにそれに起動するまでの時間(デフォルトでは5分間)何もしないで待つのもまたまた面倒臭い!!! まともに全部試していたら1時間以上掛かってしまいますので大抵は一通り鑑賞することを諦めてしまうと思います.

そんなわけで「今すぐプレビューを見たい」という方のために,その願いを叶えるシェルスクリプトを作ってみました.中身(シェルスクリプトのソース)を見たい方はそのままクリック,ダウンロードしたい方はSHIFT+クリック(または右クリック)等でファイルに保存しましょう.

使い方

このシェルスクリプトをFreeBSDに持っていって,実行パーミッションを与えたらとりあえずオプションなしで実行してみましょう.すると書式が出ます.
あ,このシェルスクリプトはroot専用ですのでご注意を….何といってもFreeBSDのスクリーンセーバー(Not X)はカーネル実装であるため,ユーザー毎に設定できるようなものではありませんので….(シェルスクリプトなのでsetuidビットを立てたとしても一般ユーザーには使えません.)
Usage: saver.sh [-l] [-s {screen_saver_name | NO} [-b waiting_seconds]]
-l と -b と -s オプションがありますが,まず -l オプションを使いましょう.すると利用可能なスクリーンセーバー一覧が表示されます.その名前が,/etc/rc.confで指定するスクリーンセーバー指定文字列としてそのまま使えます.例えば"daemon"がお気に入りなら/etc/rc.confに
saver="daemon"
という一行を追加するだけです.
途中の説明が抜けてしまいましたので話を戻します.どれがいいかプレビューを表示するためには -s オプションと -b オプションを使います.まず -s オプションで切り替えたいスクリーンセーバーを指定します.名前はさっき -l で表示されたものの中から選ぶことができます.さらに -b オプションで起動までの秒数が変更できます.この値を1にすると1秒後にすぐさまスクリーンセーバーが起動するようになりますので,-s オプションでスクリーンセーバーを次々と切り替えれば次々とプレビューできます.なお,-s オプションと -b オプションは同時に指定可能です.
これで思う存分鑑賞してお気に入りが決まったらさっき述べたように/etc/rc.confを書き換えておきます.これでスクリーンセーバーを納得して決められたことでしょう.

最後に書いておきますが,さっきも述べたようにFreeBSDのスクリーンセーバーはカーネル実装です.従ってスクリーンセーバーの切り替えにはカーネルへのモジュールロード・アンロードを行うことになります.セキュリティを高めるために kernel securelevel をレベル1以上にしていると,例えrootであっても再起動して securelevel を下げない限りカーネルへのモジュールロード・アンロードができないため,スクリーンセーバーの変更もできません.気をつけましょう.(起動までの待ち時間は変更可能)


適材適所なPCを選ぶ

自宅サーバ向けとして重要な点

自宅サーバ….「自宅」というからにはそこは居住空間であり,工場などとは違います.いろんな意味でゆとりある空間であることが望まれます.そんな場所でサーバを立てる場合.その「ゆとり空間」を壊さないためにも,以下の点が重要だと思います.いやむしろ前提条件といってもいいかもしれません.

そういうところからいくと現在売られているデスクトップPCはやや条件に合わないかもしれません.以前はファンレスが当たり前だったパソコンも,高速化する技術を重視するあまり発熱を抑える技術がないがしろにされる傾向があって今やファン付きが当たり前になってしまいました.
サーバは基本的に24時間付けっぱなしにするわけですから,消費電力の大小は電気代に大きく影響すると思われます.会社などが業務用とし使う場合,サーバを動かすことで利益を生み出すわけですから電気代は利益を得るための投資ということになり金銭的に100%無駄にはならず,ある程度多くても許容できます(もちろん少ないにこしたことはありませんが…).しかし自宅で動かす場合,全く利益目的では無いので金銭的には100%無駄となります.その意味でもできるだけ抑えたいところです.
発熱が少ないというのも重要な点です.これは「ゆとり空間」の維持には必要です.発熱するということは,見方を変えれば暖房器具です.冬はちょうどいいかもしれませんが,夏場は部屋が暑くなって地獄になります.サーバを置いている部屋が寝室を兼ねているなら熱帯夜でもないのにその部屋の中だけ熱帯夜になることもあります.かといってサーバとして動かしているならそう簡単に止めるわけにもいきません.暑いからといって冷房をつければ今度は電気代が増えます.従って発熱の少なさも重要です.
音の静かさは「ゆとり空間」維持に最も重要です.気にならない時は気になりませんが気になるときは気になってしょうがないものです.暑いときと同様に,だからといってサーバとして動かしているならそう簡単に止めるわけにもいきません.
場所を撮らないことも重要でしょう.「コンピューター動かなければただのハコ」と言われますが「動いていてもハコはハコ」です.冷蔵庫や洗濯機などはある程度の大きさが無い物が入らないので大きさに意味がありますが,コンピューターの場合はその大きさには全く意味がなく,ただ単に「ゆとり空間」を減らすだけです.要するにコンピューターは大きさに関しては百害あって一利なしですから小ささは重要です.

お勧めのコンピューター

ノートブックPC

上記の条件をクリアするものといったら,最も身近なものはノートPCではないでしょうか.ノートPCバッテリー駆動に耐えられるように設計されているので消費電力は少なめです.その結果発熱も抑えられています.ファンも無いわけではないですが一般的にデスクトップPCのものよりも静かですし,重い処理を行っているときしか動かなかったりします.
ついでに言うとノートPCにはバッテリーが付いていますので突然の停電にも耐えます.瞬間停電ならば何事も無く動きますし,長時間停電しても設定次第で安全にシャットダウンが行われます.また,携帯性を高める設計になっているために場所も取りません.
そんな理由で自宅サーバには,ノートPCがお勧めです.は携帯性や低消費電力性を高めるためデスクトップPCよりも値段が高めです.そんな時には中古品を探しましょう.サーバ,それも自宅のサーバとして使うのであればそんなに新しいもの(高性能)なものは必要ありません.ただしメモリーは少々多め(256MBくらい?)あるほうが望ましいので,手に入れた中古ノートPCのメモリが少なかったらメモリだけは別途買いましょう(これも中古で手に入りますし…).

最近よくあるファンレスPC

「最近よくあるファンレスPC」.このようなPCを何と総称していいのかわからないのですが,とにかく最近はAV志向のために騒音を排したり,まさにここで取り上げているようなサーバ用途に使われることを意識したりして,ファンレス(つまりは少発熱,低消費電力)なPCをよく見かけます.
特にサーバ用途を意識したPCでは始めからEthernet(LAN)ポートを2個搭載していて,それだけでルーターとしても使えるという製品もあります.実はそんな製品の使い心地はどんなものかと,当研究所でも
こんな製品を購入して見ました.じつはそれ以前にもそのような主旨の製品を一台購入していたんですが,今度のものは結構いい感じです.この手の製品は,FDDやCD-ROMドライブがなかったり(あるいは付けにくかったり)してOSのインストール作業が少々厄介ですが,それさえ乗り切れば自宅サーバに望まれる4つの条件を見事満たしてくれます.


ブロードバンドルータ様
今までご苦労様でした

よーするにファイアウォールとNAPT(NAT)の話

前書きの前書きです.

NAPTという用語が出てますが,これは「俗に言うNAT」(=ポート変換も利用することで1つのIPアドレスを複数のホストで共有する技術)あるいは「IPマスカレード」(=NAPTに相当する技術はLinuxで発明されたためそこではこう呼ばれている)が
RFCによりRFC2663として規定された呼び名です.
本ページでは,以下NAPTと記すことにしますので覚えておいて下さい.

俗にブロードバンドルータと呼ばれるものを買う目的といえば,

といったところではないでしょうか? そういうことであればFreeBSDを始めとするUnix(もちろんWindowsでも,MacOSでも)できますよ.他のもの(他のOSや専用ハード)は詳しくないのですが,Unixだと下記の特長があるのでおすすめです. まぁそういうわけでUnixでNAPTの立て方を解説しているページは,うちがやるまでもなく多数存在しているのですが….固定IPアドレスであることを前提に(というか固定IPアドレス環境でしか役に立たない)書かれているページばかりではありませんか? でも実際には自宅からインターネットへ接続しているほとんどの方はDHCPやPPPなどで動的にIPアドレスが変わる環境をお使いだと思います.

そこで,本ページではDHCP下でのファイアウォール&NAPTの立て方を紹介します.若干やり方が違いますがPPP(PPPoEも)下でもたぶん大いに参考になるはずですできるように正式に対応しました.(当研究所のサーバはADSLではなくCATV配下に立っいますが,フレッツが3ヶ月間無料ということで只今導入中です.)
また,本ページの記事はFreeBSD(しかもIPFW+natd)を対象としているのでLinux等ではファイアウォール内部構造からコマンドに至るまでぜーんぜん違うのでその部分は参考にしかなりませんが,やはり動的IPアドレス環境での立て方に関しては参考になると思いますのでご一読下さい.

FreeBSDファイアウォール(IPFW+natd)の内部構造

細かい設定が可能なファイアウォールで細かいフィルタリングルールを設定したいと思ったら,内部構造を知らないとなかなか難しいはずです.でもやはり,内部構造を説明しているページはほとんど無いです.そこで,FreeBSDのしかもIPFW+natdの場合についてですが,ここではその内部構造を説明します.

まずはIPFWの内部構造

IPFWの構造
図1. IPFWの内部構造

壁が外側に出来る

右の図1をご覧下さい.これは,ネットワークインターフェイスカード(NIC)を2枚挿した場合を例にしたIPFWの掛かり方です.中央の「びーえすでぃー」と書かれたノートパソコンが今までのサーバだと思ってください.実際にはもちろんIPFW自体もこのパソコンの中で動いているわけですが,今まで外部と通信していたプログラム(今までの部分)の外側に貼り付いて守るようなイメージになるので便宜的にこのような図にしたわけです.
そして,図では左右と上部に合計3枚の壁が出来上がっていますが,これがIPFWによる壁です.NICを2枚挿した場合は下記のような,3箇所に壁が出来ます. 通常は用意したNICの数+1個の壁が出来ます.NICの略号にethXという表現を用いていて何だかLinuxみたいですが,FreeBSDではNICのドライバ毎に名前が代わるので便宜上このように表記しました.ちなみに当研究所のサーバでは,外部ネットワーク用はNE2000互換のチップを使ったNICでしてed1という名前になっており,内部ネットワーク用はIntelのi8255x互換のチップを使ったNICなためfxp0となっています.

通常(NIC用)の壁

通常,自分以外のコンピューターにデータ(IPパケット)を送ったり,あるいはそこからデータを受け取る場合にはこれら(ethX)の壁を通ります.外へ出て行く場合は"out",逆に入ってくる場合は"in"ということになります.普通通信をやる場合,何かデータを送って(送られて)から応答を受ける(する)のですから,"in"の時と"out"の時の最低2回,同じ壁を通ることになります.この壁を通る時にフィルタリング(不適切なものを破棄)が行われます. 図では矢印が切れていて"in"または"out"の書かれている場所がそうです.
また,図の中央に点線矢印があって分岐・合流している箇所がありますが,点線矢印はそのデータが自分宛だったり自分発である場合に通る矢印です.入ってきたパケットが自分宛でない場合はまっすぐ通り抜けて,反対側のNICへ流れ出ます.この場合も結局"in"の時と"out"の時の2回のフィルタリングを受けます.

もう1つの壁(ループバック用)は何なのか?

最初の2つはすぐ理解できると思いますが,最後の1つは何なのか説明します.これはサーバが自分自身にデータを送る時にぶつかる壁です.サーバにログインしているユーザがそのサーバにアクセスしようとすると,内部のプロセス間でデータがやり取りされるだけなので実際のネットワークにデータは流れ出しませんが,IPFWはこのプロセス間の通信(ただしINETドメイン経由)でも壁を作ります.しかもどこかのプロセスがデータを送る時,そしてまた別のプロセスがデータを受け取る時,というふうに"out"の時と"in"の時で,この場合も結局2回壁を通ることになります.
ちなみに,ここで言うループバック(loop back)とは,INETドメインを経由するプロセス間通信全体を指しています.ループバック用のアドレスと言えばlocalhostや127.0.0.1(127.x.x.x)ですが,自分自身への通信であればそれ以外のアドレスを持つIPパケットもここを通ります. 例えば,このサーバ持つ外部ネットワーク用のIPアドレスがo.o.o.oで,自分がそこに対して通信しようとすると…送信元:o.o.o.o,宛て先:o.o.o.oのIPパケットが出来上がりますが,これはethAではなくlo0を通るということです.

natdと組み合わせた場合

IPFWの構造
図2. IPFW+natdの場合
IPFWを使いながらさらにNAPTも行わせたい場合に使うのがnatdというデーモンです.図2がnatdと連携された場合の図です.

natdの位置付け

natdはNAPTを行うためのデーモンで,ここにパケットを預けると適切なNAPTをして返してくれます.受け渡しをする場所はIPFWの壁でして,通常は外部ネットワーク(おそと)へ繋がっているNICの手前にできている壁で受け渡しをします.というわけで図2のnatdはethAに接続されています.

パケットの流れ方

natdの接続されたIPFWの壁に到達したパケットはまず,いつも通りにフィルタリングを受けます.フィルタリングとはつまり,フィルタリング対象となるパケットをフィルタリングルールとして記述されている条件に次々と照合(マッチング)していき,条件に一致した時点で何らかの動作(破棄や通過)を行うのですが,ここで行わせる動作として「natdへ送る」というものを置いておくとnatdへ転送されるようになります.
そしてnatdはパケットを受け取ると変換を行って再びそれをIPFWに戻します….が,IPFWは一回マッチングが終了したからといってそのまま素通ししてしまうわけでもなければ,だからと言って再び壁に通し直すのでもなく,マッチングの続きから行うようにします.

まとめ

文章の説明だけだといまいちわかりにくいので,具体例を挙げて説明することにします.表1をご覧下さい.条件がかなりいい加減な指定なのでこれは飽くまでイメージでしかありませんが,とりあえずこんなルールがあったとします.

表1. IPFW+natdの設定イメージ
行番号 条件 壁の場所 動作
: : : :
1000 何だか知らないがアヤしいパケット どこでも 破棄
1010 コドモ部屋のPCからのパケットで,
宛て先がコドモは見ちゃいけないサイトへのパケット
外部NIC 破棄
: : : :
2000 全てのパケット 内部NIC 通過
: : : :
3000 内部から外部へアクセスするためのパケット 外部NIC natdへ転送
3010 natdで変換されて外部へ行けるようになったパケット 外部NIC 通過
: : : :
4000 外部から入ってきたパケット 外部NIC natdへ転送
4010 natdで逆変換されて内部へ戻せるようになったパケット 外部NIC 通過
: : : :
65534 これらのどれにもマッチしなかったパケット
(例えばnatdがもともと変換した覚えなどなくて,逆変換できなかったパケット等)
どこでも 破棄&ログ

1. アヤしいパケットが来た場合

1000行で破棄されます.

2. 内部ネットワーク同士のパケット

これはつまり本サーバと内部のPCの間で通信を行うことを意味しますが,その場合は2000行で通過されるので何の規制も受けません.

3. コドモがオトナのサイトを見ようとした場合

(1)コドモ部屋のPCも当然内部ネットワークにあるので,まずは図2でいうethBに"in"します.すると2000行とマッチしてとりあえずはマッチング終了し,通過します.
(2)その後ethAに到達し,そこから"out"しようとします.ところが,そうするともう一度表1の最初からマッチングが始まりますので今度は1010行で引っ掛かってしまい,それで終わります.

4. 内部PCから普通のサイトへアクセスしようとした場合

往路(行き)
(1)内部PCなので,3と同様にethBをすり抜けた後に,ethAから"out"しようとし,再び表1の最初からマッチングが始まります.今度は3000行でマッチするので,natdへ送られます.
(2)natdで外部へ行けるように送信元アドレス&ポート変換(自分が発信したことにする)が行われ,IPFWに戻されます.
(3)先程は3000行でマッチしたので,3000行の次の行からマッチングが再開されます.するとすぐ下の3010行でマッチするのでここでethAを抜け,外部へと旅に出ます.
復路(帰り)
(4)外部からの応答が帰ってくると,まずethAに"in"します.1000行を無事かわせば4000行でマッチして,natdへ送られます.
(5)natdは,応答パケットを内部へ戻せるようにアドレス&ポートの逆変換(自分宛の返信を内部PC宛に戻す)をしてIPFWに戻します.
(6)往路と同様に,4000行の次の行からマッチングが再開され,やはりすぐ下の4010行でマッチするのでここでethAを抜け,ethBへと向かいます.
(7)ethBに到達して"out"しようとしたパケットは最後のマッチングを受け,2000行でマッチし,内部PCへと戻っていきます.

5. natd逆変換に失敗したパケット

natdを使って内部からの外部へアクセスしたパケットに対する応答が忘れた頃(タイムアウト後)に帰ってきた場合や,応答のフリをして訪れたパケットなどは次のように破棄されます.

(1)タイムアウトの場合は上記例4の(1)〜(4)が,偽装の場合は(4)が行われます.
(2)natdは最初の変換を忘れてしまったか,あるいは覚えが無いのでそのままIPFWに戻します.
(3)すると4000行の次からマッチングが行われますが,4010行ではマッチしないのでずーっとそのまま最終行(65534)まで来ます.ここでは全てのパケットにマッチするのですが,不正なパケットとしてログに記録されます.

だいたいIPFW+natdの構造は理解できましたか?

フィルタリングの方針

実際にファイアウォールを立てる場合,いきなり具体的なルールを立てるのは難しいというものです.プログラムを組むときでも最初に設計をしないとうまく作れないのと同じです,たぶん.
本ページでは,自宅にサーバを立てることを想定して方針を決めることにします.だいだいそのような用途だと下記のような方針が望まれると思います.

自宅ではこれが理想と思われますが,会社等で方針を立てる時は気をつけなければなりません.この方針では外部からの攻撃を守るのみですから,例えば内部にも信用できない人間がいたらその人にとっては攻撃し放題になるからです.しかもnatdでアドレス変換が行われますので,外部で攻撃を被った人にはどの内部PCから攻撃されたのかわからず,犯人の特定ができないからです. また,例え悪意ある人がいなかったとしても,内部PCにワーム(ウィルスの類)やトロイが感染すると,知らないうちに外部のホストを攻撃しに行ったり,内部PCの機密情報を漏らしてしまう可能性があるからです.というわけで会社等で用いる場合は,この後紹介する具体的なフィルタリングルールを流用するとしても
前節を見て,練り直したほうがいいと思います.
あと,参考までにお話しておくと上記の一番最後の方針で「マッチしなかったものは全て不正…」というのがありますがこれはごく一般的な方針です.(プロバイダなどで,ルールを規定する場合は普通逆にしますが….) しかしフィルタリングルールとして特に規定していないものは全部破棄されることになりますので,ルールを作っている最中に規定を忘れているパケットがあるとそれは破棄されてしまいますので気をつけましょう.

実際の作業

では実際の作業に取り掛かります.前節の方針を理想とし,かつFreeBSDを使うのであればここから先の作業はほとんどマネできますので,比較的ラクにいけると思います.

NICを2枚挿しする

もしNICが1つしか(あるいは1つも)なかったらNICを挿して2つにしましょう.そして2つそれぞれのどちらを外部ネットワーク用・内部ネットワーク用にするかを決めましょう.普通は外部ネットワーク用に遅いものを割り当てて,内部ネットワーク用に速いものを割り当てます.一般的にLANよりもWAN(インターネット)の方が遅いのでその方がいいですよね.

カーネルの再コンパイル

FreeBSDで,IPFW+natdを使ってファイアウォール+NAPTを実現するにはそのためにカーネルをコンパイルし直してやる必要があります.FreeBSDのカーネルもだいぶマイクロカーネル化が進んでおり,IPFWだけであるならコンパイルし直す必要が無いのですが,現状(FreeBSD 4.8-RELEASE)ではnatdも組み合わせる場合にはやはり再コンパイルが必要です.
カーネルの再コンパイルはコンフィギュレーションファイルに画面1の2行(NICを追加した場合でそのNICのドライバが無い場合はそれも)を追加するだけですから,わかっている方にはその説明だけで十分だと思いますので,次項へ言っても構いません.

画面1. コンフィギュレーションファイルの編集
options	IPFIREWALL
options	IPDIVERT
device	追加したNICのドライバのある行のコメントを外す
ファイアウォールを有効化(これも必要)
NAPTへの転送動作(divert)を有効化

わからない方のために一応説明しておきます.

1. コンフィグレーションファイルの編集

/usr/src/sys/i386/confディレクトリの中に,今使っているコンフィギュレーションファイル(GENERICとLINT以外の何か)があると思いますので,それをエディタで開きます.仮にそのファイル名がGATEKEEPERだったとします.(画面2)
え,無い!? ということはたぶんGENERICを使っていると思いますのでGENERICをコピーして開きましょう.
画面2. コンフィギュレーションファイルを開く
# su -
Password:
# cd /usr/src/sys/i386/conf
# cp GENERIC GATEKEEPER
# vi GATEKEEPER
ここから先はルートになって作業する
パスワードを入力
ファイルのある場所に移動して
(GENERIC を使っている場合はここも実行)
そのファイルをエディタで開く
開いたら画面1'のように内容を編集します.GENERICからコピーした場合には既存のidentにある"GENERIC"を,コピーしたファイル名に書き換えましょう.IPFIREWALLとIPDIVERTの2行はどこに追加してもいいのですが,ファイルの先頭から60行あたりにあるoptionsの行の最後に追加するのがいいかなと思います.

注意!!!
ファイルの編集は慎重に行ってください.おかしな記述をしたままコンパイルしてインストールしてしまうと起動しなくなってしまう恐ればあります.一応,復旧方法はありますがここでは説明しません.日本の本家である
ここには一応その方法が書いてありますが,たぶんこれだけだと知らない人はできないです.というわけで気をつけましょう….
画面1'. コンフィグレーションファイルの編集
            :
            :
cpu             I686_CPU
ident           GATEKEEPER
maxusers        0
            :
            :
options         KBD_INSTALL_CDEV
options         IPFIREWALL
options         IPDIVERT
            :
            :
devide          追加したNICのドライバ
            :



←GENERICになっていたら
 この行をファイル名に書き換えておく


←この行の下に…
←これらの
 2行を追加する


コメントアウトされていたらそれを外す

終わったら保存して終了します.

2. コンパイル

編集が終わったらコンパイルです.何も難しいことはあませんのでとにかく次の通りに打ち込みます.しかしながら,さすがにカーネルのコンパイルなので時間が掛かります(数十分)から気長にやりましょう.

注意!!!
コンフィギュレーションファイルの編集でおかしな記述をやっていた場合は,大抵コンパイルの途中でエラーとなって中断します.そうなってしまった場合は,無理やりインストールしてしまわずに,コンフィギュレーションファイルの編集からやり直して下さい.インストールしてしまうと,再起動できなくなる恐れがあります.日本の本家である
ここには一応その復旧方法が書いてありますが,たぶんこれだけだと知らない人はできないです.というわけで気をつけましょう….
画面3. コンパイル
# config GATEKEEPER
Don't forget to do a ``make depend''
Kernel build directory is ../../compile/GATEKEEPER
# cd ../../compile/GATEKEEPER
# make depend
        :
# make
        :
# make install
        :
システムを構築するために必要なファイルの作成
 configからのメッセージ:「make depend忘れずに…
 必要なファイルは../../compile/GATEKEEPERに置いたよ」
というわけでそこ(上の行に書いてある場所)に移動する
忘れずにmake dependと打ち込む
 (dependずらずら〜.ちょっと長い)
コンパイル(本番)
 (コンパイルずらずら〜.長いぞ)
インストール
 (インストールずらずら〜.すぐだぞ)

3. 再起動

コンパイルが終わると…
新しい設定を有効にするには、コンピュータを再起動する必要があります。

今すぐ再起動しますか?
というメッセージは出ませんが,普通はここで再起動します.カーネル再コンパイル後のおやくそくですから….(あ,でも今回に限ってはどうせの設定の最後に再起動することになるので,カーネル再コンパイルに自信がある方はやらなくてもいいいです.) あ,そうそう…再起動する時はカーネル再コンパイル時に限らず,rebootコマンドではなくshutdownコマンドを使うほうがいいらしいです.
画面3. 再起動のやりかた
# shutdown -r now
再起動します(rebootコマンドは避けるべき?)

各種ファイルの設定

カーネルの再コンパイルが完了したら,いよいよ本作業です.いくつかのファイルを編集したり新規作成したりします.もちろんこれ以降の作業もrootで行う必要があるので,rootでログインしておいて下さい.

0. /etc/servicesファイルの確認

古いバージョンのFreeBSDだと,natdのサーピスポート番号が定義されてない場合があります.無い場合には追加しておく必要があるのですが,そういう古いバージョンの場合はそれ以前にnatd自体をインストールする必要があります.ところが,私の知っている限りではもうnatdのインストールパッケージを配布しているところがありません.…というわけで素直に新しいバージョンを使ってください.(^^;
一応,natdのサービスポートが定義されているかどうかを調べる方法を画面4に載せておきます.
画面4. natdはサービスポートとして登録されているか?
# grep natd /etc/services
natd            8668/divert (以下略…)
確認するためにはこう打つ
そしてこのように出れば大丈夫!

1. natd.confの作成

まず最初に,NAPTのためのnatd.confファイルの設定を行いましょう.エディタでnatdの設定ファイルである/etc/natd.confを開きます…,といっても多分無いハズなので新規作成ということになります.
画面5. natd.confの編集
# vi /etc/natd.conf
natd.confの編集(恐らく新規作成になるはず)
そして内容は例えばこんな感じにします.最初の3行はこのように書いておきましょう. このうち上の2行は必須ですが,3行目は無くても問題ないでしょう.詳しくは
FreeBSDの日本語マニュアルページからnatdと打ち込んで調べてください.
画面6. natd.confの内容
dynamic         yes
port            natd
same_ports      yes

# 内部PCでWinMXを使う場合(これは例ですよ! ^^;)
redirect_port   tcp     192.168.0.100:6699      6699
redirect_port   udp     192.168.0.100:6257      6257
redirect_port   tcp     192.168.0.101:6700      6700
redirect_port   udp     192.168.0.101:6258      6258
DHCP等でIPアドレスが変化する場合は必須
natdの転送に使うポート
ポート変換をなるべく行わない
 (↑方がいいような気がするけど省略可)
これは飽くまで例ですよ例! (^^;;;
1台目(192.168.0.100)のWinMX用(TCP)
 同じく(UDP)
2台目(192.168.0.101)のWinMX用
 2台目以降はポートをずらす必要がある
え,最後の4行ですか? (^^;;; だ〜からこれは例ですっては例! だって他にいい例が思い浮かばなかったんですよぉ….要するに外部から内部のPCに向けてアクセスできるようにする必要がある場合の書き方を示しています.例えば,内部PC(IPアドレス=i.i.i.i)のTCPのポートpに対して接続をさせるてやる必要があるソフトを使う場合は,natd.confの中に
redirect_port   tcp     i.i.i.i:p   p
と書いてやれば,natdは適切に静的NAPTを行ってくれます.ただしこれには制限があります,内部に同じプロトコル(TCPかUDP)で同じポート番号への接続を必要とするPCがもう1台あったとするとそれら2台のPCの望みを同時に叶えることはできません.また,サーバ自身が使っているポートと同じ場合でもダメです.そのような場合はどちらかのPCのポートをそのソフトの設定でずらす必要があります.出来ないソフトだったらもう諦めるしかありません.ところがWinMXはそれが可能で,上の例だと192.168.0.101のPCのポート番号をずらしているのです.まぁだからWinMXを例として取り上げたわけなんですけどね.<(^^;
それからあと,「ファイアウォールとのからみもあるんじゃないのか?」と心配なさるかもしれませんが,後で紹介するフィルタリングルールを利用するのであればそれは気にしなくて大丈夫(NAPTに成功したものは無条件で通しているから)です.もちろんそうでない場合は気にしてくださいね.

2. フィルタリングルール登録スクリプトの作成

さてさて,一番重要なフィルタリングルール登録スクリプトの作成を行います.後で簡単に開設しますが
先に示した方針に従って,ある意味「そこまでするか」というほど厳格に,そして便利さを考慮したルールを作成してみました.当初は単なる一つのスクリプトでしたが,いつの間にやら といった機能を盛り込んだスクリプト集になってしまいました.残念ながら現時点では FreeBSD で IPFW を使う場合にしか対応していませんが,フレッツの3ヶ月無料期間が終わる前(解約する前)にIP Filter対応やMPD対応は済ませたいと思ってます.
2.1. 2種類のフィルタリングルールを用意しました
今回用意したスクリプト集に含まれるIPFWルール記述ファイルは2種類のものを用意してあります.静的ルールのみで構成されているものと,動的ルールを取り入れたものです.この2つは受信したUDPパケットの扱いに違いがあります.UDPはコネクションを張らないので,受信したパケットがこちらからのアクセスに対する応答なのか,それとも不正なパケットなのかを区別するのが難しいのです.
●静的ルールバージョンでは,1024番以降のパケット全てを応答とみなして受け入れるようにしています.1024番未満はwell-known portと呼ばれる重要なサービスのための領域で攻撃されると危険なものがいろいろありますが,1024番以降にはそれがあまりない(0ではありませんが)ため,許可してもまぁ問題無いですし,通常,応答が返ってくる場合は必ず1024番以降だとわかっているからです.一部のデーモン(ntpd,dhclient等)は1024番未満を送信元とするUDPパケットを使いますが,そのようなUDPパケットには個別に対応しています.
●一方,動的ルールを取り入れたバージョンは送出したUDPパケットのポート番号を覚え,一定時間だけ送信元と宛て先のポート番号が正反対のパケットを許可するルールを自動的に作ります.このおかげで,送出パケットと全く正反対のポート番号を持つパケットが一定時間内に返ってきた時だけ,それを応答パケットとしてみなして許可することができるのです.一定時間が経つとこのルールは消えるので,いつまでも開きっ放しになることはありません.
ただし動的ルールにも欠点がないわけではありません,まずUDPに対する動的ルールにはごく最近のFreeBSDで対応されたので,ちょっと古めのFreeBSD(少なくとも4.3-RELEASEでは不可でした)では対応できません.
画面7. UDP用の動的ルールを取り入れたバージョンを使えるか否か確認する方法
# sysctl -a | grep dyn_udp_lifetime
net.inet.ip.fw.dyn_udp_lifetime: 10
確認するためにはこう打つ
"dyn_udp_lifetime"についての行が表示されればOK
また,動的であるがゆえに多少動作が重くなります.一度に多数のアドレス・ポートにアクセスを行うとそれだけ一時的に覚えていなくてはならないルールが増えますので,動的ルールの書かれている行は場合によっては他の行の数百行分の処理になると言われています.とはいっても自宅でのトラフィックは高が知れていますのでまぁ古いPCでない限りは問題無いでしょう.しかしながらこの後紹介する動的ルールバージョンでは念のためにそれも配慮し,動的ルールの記述を後のほうに配置しています.
それからこれは些細なことですが,静的ルールにおいては許可されていた1024番以降のポート宛のパケットも動的ルールでは基本的には全て破棄されるので,デフォルトではUDPを使うUnix系のtracerouteコマンドに応答できなくなります.Windowsの場合はデフォルトで,Linuxの場合は-Iオプションを付けるとICMPでtracerouteを掛けるようになっていますので受け入れられますが,FreeBSDのtracerouteはICMPではできませんので我FreeBSDからのtracerouteは無理ということになります.まぁここは利便性より安全性を優先したということで,それくらいは我慢しましょう.「それでもやりたいんだ!」という方は,ctraceというソフトでできます….ちなみにFreeBSDのportsにも収録されていたりします.(→/usr/ports/net/ctrace)
2.2. フィルタリングルールの概要&ダウンロード
それぞれのルールを下記の表2にまとめましたのでご覧下さい.そして多少手直しをして使う場合は参考にして下さい.また,それぞれの題名をクリックするとスクリプト集に含まれるルール記述ファイルだけを見ることができます.
(スクリプト集自体のダウンロードはこちらです.)
表2. フィルタリングルールの概要
行番号 静的ルールバージョン 動的ルールバージョン
1000〜9999 不正なアドレスを持つパケットの破棄
  • Land Attackからの防衛
  • IP Spoofingの阻止
  • プライベートIPアドレスの侵入(または流出)を阻止
10000行台 自分の管理下にあるネットワーク内のパケットの全許可
  • 内部ネットワークのパケットの全許可
  • ループバックパケットの全許可
20000行台 NAPTパケットの処理
  • 下り
    • natdとの受け渡し
    • NAPT処理後のパケットの許可(2箇所)
  • 上り
    • NAPT処理前のパケットの許可
    • natdとの受け渡し
    • NAPT処理後のパケットの許可
NAPTパケット(下りのみ)の処理
  • natdとの受け渡し
  • NAPT処理後のパケットの許可(2箇所)
30000行台 本サーバ提供サービスへのアクセスの許可
  • 確立済TCPパケットの全許可
  • WWW接続要求許可
  • Secure WWW(https)接続要求許可
  • FTP接続要求許可
  • SSH接続要求許可
  • MTA(smtp)接続要求許可
  • MUA(pop3)接続要求許可
  • 一部のICMPの受け入れ,応答を許可
40000行台 本サーバ自身の外部アクセスの全許可
  • 確立済TCPパケットの全許可(30000行台で許可済)
  • 本サーバから外部へのTCP接続要求全許可(静的ルールは20000行台で許可済)
  • 外部からのFTP Activeモードで必要なFTPデータポートへの接続許可
  • 本サーバから外部へのUDPパケットを全て許可
  • UDPの1024番以降の本サーバ宛のパケットを全て許可(全て応答とみなす)
  • UDPの1024番未満のものの一部(NTPとDHCP)を許可
  • ICMPパケットの送出と受信を一部許可する
本サーバ自身の外部アクセスの全許可
  • 確立済TCPパケットの全許可(30000行台で許可済)
  • 本サーバから外部へのTCP接続要求全許可
  • 外部からのFTP Activeモードで必要なFTPデータポートへの接続許可
  • UDPにおいて,本サーバが外部に送ったもの及び,それに対する応答(一定時間内に帰ってきたアドレスが正反対のもの)を許可
  • ICMPパケットの送出と受信を一部許可する
50000行台 無し NAPTパケット(上りのみ)の処理
  • NAPT処理前のパケットの許可
  • natdとの受け渡し
  • NAPT処理後のパケットの許可
60000行台
(オプション)
フレッツスクウェアへのアクセスの許可(フレッツスクウェア側の壁に対するルール)
  • 1000〜9999行と同様の処理(攻撃からの防衛と)
    • 攻撃からの防衛
    • プライベートIPアドレス(フレッツスクウェア用以外)の通過阻止
  • 内部ネットワークからのアクセスを全許可
  • 本サーバからのアクセスを全許可
65534行 規定されていない全てのパケットを不正とみなし,破棄してログを取る.
2.3. スクリプト集のインストール・設定
さて,スクリプト集を使用する場合はインストールと若干の設定が必要になります.インストールはスクリプトで書かれた対話型インストーラによって面倒臭いコピーやパーミッションの設定が自動で行われるようになっています.
設定は…,多機能になったためにちょっと増えていますが….主なものは といったことです.詳しくはとにかく付属ドキュメントをご覧下さい.
上記の「ファイアウォールのカスタマイズ」というのはリッチなサーバ(一台に何でもやらせるサーバ)を構築するには必須です.主なものはあらかじめコメントアウトした形で書いてありますので,必要なもの(HTTP や FTP や SSH などなど…)があったらそこのコメントを外してください.そうしないと単なるブロードバンドルータと同等になってしまいます.
2.4. スクリプト集の構成
図にして説明しますのでしばらくお待ちください.

3. /etc/rc.confの編集

FreeBSD(正確に言うとさらにバージョン2.2.2以降)において,/etc/rc.confは起動時に各種の設定を行うためのファイルです.このファイルをエディタで開き,画面11の通りの編集を行います.項目が既にあれば後ろの値をこのように書き換え,無ければ項目自体を追加します.
画面11. /etc/rc.confの編集
firewall_enable="YES"
firewall_script="/usr/local/richscripts/bin/regfw.sh"
firewall_quiet="NO"
         :
natd_program="/usr/sbin/rtprio 5 /sbin/natd"
natd_enable="YES"
natd_interface="ethA"
natd_flags="-f /etc/natd.conf"
         :
ipfilter_enable="NO"
         :
ipfs_enable="NO"
         :
ifconfig_ethA="DHCP"
ifconfig_ethB="inet i.i.i.i netmask m.m.m.m"
         :
gateway_enable="YES"
         :
ppp_enable="NO"
IPFWの有効化
IPFW用ルール登録スクリプトを指定
登録中の画面出力をする

natdプログラム(処理優先度を高めにしている)
natdの有効化
natdを連携させるNICドライバ名
natdに渡す引数

ipfilterは同業者であり無意味なので無効にする

ipfsも無効にする

外部NICのアドレスをDHCPで決める(PPP環境では当然不要)
それに対する設定も追加する

本サーバをgatewayとして使う

OS起動によるPPP起動を無効化する
ethAというのは図1,2で出てきたように,外部ネットワーク用NICのドライバ名を表していますので,その名前に適宜置き換えて記述してください.今回紹介する方法ではとにかくこの画面の通りに書き換えればいいのですが,ちょっと不親切かと思うので軽く説明します.
編集が終わったら終了してください.
注(おまじない)
おまじないとして付け加えた rtprio というプログラムは,その後に書かれたプログラム(プロセス)をどの程度の優先度で実行するかを決めるためのものです.最初の引数が5となっており,0-31の範囲で指定可能なこの値としてはかなり高い優先度にしてあります.それではなぜこのnatdに対しては高い優先度を指定しているのかを簡単に説明します.
IPFWで指定するフィルタリングはOSカーネル内部で行われていますが,natdが担当するNAPT処理はユーザーランドといって各ユーザーが実行している多くのプログラム(コマンド)の中の1つとして実行されています.つまりカーネルという階級から見ればnatdは庶民階級の一人に過ぎません.カーネルは自分に必要な資源(処理能力)をさきに確保し,残りを庶民階級プログラム達に分け合うことになります.すると多くの庶民階級プログラムが走るようになればなるほどnatdに与えられる資源も減ってしまいます.しかし,natdは他の様々なプログラムにとって重要です.図2のように,外から入ってきた全てのパケットはNAPT処理を行うべきかどうか判断するためにnatdに入りますので,natdの処理能力が低下するだけでルーターとしてのスループット,および他の各種サーバプログラム(Web,FTP,MAILなどなど)のデータ転送スピードも低下してしまいます.
従ってnatdは庶民階級プログラムではあるものの,他のものより優先的に資源を与えてやるほうが全体としての性能を維持することができます.そこで,rtprio というプログラムを使って0-31まである庶民階級の5を与え,高い優先度で資源を与えるようにしているというわけです.
そんなに重要なプログラムならカーネル階級にしてしまえばいいのですが,そうなっているのが実は IP Filter + IP Nat なのです.こちらの方が高いスループットが得られると言われるのはそのためです.そういうこともあり,またUPnP(linux-igd)とも相性がいいらしいのでこっちへの乗り換えを検討していたりします.

4. (参考)/etc/dhclient-*-hooks(PPPな場合は/etc/ppp/ppp.linkup)

これらのファイルは,dhclient(DHCPクライアント)やPPPが新しいIPアドレスと取得してきた直後に呼び出されるスクリプトです(ppp.linkupはスクリプトとはちょっと違いますが…).呼び出された時には,新しいIPアドレス等も受け取れるようになっています.従って,IPアドレス取得のタイミングでファイアウォールルールを登録したり,DDNSの更新をしたいと思ったらこれらのファイルに細工することから始まります.
やはり本スクリプト集でもこれらのファイルに手を入れており,ここからメインのスクリプトを呼び出すようにしてあります.詳しくは
スクリプト集の構成をご覧下さい.
4.1. dhclient-*-hooksのパーミッション
厄介なことに,dhclientの古いバージョンではdhclient-*-hooksのファイルに実行権限を与えておく必要があります.(少なくともFreeBSD 4.3-RELEASEに組み込まれているバージョンでは必要でした.) そうしないと,せっかく書いたこれらのファイルが無視されてしまいます.実行権限が必要かどうかの確認は画面14のようなコマンドを打ち込んで"-x"という表示が出てくるか否かでわかります.もしそれが出てきてしまったら("-f"だったらそのままでよい),画面14の続きのコマンドを打ってこれらのファイルに実行権限を与える必要があります.ちなみに本スクリプト集ではインストール時にインストーラーがそこらへんのチェックも行うようになっています.
一方,ADSL等のPPP環境の場合は/etc/ppp/ppp.linkupのパーミッションをどうするかということになりますが,これは単に読み込み権限を与えておくだけでよいようです.

5. ログカウントを毎日初期化するようにする

この設定は不正パケットのログを特に気にしない(取りたいとは思わない)のであれば省略しても構いません.取りたいと思う場合は設定してください.
最近のバージョンのデフォルト設定では意図的な不正パケットの嵐によってログを記録するディスクが溢れてしまう事がないように,ある一定回数を超えると不正パケットの記録を止めるようになっています.しかし,そのカウントをクリアしなければ嵐が治まった後もずーっとログを取らなくなってしまいます.そこでこのカウントを毎日クリアすることで,1日毎に設定した最大回数までログを取れるようになります.ちなみにデフォルトでは100になっているようですが,richsvfwスクリプトの中では最終行のみ5000回までログを取るようにしてあります.
作業内容は,画面15のようなファイルを新規作成して,その中に画面16の内容を書き込んで,最後に実行権限を与えるだけです.
画面15. ログカウントを毎日初期化するようにする
# vi /etc/periodic/daily/900.clear-ipfw-count
# chmod 755 /etc/periodic/daily/900.clear-ipfw-count
エディタでファイル新規作成し…
それが終わったら実行権限を与える
画面16. 900.clear-ipfw-countの内容
#! /bin/sh

FWCMD="/sbin/ipfw"

$FWCMD z > /dev/null

exit 0

6. 再起動しておしまい

あとは
前にやったように再起動をすればおしまいです.再起動は困るというのであれば再起動せずにできなくもないですけど,ifconfigの設定,natdの起動,gatewayの有効化,IPFWフィルタリングルールの登録等を手動でやらないといけないので面倒ですよ.それに,ここまででしてきた設定が正しく行われていて,起動時にもきちんとIPFWとnatdが作動するようになっているのかを確認する意図もあります.というわけで再起動してしまいましょう.

使い心地は?

お疲れ様でした….これでブロードバンドルータに勝る柔軟で強固なファイアウォール&NAPTが出来上がったと思います.それはよいとして,気になるスループットはどうなのでしょう? というわけで簡単ながらその検証をしてみました.

しかしぢつは…

ノートPCで立てている場合は1つ致命的な問題があるのです.それは…

100Mbpsを実現するにはCardBus規格のNICが必須だが,現状では使えない…
ということです.これは痛いです.PC-Cardでも100Base-TX対応の製品はあることはありますが,それはその信号に対応しているというだけであり,PC-Cardの性能からいって100Mbpsを叩き出すことは絶対に不可能なのです.というわけで,マシンパワーを出しきらずして10Mbps止まりだったりします….なんてこった! しかし秋頃に出ると言われているFreeBSD 5-STABLE(またはSTABLEブランチからのRELEASE),これが出ればCardBus対応になるので一気に解決するはずです.いゃ,既に出ている5.0-CURRENT(RELEASE)を使うという手もありますが,安定版ではないものをサーバ用途に使うというのはちょっとねぇ….というわけで,もう少しで出るであろう5-STABLEを待ちましょう!

じつは,既に5.0-RELEASEが出ていますので使ってみました.しかしさすが開発版であるCURRENTからのリリースということだけあって,私が試した限りのCardBusネットワークカード,3Comの3CXFE575CT(xlデバイス)とアライドテレシスのLA100-CardBus-T(dcデバイス)の結果は悲惨なものでした.一応認識はするもののとにかく通信ができず,watchdog timeout になったり,最悪フリーズしました….やはりSTABLEからのリリースを待つしかなさそうというのが私の結論です….

5-STABLEが出たその時は?

5-STABLEが出たその時を想定して簡単な実験を行ってみました.ノートPCとはいえ,今時のものには大抵PCI接続の100MbpsNICが内蔵されていますので,ここを通してのスループットを計ってみました.

実験(1)

実験内容は下記のとおりです.

結果(1)

結果は…,なんと10.2Mbpsでした.そんなバカな〜,とか思いながら試行錯誤しているうちにnatdを使わないで転送してみると一気に60.7Mbpsに跳ね上がりました.natdってそんなに重いのか??? かといってこれを使わないわけにはいかないしなぁ….

実験(2)

もしやと思って後日,メモリを買ってきて増設することにしました.手持ちのノートPCにはメモリスロットが2つ付いているので,64MBのDIMMを一枚外し,256MBのDIMMを付けて合計320MBとしていざ再実験です.

結果(3)

結果はnatdを使っても75.9Mbpsが出ました.「なんだ,やっぱりメモリのせいだったのか〜!」 EthernetでTCP/IP転送を行うと,ヘッダーなど付加データ分を除いた実質的なスピードは8割程度と言われているのでかなりいい線いっていると思います.しかも今回実験したFreeBSDではApache等別のプロセスも動いているというハンディーキャップがあるにもかかわらずです.これなら高速スループットを謳っているブロードバンドルータにも十分対抗できますね.

考察(追記)

natdを使うと途端にスループットが落ち,ところがメモリを増設すると一気に跳ね上がるという結果となりましたが,これも
(注)で触れたように,natdがユーザーランドプログラムであるためのようです.
natdを使う場合,カーネル側(IPFW)とユーザーランド側(natd)との間でデータ(この場合はパケット)転送が行われます.階級の異なるカーネルとユーザーランドプログラムとでは使用するメモリ領域がきっちり分けられているため,データはポインタ渡しではなくいちいち実体を渡すことになります.そして,特にユーザーランド側のプログラムはカーネル側よりも実行時間が短いという特徴があります.この調整をとるために大量のバッファが必要となります.しかし最初は領域が不足しており,すぐにバッファが満タンになってスループットが低下していたようです.これはメモリを増量した途端にスループットが飛躍的に上がったという結果からも説明がつきます.
よってnatdを使うときは,それがユーザーランド実装であることに留意しておくことが重要というわけですね.

結論

FreeBSDも能力的には結構イケます! ノートPCではまだその能力をフルに発揮できませんが,あと数ヶ月9月頃まで待てばCardBus対応になるのですからその日が待ち遠しいです.どうしよう,そうなったら….Bフレッツにでも乗り換えなきゃダメか? (^^;


とりあえずNTPでもやらせるか

NTPって何?
(前置きなんで先行ってもいいです)

NTPというのは"Network Time Protocol"の略で,よくずれがちなコンピューターの 時計を修正するためのプロトコルです.これを使えば コンピューターの時計を非常に正確に保つ ことができるようになります.
といってもNTPというプロトコル自体が正確な時刻を生み出すわけではもちろんなく, コンピューターが持っている時刻を非常に正確に伝える/受け取る という機能を備えたプロトコルです.

NTPの優れた点

〜情報を使えるには時間が掛かる〜

例えばある一人の人間が正確な時刻を刻む時計を持っていたとして, 耳伝いで次々と他の人に時刻を知らせるような場合を考えてみて下さい. 最初の人がいくら秒単位で正確な時刻をわかっていても,

というような要因により,伝えるたびにどんどん不正確な時刻になってしまいます. これはいくら動作の素早いコンピューターとて同じことで, コンピューターの処理速度による遅延,情報を伝達する経路による遅延などによって 時刻がコンピューターからコンピューターへ伝えられるたびに どんどん不正確なものになっていきます.
特にインターネットという伝達経路の場合,情報が遅れて伝わる様子は人間でも 認識できるほどに遅い場合がありますよね.
当研究所からwww.google.comにpingを送ってみた場合の応答
> ping -c 3 www.google.com
PING www.google.com (216.239.33.101): 56 data bytes
64 bytes from 216.239.33.101: icmp_seq=0 ttl=40 time=171.072 ms
64 bytes from 216.239.33.101: icmp_seq=1 ttl=40 time=141.164 ms
64 bytes from 216.239.33.101: icmp_seq=2 ttl=40 time=147.995 ms

--- www.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 141.164/153.410/171.072/12.796 ms
この例ではこちらがpingを送ってから返事が届くまでに0.15秒ほど 掛かっていることがわかります.インターネットの遅延は, 衛星中継で日本のニュースキャスターと現地レポーターが会話をしている様子を 想像して頂くと近いかもしれません.

〜遅延時間の見当をつける〜

「どうしても遅れるんだからしょうがない」では, NTPは大して優れていないプロトコルで終わってしまいます. が,NTPはそれでは終わりません.
先程のpingの例がありましたが,pingコマンド出力結果の最後の行に 遅延時間の統計をとっている"round-trip"という行があります. 左から,最小値,平均値,最大値,標準偏差です. いくら遅延が生じるからとはいえ,毎回毎回まったく予想もつかない時間に なるわけでもなくだいたい予想がつきます.長い間観察すればするほど, その経路がどれくらいの遅延を持つのかの確かな見当がつくようになります.
NTPはこの性質を利用して時刻を伝えています.送信側が持っている時刻を 送ると同時に,送受信に使われている経路で発生する遅延の統計をとり, 受信側は伝えられた時刻とその遅延に関する統計から 自分に設定すべき時刻を決定します. 従って,NTPデーモンは動かし始めた直後よりもある程度動かしておいてからの 方がより正確な(送信側の持つ時刻に近い)時刻を持つようになります. しかもかなり正確です.

〜正確な時刻を持つNTPサーバ〜

NTPは正確な時刻を作り出すわけではなく,飽くまで正確に時刻を伝えるだけです. つまり正確な時刻が欲しくても 正確な時刻を持つサーバがどこかに無いと意味が無い わけです. しかしそこはちゃんとそういうサーバが用意されていて, 誰でも利用できるように公開されています.
公開NTPサーバは
ここで紹介されているようです.この正確な時を刻むNTPサーバと 通信することで,皆様のPCにも正確な時を刻ませることができるというわけです.

〜閏秒も気にならない〜

閏秒というものをご存知ですか? これは地球の自転が毎日一定の周期ではないこと (摩擦により日に日に減速していて周期が延びていっているらしい)により, それによるズレを修正するべく最高で年に2回(日本時間では1/1と7/1の朝8:59〜9:00), 一秒を追加したり削除したり(制度上は削除も可能だが,実際に削除されたことはない) するものです.
地球の自転周期の変化を長期予測することは難しいらしく, 閏年のように厳密な規則(
グレゴリオ暦)が規定されていません. 従って,『来年(再来年,3年後…)は閏秒の入る(入らない)年である』ということは わからないのです.ということで普通の時計には閏年を考慮したものはあっても 閏秒まで考慮したものはないため,どんなに正確に1分,1秒を刻む時計であっても閏秒が発生すると±1秒狂うことになります.しかも世界中の時計がです.

昔,閏秒が挿入されるまさにその瞬間にNTTの117を聞いていたことがありましたが, 最後の10秒間(8:59:50〜9:00:00)だけが1.1秒ごとに数えられ(ピッ…ピッ…と鳴って), 11秒を10秒に扱うという方法によりウマいこと閏秒を挿入されていたのを覚えています.

しかし公開NTPサーバから正確な時刻を取得していればそんな心配は無用なのです. 当然自宅にNTPサーバを用意しても閏秒の調整が行われる瞬間,時計はズレますが 参照している公開NTPサーバは当然閏秒も考慮して時を刻んでいる(ハズ)なので すぐに修正されます.よって, 公開NTPサーバから時刻を取得しているコンピューターは世界中のどんなに精度の高い時計よりも正確 ということができるのです.

NTPを利用するとこんないいことが…

NTPを利用して正確な時刻をPCに持たせるとこんないいことがありますよ.

その1. とにかく正確なのはうれしい

うれしいですよね.(*^^*)

その2. 不正アクセスの被害届を受理してもらえる?

これは聞いた話ですが,何かしらの不正アクセスを受けて 然るべき機関に被害届を提出しようと思った場合, 正確な時刻の記録されたアクセスログを提供できないと相手にされないらしいです. 受け付ける側としても正確な時刻の記録されたログがなければ不正アクセス犯を 追跡する手がかりが1つ無いことになりますので捜査がやりづらくなります.
また,正確な時刻のログを残しているかどうかはサーバ管理者の日頃の危機管理意識の 程度が現れる要素の1つとされており, そういう意味においても相手にしてもらえないのかもしれません.

その3. キャプチャPCでのタイマー録画が正確に行える!

ビデオデッキなども,テレビで放送されている時報から内蔵時計の時刻を 調整してくれる機種があったりして便利ですが,今やPCでもHDDでビデオ録画を 行う時代.PCにもやはり正確な時刻を持っていてもらいたいですよね. このリッチなサーバ構築(仮)でも『cronでビデオキャプチャのお手伝い』の話を する時に紹介しますのでお楽しみに….

さぁ一家に一台! NTPサーバ

NTPサーバはここまででお話ししたように正確な時刻を提供するのに欠かせません. 実はWindowsにもNTPクライアントプログラムがある のでそれを動かし,参照するNTPサーバとして先程お話した公開NTPを見せれば 今すぐ(わりと)正確な時刻が取得できます.

NTPサーバについては,Windows NT Server系にはあるらしいですが それ以外は聞いたことがありません.フリーソフトではあるのかな? ちなみに桜時計にはSNTPサーバとしての機能ならありますが, SNTPはSimple NTPの略であることが物語っているようにNTPの簡易版であり, 経路の遅延を考慮しないプロトコルになっています.

ですがここはもう少し正確な時間を取得&提供すべく,NTPサーバを立てましょう. せっかくリッチなサーバを目指しているのですから….というか, 自宅サーバにとってあっても無くてもそれほど問題ないこの機能こそ 当研究所のテーマとしているリッチ(余計なまでの栄養)さにふさわしい!

いゃ,そうでなくても自宅にNTPサーバを置くことには下記のような意義があります.

その1. 公開NTPサーバとインターネット回線の負荷低減

公開NTPサーバリストのところでも紹介しましたが, このリンクで紹介されているたった数十(本当は他にもあるけどそれでも数百?) のサーバで全世界のコンピューターのほとんどの面倒を見ているのですから, それらのNTPサーバには相当の負荷がかかっています.NTPというプロトコル自体に 正確に時刻を伝える機能があるのですから,自宅から公開NTPサーバにアクセスする PCは一台に抑え,残りのPCはそのPCから正確な時刻をもらうようにすることで 外部にやさしいネットワークを作りましょ…ってことです.

その2. (Windowsの桜時計で)更新開始したまま止まることがなくなる

先程Windows用のNTPクライアントとして紹介した(リンクを貼った)桜時計ですが, 公開NTPサーバなどの遠くにあるNTPサーバを参照させるとたまに『更新開始』と メッセージが出たままそれっきりになってしまうことがあります. 参照させるNTPサーバとして指定したサーバからの応答に時間が掛かったり, あるいは応答が帰ってこないとそうなってしまうのかもしれません.
ハッキリしたことはわかりませんが,これは自宅にNTPサーバを置いて それを参照させるようにすることで直るようです.

それでは,次の節からようやく設定方法を説明します.

んー,リッチな前置きだ….

NTPサーバの立て方

それではNTPサーバの立て方です.NTPサーバの機能に関しては, FreeBSDが標準で持っており,それを利用する方法を説明しますので 他のOSを利用されている方にとっては参考になる部分が少なめな気がしますが ご了承ください.
あ,了承は1秒でなくても構いません, NTPサーバが立てられさえすればあとは自動的に修正されますから.(謎

0. NTPデーモンのインストール

FreeBSDには標準で入っていますが(古いバージョンはわかりませんが…), FreeBSD以外のUnixをお使いの場合は NTPをインストールしないといけないかもしれません. もし,その必要がある場合は 名前からしてNTPなサイトwww.ntp.org に行ってNTPデーモン(xntpd)をダウンロードし,インストールしましょう. その詳細は略します.(略すというより当研究所では実践していなため 無責任に書かない方がいいと思いますので….)

1. 公開NTPサーバを選ぶ

まずは先程紹介した公開NTPサーバリストのページから 手近なものを選んできます.その紹介したページの最後に"Primary (stratum 1)"と "Secondary (stratum 2)"のサーバリストがあり,ここで紹介されているサーバを どれでも使うことが出来ます.
PrimaryとSecondaryの違いは何かというと,Primaryは 正確な時計(原子時計)などから直接な時刻を取得しているのに対し, SecondaryはそのPrimaryから時刻を取得しています. 従って理屈ではPrimary Time Serverから時刻を取得する方がより正確な時刻を 取得できることになりますが,自宅のPCで使うのであれば どちらでも全くといっていいほど問題無いと思います. どこのNTPサーバを選ぶかは,

  1. リスト中の"Service Area"に自分のいる地域(日本ならJapan)があること
  2. その中でもネットワーク経路的に距離が短いもの
という点に気を配って選ぶようにしましょう.自宅で使うんだからPrimaryも Secondaryも気にしなくていいです.というかPrimaryは人気があるため, Secondaryを使ってあげるようにしましょう. Primaryにこだわるくらいなら, サーバとの距離にこだわる方が結果的により正確な時間を得られる気がします. それから2番目(距離)の選択基準についてはわからなければテキトーに選びましょう. なるべく自宅から近いところを選ぶことによってトラフィックの軽減 (インターネット回線の渋滞緩和)に貢献すると共に, NTPでもカバーしきれない小さな誤差を軽減できるから… と思うわけですが,だいじょーぶ! 自宅で使うんだから研究機関級の精度は必要ありませんよね.(とかいつつ,うちも研究所を名乗ってますけどね… ^^;)
で,どれかに決めたらそのサーバのアドレス(IPアドレスまたはドメイン名)を どこかにメモしておいて下さい.後で設定を行う際に利用しますので.

2. 設定ファイルを作る

参照させたいNTPサーバの指定には設定ファイルが必要になりますので, このファイルをつくります.FreeBSDにはNTPデーモンは標準で インストールされていますが,設定ファイルは標準では存在しないので 新規作成ということになります.設定ファイル名およびパスは標準では /etc/ntp.confになります.これ以降の作業はrootになって行います.

エディタでNTP設定ファイルを作る
> su -
Password:
# vi /etc/ntp.conf
rootになって…
パスワードを入力して…(もちろん打った文字は見えません)
エディタで/etc/ntp.confを作る
エディタはviにしましたが,慣れないとパニックを起こすほどクセがあるので FreeBSDでは"vi"の代わりに"ee"というエディタもありますので,"ee /etc/ntp.conf" でも構いません.
さて,ntp.confの内容は下記のように書いておきましょう.当研究所では, 参照先とする公開NTPサーバに
ここ で紹介されているサーバを使っています.試験サービスということですが, なるべく負荷を分散させようということで使わせてもらっています.
サーバ名は,ドメイン名でなくIPアドレスを書いています. ドメイン名でもいいのですが,NTPサーバの場合は決まりきったIPアドレスなので DNSサーバの世話にならずに済むIPアドレスで指定することが推奨されているようです.
エディタでNTP設定ファイルを作る
server 210.173.160.57
driftfile /var/ntp/ntp.drift
参照先公開NTPサーバの指定
ドリフトファイル(内蔵時計誤差調整に使う)の指定
2行目はドリフトファイルというものをどこにどういう名前で置くかについての記述です. どこにどういう名前で置くべきかわからないというのであれば このように書いておきましょう.
まぁこの行は書かなくても動作することはしますが,書かない場合は /etc/ntp.driftがドリフトファイルの場所として指定されたものと見なされます. しかしUnixでは,刻々と内容が変わったり, あるいは新しいファイルができるようなものは /varというディレクトリ以下に置くのが望ましいとされていますので, やっぱりきちんと置くべき場所を書きましょう.
ちなみに,/varの"var"とはvariable(可変・変数)の略らしいです.

(参考) ドリフトファイルって何物?

そもそもドリフトファイルとは一体何なのかというと,FreeBSDのマニュアルによれば 『ローカルの時計発振子の周波数オフセットを マイクロ秒(100万分の1秒)単位で記録しておくファイル』だそうです. わかりやすく言うと『そのコンピュータの時計が1秒間で何マイクロ秒ずれるか』 ということだと思います. (ネットワーク遅延計算用ではありませんでした,すいません….)
定期的(1時間毎)に更新するということなので,恐らく定期的に自分の時計の経過時間と 外のNTPサーバから得られた正しい(と見なしている)経過時間を比較することで この値を求めているのではないかと思います. もし仮にこの値が正確に求められたとしたらそれ以後は外のNTPサーバに頼ること無く 自律的に誤差を修正できることになりますね.まぁ実際には室温の変化などによって この値(つまり時計のずれの激しさ)も少しずつ変動するとは思いますけど….とはいえ, ドリフトファイルのおかげで, たとえ外のNTPサーバと通信ができなくなってしまっても しばらくの間ならば正確な時を維持していられると言えそうです. ちなみに,現在当研究所で稼動中のサーバにあるこのファイルの値は 27.971 となっているので,仮に一日あたりの誤差を計算してみると
27.971[μs/s] ・ 10-6-1] ・ 86400[s/day] ≒ 2.41[s/day]
ということで,…なるほど確かに1日あたりの誤差としては妥当な値ですね.

3. ドリフトファイルの居場所を用意する

設定ファイルの中で『ドリフトファイルはここです』と指定しましたが, そのディレクトリおよびファイルはまだ存在しなていません. 指定されたディレクトリが存在すればファイルはその中に勝手にできますが, ディレクトリは勝手に作ってくれませんのでこれだけは手作業で作っておきます. ディレクトリは普通にmkdirコマンドで作ればOKです.

ディレクトリを作る
# mkdir /var/ntp
NTP用ディレクトリを作る(普通にmkdirで作ります)
今回は一応NTP用のディレクトリを作ってその下にドリフトファイルを 収めるようにしましたが,/varの直下に置いても構いません. ここらへんは気持ちの問題ですから…./varの直下に置くのであれば ディレクトリを新たに作る必要はありません.なんせ/varはもともとあるはずですから. あ,でもその場合はもちろん設定ファイル(ntp.conf)の内容も /var/ntp/ntp.confではなく/var/ntp.confにして下さいね.

4. 自動的に起動する設定にする

NTPサーバをやらせるPCが起動する際に 自動的に起動させておくようにする方が便利ですのでそのための設定をします.
FreeBSDの場合は,/etc/rc.confというファイルをエディタでいじります.

NTPの自動起動のためのファイル(FreeBSD)を書き換える
# vi /etc/rc.conf
エディタで/etc/rc.confを書き換える
で,そのファイルの中に下記のうちの最初の2行を追加します. もし既にこれらの項目がある場合は,"YES","NO"をこのように直して下さい. 最初の1行は,NTPデーモンではないNTPクライアントプログラムntpdate (時刻調整をしたらすぐ終了する)を起動時に実行するかどうかの設定で, NTPデーモンの使用するポートと競合する可能性があるので使いません. 2行目がNTPデーモンを自動起動するかどうかの設定になります.
NTPの自動起動のための記述内容(/etc/rc.conf)
ntpdate_enable="NO"
xntpd_enable="YES"
xntpd_program="/usr/sbin/ntpd"
xntpd_flags="-p /var/run/ntpd.pid"
ntpdateの自動起動をしない
NTPデーモンの自動起動をする
実行するNTPデーモンのフルパス(無くてもよい)
実行するNTPデーモンに渡す引数(無くてもよい)
下の2行はNTPデーモンの自動起動をする設定にした場合(xntpd_enable="YES")に 実際に実行させるプログラム名とそれに渡す引数を定義するためのものです. 指定しなければFreeBSD標準のプログラムが起動し, 標準の引数が渡されるので無くても問題ありません. しかし,NTPデーモンとしてを独自にインストールものを使いたかったり, 引数を独自に定義したい場合は必要になります.

これで再起動すればNTPサーバが起動します…. でもすぐ設定を変えるたびに再起動が必要なようじゃWindowsっぽくてカッコ悪いですし, まだ少しやることがありますのでもう少しガマンです.

5. ファイアウォールの設定

ファイアウォールで不要な通信を遮断している場合には,NTPサーバを起動する前に 公開NTPサーバとの通信パケットを通過させるような設定にしなければなりません. 追加するルールは次の通りです.

対象となるパケット UDP (本サーバのIPアドレス:123)→(公開NTPサーバのIPアドレス:123)
UDP (公開NTPサーバのIPアドレス:123)→(本サーバのIPアドレス:123)
マッチしたパケットの処理 通過
123というのはNTPで使うポート番号です.NTPの場合はなんと, 送信元のポート番号まで同じ123です.
このルールをファイアウォールをやっている ブロードバンドルータやPCに必要に応じて追加します. 具体的な設定方法はファイアウォール機能を提供している機器の説明を読んで下さい. 本サーバ自体にやらせる方法についてはファイアウォールの説明をする回で説明します.
また,内部ネットワークに対してもファイアウォールが設けてあって 内部ネットワークのPCに対してもNTPサーバとして機能させようとしているであれば 本サーバと内部ネットワークとの間にも123/UDPのパケットを通過させるような設定を 追加してください.

6. NTPデーモンの起動

これでNTPデーモン起動のための準備は全て整ったので いよいよ起動することができます…. が,場合によってはその前にやっておいた方がいいことが1つだけあります.

6.1. 時刻調整

「なんで?」と思うかもしれません….これからNTPデーモンに それをやらせようとしているのですから….しかしやっておいたほうがいいです. というのは,NTPデーモンは時刻を気にしながら動いている他のプログラムに配慮して 急激な時刻の変化をさせないようになっているからです.
もしこれからNTPデーモンを動かそうとしているPCの時計が1時間以上ずれていたとします. …と同時に1時間ごとに何らかのログを取るプログラムが動いていたとします. そして,このPCの時計が急に正確になったらどうなるでしょうか? 1時間分の ログが空白になるか(遅れていた場合), あるいは同じ時刻のログが2つできてしまいます(進んでいた場合). こういうことのないように,NTPは自らのはやる気持ちを抑えて
ゆっ…………………………………………………………………………………………くり
と時間をかけて修正していきます.(しかしあまりにも最初のズレが激しすぎると 面倒くさがって(?)終了してしまうこともあります.)
でも普通は早いとこ正確な時刻になってもらいたいので, そうしたければNTPデーモンを起動する前に一度時計を合わせておく方がいいのです. もちろん時刻を気にするプログラムが動いていないことが前提ですが, 今はそんなもの無い(あるいはあっても気にしないでいられる)ですよね?

時刻調整をするには前の説明でちょっと出てきたntpdateというプログラムを使います.

時刻調整プログラムを実行する
# ntpdate  210.173.160.57
24 Sep 00:01:32 ntpdate[62450]: adjust
time server 210.173.160.57 offset -0.169926 sec
ntpdateコマンドの実行(引数に公開NTPサーバを指定)
コマンドの実行結果(実際は1行で表示される)

6.2. さて起動…

今度こそ本当にNTPデーモンの起動です.再起動…,でもいいのですが WindowsっぽくてカッコわるいのでOSの再起動ナシで起動させましょう.
FreeBSD標準のNTPデーモンを起動させるには次のコマンドを実行します.

NTPデーモンの起動
# /usr/sbin/ntpd -p /var/run/ntpd.pid
#
コマンド実行
特にメッセージはありません.
起動しても特にメッセージが表示されませんが起動はしています. 気になる場合は下記のようにして確認してみてください.
NTPデーモン起動中か否かの確認
# ps -ax | grep ntpd
62457  ??  Ss     0:00.13 /usr/sbin/ntpd -p /var/run/ntpd.pid
実行中のNTPデーモンのプロセス番号を調べるコマンド
プロセスID=62457で実行中であることがわかった…
これでNTPサーバは立ち上がりました.おめでとうございます.

他のPCでの利用のしかた

これで本サーバに正確な時刻を持たせることができました.次は当然, 本サーバだけでなく他のPCも正確な時刻を取得できるようにしましょう.

1. Unixの場合

まずはUnixです.とはいっても本サーバが公開NTPサーバから時刻を取得したのと同じように, 他のUnixでも全く同じ事をすればいいだけです.ntpdでもじっくり合わせるのでもいいですし,ntpdateでその時だけ合わせるというのでもいいです. ただし,今度は参照するNTPサーバとして本サーバを参照させるようにしてくださいね.

2. Windowsの場合

2.1. インストール

先に紹介した桜時計を利用しましょう. インストールは簡単で,桜時計をダウンロードして解凍して好きな場所に置くだけです. 実行ファイルは2種類ありますが,そのWindows PC自身がダイアルアップを行わず, LANを介してインターネットに繋ぐ場合は"SW_NORAS.EXE"の方を使う方がいいようです.
一応基本的なインストールはそれでけですが,ついでにプログラムメニューの スタートアップフォルダにこのプログラムのショートカットを置くのがオススメです. こうすればWindowsの起動時に桜時計が起動して時刻が修正されるようになります.

2.2. 最初の設定

初めて使うときだけは設定が必要です. 最低限の設定として,NTPサーバ/IPアドレスを書く欄に本サーバのIPアドレスを 書き込む必要があります. また起動したら直ちに調整するように『起動時にオンラインにする』のチェックを入れておきましょう. あとは『常駐する』にチェックを入れるかどうかですが,Windows NT/2000/XP では チェックを入れておくことをおすすめします.Windows 9x/Me については, 残りリソースが豊富ならおすすめします.このプログラム自体が そんなにリソースを消費するわけではありませんが,95→98→98SE→Me と バージョンアップするに従ってリソースの残量は厳しくなりますし, 初心者向けの大手メーカー製パソコンや萌ぇ萌ぇアクセサリを いっぱいインストールしているとよけい厳しくなるので, そういう方でしかも「うちのWindowsはよく固まるんだよな」とお嘆きの方は 余計おすすめしません.
いや逆に必要ないかも….だってよく固まるなら 頻繁に再起動すると思いますので,そのたびに時刻が調整されますからね.(^^;

2.3. 使い方

あとは基本的に桜時計を動かすだけです.常駐させていれば 定期的に時刻を調整してくれますし,今すぐ調整したいと思ったら起動させた状態で オンラインボタンを押します(既にオンラインになっているなら, 2度押してオンラインにし直します).
ちなみに常駐する設定にしておくと, このソフトの起動時にはシステムトレイに隠れているので 必要なときはウィンドウを開きます.

2.4. 一つだけ注意

本サーバをNTPサーバとして動かして,すぐに桜時計を動かすと

サーバーの準備がまだのようです(LI=ALARM)
と表示されて時刻が調整されないことがあります. これはそのメッセージの通りで,起動して間もないNTPサーバは 他のクライアントからの問い合わせに答えられません. おそらくNTPサーバ自身が参照先のNTPサーバとの間の経路の遅延時間などを計算中で 他のコンピューターに時刻を教えるどころではないからだと思います.
このメッセージが出たからといってもサーバの設定は間違っていませんので 安心しましょう.この場合はNTPサーバが落ち着くまで待ってあげるしかありません. だいたい10分くらい待てば調整できるようになると思います.




メニューに戻る…