diff --git a/ja_JP.eucJP/books/handbook/internals/chapter.sgml b/ja_JP.eucJP/books/handbook/internals/chapter.sgml index 5ddb989c7f..ef4c0b34c4 100644 --- a/ja_JP.eucJP/books/handbook/internals/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/internals/chapter.sgml @@ -1,1809 +1,3573 @@ FreeBSD の内部 + DMAとはどういったものでどういう働きをするのか 原作: Copyright © 1995,1997 &a.uhclem;, All Rights Reserved. 1996 年 10 月 10 日. 最終更新日 1997 年 10 月 8 日. 訳: &a.jp.yasu; Direct Memory Access (DMA)は, 中央演算処理装置 (CPU)からの干渉なく データを計算機中である場所から別の場所に動かすための手法です. DMA 機能の実装の方法はそれぞれの 計算機アーキテクチャ間で異なるもので あるため, ここでの議論はIBMパーソナルコンピュータ(PC), PC/AT とその互換機における DMA サブシステムの実装と働きに限定します. PCの DMAサブシステムは, Intelの 8237 DMAコントローラをベースにして います. 8237はそれぞれ独立にプログラムできる4つのDMAチャネルを持ち, それぞれどのチャネルもいつでもアクティブにできます. これらのチャネルは順に 0, 1, 2, 3となっています. PC/ATからは, セカンド 8237 チップが追加され,それらは 4, 5, 6, 7と なっています. オリジナルの DMAコントローラ(0, 1, 2, 3)は, 1回の転送で1バイト 転送します. セカンドDMAコントローラ(4, 5, 6, 7)は1回で 隣接する2つのメモリ番地から 16ビット転送します. ここで, 最初のバイトは通常偶数のアドレスになります. 2つのコントローラは全く同じものであり, 転送量が異なるのは セカンドコントローラがシステムに直結しているためです. 8237 は個々のチャネルについて, DRQと-DACKという2つの電気信号を 持っています. その他に, HRQ (Hold Request), HLDA (Hold Acknowledge), -EOP (End of Process)があり, バス制御信号として -MEMR (Memory Read), -MEMW (Memory Write), -IOR (I/O Read), and -IOW (I/O Write)があります. - 8237 DMACは, いわゆる“fly-by” + 8237 DMACは, いわゆるfly-by DMAコントローラです. これは, データの移動を行う際に, データは DMACチップを通過せず, DMACチップに格納されないことを意味します. また, DMACはI/Oポートとメモリアドレス間でのみデータを 転送することができますが, 2つのI/Oポートもしくは2つのメモリアドレス 間ではできません. - 8237 は, 非 “fly-by”モードでは, + 8237 は, 非 fly-byモードでは, 互いに接続された 2つのチャネルでのメモリ-メモリ間でのDMA操作を許可します. しかし, PC メーカは, ただでさえ乏しいこのリソースをこんなふうに 使ったりしません. なぜなら, CPUを使用してメモリ間のデータを動かす方が早いからです. PC アーキテクチャでは, それぞれのDMAチャネルは, 通常 与えられた DMA チャネルを使用するハードウェアがそのチャネルについて DRQ線を使って転送を要求した時のみ動作します. DMA転送の例 DMA転送の発生と処理の手順の例をあげてみましょう. この例では, フロッピーディスクコントローラ (FDC)が ディスケットから1バイト読み込んで, DMAを使って,メモリの0x00123456番地に 格納したいとします. 処理は, FDCが, DRQ2信号(DMAチャンネル2に 対するDRQ線)を有効にして DMAコントローラに要求を伝えることで開始されます. DMAコントローラは DRQ2 シグナルが有効になったことを記録します. するとDMAコントローラはDMAチャネル2がプログラムされ, マスクが かかっていない(有効になっている)ことを確認します. 同様に, DMAコントローラは, 他のDMAチャネルがアクティブまたは アクティブになろうとしていないこと, そしてより高い優先度を持って いないことを確認します. 一旦これらのチェックが完了すると, DMACはDMACがバスを使うために バスを開放するようにCPUに要求します. DMACはCPUにHRQ信号を送ってバスを要求します. CPUはHRQ信号を検出し, 現在の指示の実行を完了します. 一旦プロセッサがバスを開放することができる状態になると, 解放を 行います. 通常は CPU により駆動される信号 (-MEMR, -MEMW, -IOR, -IOW, その他)を すべてハイインピーダンス (ハイともローとも指定しない)状態にした後, CPUは HLDA信号を有効にして DMAコントローラにバスを明け渡したことを 伝えます. プロセッサによっては, CPUはバスを使用しないいくつかの 命令を追加して実行することもできますが, しかし,プロセッサの内部キャッシュや パイプライン以外のメモリから 何か読み出すといった指示に到達したら結局 CPU は待たなくてはなりません. - ここで,DMACが バスを“託される”と, DMACはその + ここで,DMACが バスを託されると, DMACはその -MEMR, -MEMW, -IOR, -IOW 出力信号をアクティブにし, DMACから出力されるアドレスは 0x3456にセットされます.これは 転送しようとする特定のメモリ番地をバイトで 指示するのに使われます. すると DMAC は DMA 転送をリクエストしたデバイスに転送が始まることを 知らせます.これは -DACK 信号をアクティブにすることで行われます. フロッピーディスクコントローラの場合は, -DACK2を アクティブにすることで行われます. バスのデータ線に転送されるバイトにを出力することについては フロッピーディスクコントローラが責任をもつことになります. もし,フロッピーディスクコントローラがバス上にバイトデータを 出力するのに余計な時間を必要としなければ (もし周辺装置がもっと時間を必要とする場合には, READY信号を 経由してDMACに通知します), DMAは 1 DMAクロック待ち, メモリにバス上のバイトデータを格納するために -MEMW および -IOR 信号を解除します. そして FDCはバイトデータが転送されたことを認識します. DMAサイクルは1度に1バイトしか転送しないので, FDCはDRQ2信号を止めて, DMACに転送が終了したことを知らせます. DMACは-DACK2信号を解除して, FDCはバス上へのデータ出力を 停止しなくてはならないことを知らせます. 次にDMACは他のDMAチャネルのいずれかに要求がきていないか チェックを行います. もしどのチャネルのDRQも有効になっていなければ, DMAコントローラは処理を完了して, -MEMR, -MEMW, -IOR, -IOW および アドレス信号をハイインピーダンス状態にします. 最後に, DMAはHRQ信号を解除します. CPUはこれを見ると,HOLDA信号を 解除します. そしてCPUは自らの -MEMR, -MEMW, -IOR, -IOW 信号および アドレス線を有効にし, 命令の実行やメインメモリや周辺機器へのアクセスを 再開します. 典型的なフロッピーディスクの1セクタについては, 上記のプロセスが それぞれのバイトについて1回行われ, 全部で512回繰り返されます. 1 バイト転送される毎に, DMAC 内のアドレスレジスタはインクリメントされ, 同じくDMAC内にある, 何バイト転送すればよいかを示すカウンタが デクリメントされます. カウンタが0になると, DMAはEOP信号を送ります. この信号は カウンタが0であり, DMAコントローラがCPUによって再び プログラムされるまで, これ以上データは転送されないことを 示すものです. このイベントはターミナルカウント(TC)とも呼ばれます. EOP信号は1本しかありません. そして, 一度にアクティブにできる DMAチャネルは一本だけなので, 現在アクティブであるDMAチャネルこそが, たった今処理を終了したDMAチャネルだと言うことができます. もし, バッファの転送が完了した時に周辺機器から割り込みを発生させたい とき, 周辺機器は -DACKn信号およびEOP信号の両方が同時に発信されたか どうかをテストします. その場合, DMACはCPUの介在がなければ これ以上はその周辺機器についての情報を転送しません. その後で, 周辺機器はプロセッサに割り込みを生じさせるために, 何らかの割り込み信号を発生させることができます. PCアーキテクチャ においては, DMAチップ自身が割り込みを生じさせることはできません. 周辺機器とそれに関連するハードウェアが割り込みを生成する責任を 持ちます. また, DMAを使用する周辺機器が割り込みを使用しない 可能性もあります. DMAC が要求を出したときには CPU は常にバスを DMAC に開放しますが, この動作は, DMAC がアクティブになった時にプロセッサが命令を実行するのに かかる時間がわずかに変化することを除いては, アプリケーション, オペレーティングシステムの両方からはわからないということを 理解することが重要です. そのため, プロセッサが確かにDMA転送が完了したことを知るためには, 周辺装置や DMA チップ中のレジスタを調べたり,周辺装置からの割り込みを 受け取る必要があります. DMA ページレジスタ および 16メガ アドレス空間制限 これまで述べたのとは異なり, DMACはアドレス線を 0x0123456 にセットする 代わりに 0x3456 だけをセットすることにあなたは気づいたかも しれません. この理由について少し説明します. オリジナルのIBM PCがデザインされた時, IBMは, DMACと割込み制御チップの 両方を, 8085(8ビットプロセッサで, 16ビットのアドレス空間(64k)を持つ)と 組み合わせて使うように設計されたチップを使うことを選びました. IBM PCが64k以上のメモリをサポートしていたため, DMACが64kを越えるメモリ番地に読み込み又は書き込みを行うために 変更を行う必要が生じました. この問題を解決するためにIBMが行ったのは, それぞれのDMAチャネルに, 読み込み元または書き込み先のアドレスの 上位ビットを保持するための 外部的なラッチを追加することでした. DMAチャネルがアクティブな時はいつでも, このラッチの内容はアドレスバスに書かれて, そのチャネルのDMA操作が 終了するまでそこに保持されます. IBM - はこれらのラッチを “ページレジスタ” + はこれらのラッチを ページレジスタ と呼んでいます. そのため上記に示した例では, DMACはアドレスの0x3456の部分をバス上に 置き, DMAチャネル2に対するページレジスタは, 0x0012xxxxをバス上に 置きます. これらの2つの値が組み合わされてアクセスされるメモリ中の完全な アドレスを形成します. ページレジスタのラッチはDMAチップとは独立であるので, 読み込まれる又は書き込まれるメモリ領域は, 64kの物理的境界を またいではなりません. 例えば, もし DMACがメモリの0xffff番地をアクセスした場合, データの転送後, DMACはアドレスレジスタをインクリメントし, 0x0000番地にある次のバイトを アクセスします. 0x10000番地ではありません. これはおそらく意図されたものとは異なっているでしょう. - “物理的な” 64Kの境界を 8086モードの - 64k“セグメント”と混同してはいけません. + 物理的な 64Kの境界を 8086モードの + 64k セグメントと混同してはいけません. セグメントは, セグメント レジスタに数学的にオフセットレジスタを 加算して作られるものです. ページレジスタにはアドレスのオーバーラップも無く, 数学的に OR を取られることもありません. さらに複雑なことには, PC/ATでは外部のDMAアドレスのラッチは 8ビットしか保持しません. よって8+16で24ビットになり, これは DMAが0から16メガの間のメモリ番地しか指し示せないことを 意味します. 16メガ以上のメモリを持ったより新しいマシンにおいても, 標準的なPCコンパチブルなDMAでは16メガ以上のメモリ番地には アクセスできません. この制限を避けるために, オペレーティングシステムは 16 メガ以下にある物理的な 64k の境界をまたがない領域に RAM バッファを 予約します. そして, DMACはデータを周辺機器からそのバッファに 転送するようにプログラムされます. 一旦DMACがこのバッファに データを動かすと, オペレーティングシステムは本当にデータを 格納したいアドレスにバッファからデータをコピーします. 16メガを越えるアドレスからDMAベースの周辺機器にデータを 書き込む際には, データは16メガ以下に位置したバッファから最初に コピーされなくてはならず, その後, DMACはバッファからハードウェアに データをコピーすることができます. FreeBSDでは, これらの予約バッファは - “バウンスバッファ”と呼ばれます. MS-DOSの世界では, - これらは“スマートバッファ”などと呼ばれます. + バウンスバッファと呼ばれます. MS-DOSの世界では, + これらはスマートバッファなどと呼ばれます. 82374と呼ばれる8237の新しい実装においては, ページレジスタを16ビットで指定して, バウンスバッファを使用しなくても, 32 ビットのアドレス空間全体にアクセスすることが可能です. DMA操作モードとその設定 8237 DMA はいくつかのモードで動作します. 主なモードは, 以下のとおりです. シングル転送モード シングルバイト(もしくはワード)が転送されます. DMAは1バイト毎にバスを開放し, 再び要求しなくてはなくてはなりません. これは一般に, すぐにはデータのブロック全てを転送できないデバイスに よって使用されます. 周辺装置は次の転送の準備ができる毎にDMAを要求します. 標準的な PC コンパチブルなフロッピーディスクコントローラ(NEC 765)は 1バイトのバッファしか持たないので, このモードを使用します. ブロック/デマンド転送モード 一旦 DMAC がシステムバスを取得すると, 最大64kまでのデータブロック 全体が転送されます. もし周辺装置が余分に時間を必要とするときは, 転送を一時中断するためにREADY信号を有効にします. READY信号は過度に使われるべきではなく, 遅い周辺装置の転送の場合は シングル転送モードを代わりに使うべきです. ブロック転送モードとデマンド転送モードの違いは, 一旦ブロック転送が 始まると, 転送カウンタか 0 になるまでそれが行われるところです. DRQ は -DACK が有効になるまでの間は有効でなければなりません. デマンドモードは DRQ が有効な間転送が続けられます. DRQが有効でなくなった場合, DMA はその時点で転送を中断し, バスを解放して CPU に返します. その後, DRQが有効になると, 転送は中断したところから再開されます. データの転送, 特に転送に使われるメモリ番地が16Mを越える場合に, CPU を使った方が効率がよくなるまで CPU の速度が向上する以前の 古いハードディスクコントローラはデマンドモードを 使っていました. カスケード転送モード このメカニズムは DMA チャネルがバスを要求することを許可する ものですが, 接続されたデバイスはバス上のアドレス情報の配置に ついてDMACに代わって責任を持ちます. - これは“バスマスタ” + これはバスマスタ と呼ばれる技術の実装に利用されます. カスケードモードの DMA チャネルがバスのコントロールを受け取ると, DMA は通常行われるようなバス上のアドレスと I/O コントロール信号の 出力を行いません. 代わりに, DMAはアクティブなチャネルの -DACK信号を 有効にします. この時点で, アドレスとバスコントロール信号の供給は DMAチャネルに接続された周辺機器が担当します. 周辺機器はシステムバスの完全なコントロールを行い, 16 メガ以下の任意のアドレスの読み込みおよび書き込みを 行うことが できます. 周辺機器はバスの使用を終えると DRQ 線を無効にするので, DMA コントローラは CPU もしくは他のDMAチャネルに制御を返すことが できます. カスケードモードは複数の DMA コントローラを相互接続するのに 使われます. PC内ではDMAチャネル4がまさにこの用途に使われています. 周辺機器がDMAチャネル0, 1, 2, 3でバスを要求すると, スレーブDMAコントローラは HLDREQ を有効にしますが, この線はCPUではなく, 実際にはプライマリDMAコントローラのDRQ4に 接続されています. その後, チャンネル4になにか仕事があるものと見なしたプライマリの DMAコントローラは HLDREQ を使ってCPUにバスを 要求します. バスが与えられると, -DACK4が有効になりますが, この線は実際にはスレーブDMAコントローラの HLDA信号に 接続されています. スレーブDMAコントローラはその後要求したDMAチャネル (0, 1, 2, 3) に対してデータを転送するか, SCSIコントローラのような バスマスタリングを要求する周辺機器にバスを許可します. このような配線がおこなわれているため, PC/ATシステムの 周辺機器ではDMAチャネルは 0, 1, 2, 3, 5, 6, 7のみが使用できます. 初期のIBM PCコンピュータでは, DMAチャネル0は操作の リフレッシュのために予約されていますが, 最近のシステムでは通常, 周辺機器によって使用することができます. 周辺機器がバスマスタリングを行っている時は, システムバスを保持している間絶えずメモリに もしくはメモリから データを転送することが重要です.もし, 周辺機器がこのように できないときは, システムがメインメモリのリフレッシュを 行なえるようにしばしばバスを開放しなくては なりません. 全ての PC でメインメモリとして使われるダイナミック - RAM は, 中身が “満たされている” + RAM は, 中身が 満たされている ビットを保持するため 頻繁にアクセスされなくてはなりません. ダイナミック RAM は, それぞれが 1 ビットのデータを記憶するコンデンサが たくさん集まって構成されています. これらのコンデンサは充電された 状態で 1, 充電されていない状態で 0 を表します. 全てのコンデンサは放電するため, 1 の値を保持するために, 一定の間隔で電力を加える必要があります. 実際に RAM チップは RAM の適切な場所に電力を送る作業を行ないますが, メモリのリフレッシュ作業が RAM を普通にアクセスする時と 衝突しないように, それをいつ行なうかを コンピュータが休止状態の時に知らせなくてはなりません. もしコンピュータがメモリのリフレッシュを 行なえない場合は, メモリの中身はわずか数ミリ秒で壊れてしまいます. メモリの読み込みと書き込みのサイクルは - リフレッシュサイクルとして カウントされる(ダイナミック + リフレッシュサイクルとして カウントされる + (ダイナミック RAM のリフレッシュサイクルは 実際には不完全なメモリ読み込みサイクルになります)ので, 周辺機器のコントローラが連続するメモリ番地から データの読み込み または書き込みを行う間は, メモリの全てがリフレッシュされます. バスマスタリングはいくつかの SCSI ホストインターフェースやその他の ハイパフォーマンスな周辺機器コントローラに 見られます. 自動初期化転送モード このモードにおいてDMAはバイト, ブロック, デマンド転送を行いますが, DMA転送カウンタが0になると, カウンタとアドレスはDMAチャネルが もともとプログラムされた時のものに戻されます. これは, 周辺機器が転送を要求している間は転送が続けられることを 意味します. 転送領域としてDMACにプログラムされた固定バッファの中で, 出力操作でDMACがデータを読み出す前もって新しいデータを 書き込んだり入力操作でDMACが書き込んだあとに, そこから新しいデータを読み出す作業は CPU が受け持ちます. - このテクニックは, “サンプリング” + このテクニックは, サンプリング 用のバッファが小さいもしくは それを持たないオーディオデバイスによく使われます. - この“環状” バッファの管理は更なる CPU + この環状バッファの管理は更なる CPU オーバーヘッドになりますが, DMAカウンタが0になり, 再プログラムされるまでDMAが停止してしまう ことによって起きる遅延は, この方法でしかなくす事ができない 場合もあります. DMAのプログラミング プログラムされるDMAチャネルは, 通常, 設定を行う前に - “マスクする”べきです. + マスクするべきです. これはハードウェアが予期せずそのチャンネルに対してDRQを有効に した場合, たとえ全てのパラメータが 満たされてない場合や更新されていない場合でも, DMACは それに応答してしまう可能性があるからです. マスクを行ってから,ホストは転送の方向(メモリからI/O, もしくはI/Oからメモリ)と, 転送に使用するDMA操作のモード (シングル, ブロック, デマンド, カスケードなど)を設定し, 最後に アドレスや転送の長さを設定します. 設定される長さはDMACに転送させたい量よりも1少なくなります. アドレスや転送長のLSBとMSBは同じ8ビットI/O ポートに書き込まれます. そのためDMACが最初のバイトをLSBとして, 2番目のバイトをMSBとして 受け取ることを保証するために, 最初に別のポートに書き込みを行なって LSBとMSB の判別を行なうフリップフロップをクリアしておく必要があります. そして,DMAのページレジスタを更新します. これはDMACの外部にあり I/O ポートの別のセットを通してアクセスされます. すべての設定ができると, DMAチャネルはマスクを解除することができます. - そのDMAチャネルは“準備ができた”とみなされ, + そのDMAチャネルは準備ができたとみなされ, そのチャンネルのDRQが 有効になると応答します. 8237のプログラミングの正確な詳細については, ハードウェアデータブックを参照してください. PCシステムにおける I/O マップについても参照する必要があるでしょう. このマップには DMA およびページレジスタのポートがどこに位置するのかを 書いてあります. 以下に完全なポートのマップテーブルを示します. DMAポートのマップ IBM-PCとPC/ATに基づくすべてのシステムでは, 同じI/Oポートに配置された DMAハードウェアを持っています. その完全なリストを以下に示します. DMAコントローラ2に割り当てられたポートは, AT以外のデザインでは 未定義になっています. 0x00 – 0x1f DMA コントローラ #1 (Channels 0, 1, 2 and 3) DMA アドレス および カウントレジスタ 0x00 write Channel 0 starting address 0x00 read Channel 0 current address 0x01 write Channel 0 starting word count 0x01 read Channel 0 remaining word count 0x02 write Channel 1 starting address 0x02 read Channel 1 current address 0x03 write Channel 1 starting word count 0x03 read Channel 1 remaining word count 0x04 write Channel 2 starting address 0x04 read Channel 2 current address 0x05 write Channel 2 starting word count 0x05 read Channel 2 remaining word count 0x06 write Channel 3 starting address 0x06 read Channel 3 current address 0x07 write Channel 3 starting word count 0x07 read Channel 3 remaining word count DMA コマンドレジスタ 0x08 write Command Register 0x08 read Status Register 0x09 write Request Register 0x09 read - 0x0a write Single Mask Register Bit 0x0a read - 0x0b write Mode Register 0x0b read - 0x0c write Clear LSB/MSB Flip-Flop 0x0c read - 0x0d write Master Clear/Reset 0x0d read Temporary Register (新しいバージョンでは利用不可) 0x0e write Clear Mask Register 0x0e read - 0x0f write Write All Mask Register Bits 0x0f read Read All Mask Register Bits (Intel 82374にのみ存在する) 0xc0 – 0xdf DMA コントローラ #2 (Channels 4, 5, 6 and 7) DMA アドレス および カウントレジスタ 0xc0 write Channel 4 starting address 0xc0 read Channel 4 current address 0xc2 write Channel 4 starting word count 0xc2 read Channel 4 remaining word count 0xc4 write Channel 5 starting address 0xc4 read Channel 5 current address 0xc6 write Channel 5 starting word count 0xc6 read Channel 5 remaining word count 0xc8 write Channel 6 starting address 0xc8 read Channel 6 current address 0xca write Channel 6 starting word count 0xca read Channel 6 remaining word count 0xcc write Channel 7 starting address 0xcc read Channel 7 current address 0xce write Channel 7 starting word count 0xce read Channel 7 remaining word count DMA コマンドレジスタ 0xd0 write Command Register 0xd0 read Status Register 0xd2 write Request Register 0xd2 read - 0xd4 write Single Mask Register Bit 0xd4 read - 0xd6 write Mode Register 0xd6 read - 0xd8 write Clear LSB/MSB Flip-Flop 0xd8 read - 0xda write Master Clear/Reset 0xda read Temporary Register (Intel 82374には存在しない) 0xdc write Clear Mask Register 0xdc read - 0xde write Write All Mask Register Bits 0xdf read Read All Mask Register Bits (Intel 82374にのみ存在する) 0x80 – 0x9f DMA ページレジスタ 0x87 r/w Channel 0 Low byte (23-16) page Register 0x83 r/w Channel 1 Low byte (23-16) page Register 0x81 r/w Channel 2 Low byte (23-16) page Register 0x82 r/w Channel 3 Low byte (23-16) page Register 0x8b r/w Channel 5 Low byte (23-16) page Register 0x89 r/w Channel 6 Low byte (23-16) page Register 0x8a r/w Channel 7 Low byte (23-16) page Register 0x8f r/w Low byte page Refresh 0x400 – 0x4ff 82374 Enhanced DMA Registers Intel 82374 EISA System Component (ESC)は1996年の初めに発表されました. この中 には機能的には8237のスーパーセットであり, 1つのパッケージの中にその他の PC 互換機のコアとなる周辺コンポーネントをも含んだ DMA コントローラも含まれています. このチップはEISAとPCI 両方のプラットホームをターゲットにしたものであり, scatter-gather I/O やリングバッファを始めとして, システムDMAをして32ビットの アドレス空間全体に直接アクセスする能力も提供しています. これらの機能を使用する場合でも, 過去16年間のPC互換機で利用されてきた 同等機能を提供するコードも含めておく必要があります. 互換性の問題から, 82374の レジスタの一部は, 従来の8237のレジスタをプログラムした 後 に, 転送の度にプログラムされる必要があります. 8237のレジスタに書き込みを行うとき, ソフトウェアの下位互換性のために, 82374で追加された一部のレジスタの内容が 強制的に0にクリアされるからです. 0x401 r/w Channel 0 High byte (bits 23-16) word count 0x403 r/w Channel 1 High byte (bits 23-16) word count 0x405 r/w Channel 2 High byte (bits 23-16) word count 0x407 r/w Channel 3 High byte (bits 23-16) word count 0x4c6 r/w Channel 5 High byte (bits 23-16) word count 0x4ca r/w Channel 6 High byte (bits 23-16) word count 0x4ce r/w Channel 7 High byte (bits 23-16) word count 0x487 r/w Channel 0 High byte (bits 31-24) page Register 0x483 r/w Channel 1 High byte (bits 31-24) page Register 0x481 r/w Channel 2 High byte (bits 31-24) page Register 0x482 r/w Channel 3 High byte (bits 31-24) page Register 0x48b r/w Channel 5 High byte (bits 31-24) page Register 0x489 r/w Channel 6 High byte (bits 31-24) page Register 0x48a r/w Channel 6 High byte (bits 31-24) page Register 0x48f r/w High byte page Refresh 0x4e0 r/w Channel 0 Stop Register (bits 7-2) 0x4e1 r/w Channel 0 Stop Register (bits 15-8) 0x4e2 r/w Channel 0 Stop Register (bits 23-16) 0x4e4 r/w Channel 1 Stop Register (bits 7-2) 0x4e5 r/w Channel 1 Stop Register (bits 15-8) 0x4e6 r/w Channel 1 Stop Register (bits 23-16) 0x4e8 r/w Channel 2 Stop Register (bits 7-2) 0x4e9 r/w Channel 2 Stop Register (bits 15-8) 0x4ea r/w Channel 2 Stop Register (bits 23-16) 0x4ec r/w Channel 3 Stop Register (bits 7-2) 0x4ed r/w Channel 3 Stop Register (bits 15-8) 0x4ee r/w Channel 3 Stop Register (bits 23-16) 0x4f4 r/w Channel 5 Stop Register (bits 7-2) 0x4f5 r/w Channel 5 Stop Register (bits 15-8) 0x4f6 r/w Channel 5 Stop Register (bits 23-16) 0x4f8 r/w Channel 6 Stop Register (bits 7-2) 0x4f9 r/w Channel 6 Stop Register (bits 15-8) 0x4fa r/w Channel 6 Stop Register (bits 23-16) 0x4fc r/w Channel 7 Stop Register (bits 7-2) 0x4fd r/w Channel 7 Stop Register (bits 15-8) 0x4fe r/w Channel 7 Stop Register (bits 23-16) 0x40a write Channels 0-3 Chaining Mode Register 0x40a read Channel Interrupt Status Register 0x4d4 write Channels 4-7 Chaining Mode Register 0x4d4 read Chaining Mode Status 0x40c read Chain Buffer Expiration Control Register 0x410 write Channel 0 Scatter-Gather Command Register 0x411 write Channel 1 Scatter-Gather Command Register 0x412 write Channel 2 Scatter-Gather Command Register 0x413 write Channel 3 Scatter-Gather Command Register 0x415 write Channel 5 Scatter-Gather Command Register 0x416 write Channel 6 Scatter-Gather Command Register 0x417 write Channel 7 Scatter-Gather Command Register 0x418 read Channel 0 Scatter-Gather Status Register 0x419 read Channel 1 Scatter-Gather Status Register 0x41a read Channel 2 Scatter-Gather Status Register 0x41b read Channel 3 Scatter-Gather Status Register 0x41d read Channel 5 Scatter-Gather Status Register 0x41e read Channel 5 Scatter-Gather Status Register 0x41f read Channel 7 Scatter-Gather Status Register 0x420-0x423 r/w Channel 0 Scatter-Gather Descriptor Table Pointer Register 0x424-0x427 r/w Channel 1 Scatter-Gather Descriptor Table Pointer Register 0x428-0x42b r/w Channel 2 Scatter-Gather Descriptor Table Pointer Register 0x42c-0x42f r/w Channel 3 Scatter-Gather Descriptor Table Pointer Register 0x434-0x437 r/w Channel 5 Scatter-Gather Descriptor Table Pointer Register 0x438-0x43b r/w Channel 6 Scatter-Gather Descriptor Table Pointer Register 0x43c-0x43f r/w Channel 7 Scatter-Gather Descriptor Table Pointer Register FreeBSD VM システム 原作: &a.dillon;. 6 Feb 1999 物理メモリ管理 — <literal>vm_page_t</literal> 物理メモリはページ単位に, vm_page_t構造体を用いて管理されます. 物理メモリのページは, ページキューの一つに存在する, それぞれの vm_page_t 構造体の配置によって分類されます. ページは, wired(ワイヤード), active(活性状態), inactive(非活性状態), cache(キャッシュ状態), free(使われていない状態)の 各状態をとります. wired 状態を除いて, ページは通常 その状態を示す二重連結リストのキューに置かれます. wired 状態のページがキューに置かれることはありません. FreeBSD は, ページカラーリング(page coloring)を実装するため, cache 状態, free 状態にあるページ用に, さらに複雑なページキューを実装しています. その各々の状態は, プロセッサの L1, L2 キャッシュサイズに応じて最適化された 多重キューを利用します. FreeBSD は, 新たなページを確保(allocate)することが 必要になった場合に確保される VM オブジェクトのために, L1, L2 キャッシュに対して合理的にアライン(align)されたページを 得ようと試みます. 加えて, ページは参照カウントとともに保持され, ビジーカウントとともにロックされます. VM システムは, - ページフラグとして PG_BUSY を使う “完全ロック状態” + ページフラグとして PG_BUSY を使う完全ロック状態 も実装しています. 一般的には, 各々のページキューは最長不使用 (LRU) 方式で動作します. ページは普通, 最初に wired, もしくは active 状態に置かれます. wired 状態の場合, そのページはどこかにあるページテーブルに 関連づけられています. VM システムはアクティブなキュー内のページをスキャンし, wired 状態のページにエイジング (訳注: ページ参照頻度を量る手法の一つ; aging) を施します. そして, そのページはあまりアクティブでないキューへ 移動することになります. cache キューに移動させられたページは, 再利用の候補になっている VM オブジェクトに割り付けられています. free キューにあるページは, 完全に自由の状態にあります. FreeBSD は, free キューにあるページ数を最小限にとどめようと 試みますが, 割り込み発生時のページ確保を融通するため, 完全に自由なページをいくつか持っていなければなりません. プロセスがページテーブルに存在しない, ページキューの一つ(例えば, inactive, cache キュー等)に 存在するページをアクセスしようとしたとき, 比較的負荷の小さなページ再活性化フォールトが起こります. システムメモリに全く存在していないページの場合は, ディスクからページを読み出す間, そのプロセスはブロック(block)されます. FreeBSD は, ページキューを動的に調節し, 同期済(clean)のページ, 同期していない(dirty)ページの分類を 合理的に保つのと同様に, それぞれのキューにあるページが合理的な 比率に保つように試みます. 再バランス化処理が起こる量は, システムのメモリ負荷に依存します. この再バランス化処理は ページアウトデーモンによって実装されていて, (補助記憶とページを同期して)同期していないページの クリーニングすることや, (LRU キュー内でのページ位置を再配置したり, ページをキューの間を移動することで)ページが頻繁に 参照状態にあることに注目すること, キューを均等にするための キュー間ページ移動等を伴います. ページが実際にどれだけ使われているかを決定するために, FreeBSD の VM システムは, ページの再活性化フォールトを 自発的に, 合理的な数だけ発生します. これは, ページをスワップアウトしたり, クリーニングする時期を より良く決めることに繋がります. 統合バッファキャッシュ — <literal>vm_object_t</literal> - FreeBSD は, 一般化した “VM オブジェクト” + FreeBSD は, 一般化した VM オブジェクト という考え方を実装しています. VM オブジェクトは, 様々な種類の補助記憶(backing store) — 補助記憶なし, スワップ, 物理デバイス, ファイル, に割り付けられます. ファイルシステムは ファイルと関連するインコアデータを管理するのに, 同じ VM オブジェクトを利用するため, 統合バッファキャッシュと呼ばれます. VM オブジェクトは, シャドウ化 することができます. シャドウ化とは, オブジェクトがそれぞれ互いの上に スタック(stack)されるということです. 例えば, MAP_PRIVATE mmap() の 動作を実装するために, ファイルに割り付けられた VM オブジェクトの上にスタックされた, スワップに割り付けられた VM オブジェクトが存在しているでしょう. このスタッキングは, fork されたアドレス空間のための 様々な共有属性, コピーオンライト(訳注: ページ共有のための 手法の一つ; cow,copy-on-write) を実装するのにも利用されています. vm_page_t は, 同時に一つの VM オブジェクトしか割り付けられることが できないことに注意しなければなりません. VM オブジェクトのシャドウ化は, 複数のインスタンスが同じページに 共有できるように実装されています. ファイルシステム I/O — <literal>struct buf</literal> 補助記憶にファイルを使う VM オブジェクトのように, v ノードを使う VM オブジェクトは通常, 処理されているかどうかという情報を, VMシステムが管理する処理情報から独立して 管理される必要があります. 例えば, VM システムが物理ページと補助記憶を同期させようとしたとき, VM システムは, 実際に書き戻す前に, ページがクリーニング済であるという マークを付ける必要があるわけです. さらに, ファイルシステムは, KVM 内で操作できるように, ファイルや, ファイルメタデータの一部分を KVM にマッピングすることが できなくてはなりません. これを管理するために使われる実体は, ファイルシステムバッファ, struct buf, bp として知られています. ファイルシステムに VM オブジェクトの一部を操作することが 必要となるときは通常, オブジェクトの部分が struct buf に マッピングされ, KVM に struct buf 内のページがマッピングされます. 同じ方法で, ディスク I/O はオブジェクトの部分を バッファ構造体内にマッピングし, その時バッファ構造体上の I/O を 発行することで発行されます. 基礎となっている vm_page_t は, I/O 処理の間 ビジー(busy)状態になります. ファイルシステムにも 独立したビジー状態があり, それはハードウェア上の VM ページの代わりに ファイルシステムバッファで動作する ファイルシステムドライバのコードに とって有用です. FreeBSD は, マッピングを保持するためにある量に制限された KVM を 予約していますが, KVM がマッピングを保持するためだけに使われ, キャッシュデータの能力を制限しないということは 明確にされるべきでしょう. 物理データキャッシュを行うことは厳密に vm_page_t の機能になっており, ファイルシステムバッファの機能ではありません. しかし, ファイルシステムバッファは placehold I/O に使われるため, それは実質的に同時処理可能な I/O 処理量を制限します. 通常は二, 三千のファイルバッファが利用可能ですから, このことは問題にならないでしょう. マッピングページテーブル — <literal>vm_map_t</literal>, <literal>vm_entry_t</literal> FreeBSD は, 物理ページテーブルの形態を VM システムと分離しています. ハードウェア上にある全てのプロセス毎のページテーブルは, その場その場で再構成され, 通常, 使い捨てだとみなされています. KVM を管理するような特殊なページテーブルは, 最初に永続的な確保が 行われ, これらのページテーブルが破棄されることはありません. FreeBSD は, vm_objects の部分を, 仮想メモリのアドレス範囲に vm_map_t と vm_entry_t 構造体を通して割り付けます. ページテーブルは, vm_map_t /vm_entry_t/vm_object_t という階層から 直接つくられます. “物理ページは, 直接一つの vm_object に 割り付けられる” と私が述べたことを思い出して下さい. ええと, そうですね, しかしそれはいつでも完全に当てはまる, というわけでもないのです. vm_page_t のは, 実際に割り付けられた ページテーブルにもリンクされています. 一つの vm_page_t は ページテーブルが呼ばれた時, いくつかの pmaps と リンクされることがあります. しかし, そのような階層的な割り付けは, 同じ vm_page_t を参照するオブジェクト内の, 同じページへの参照全てを保持しているため, その結果, 常にバッファキャッシュの統合を得ることができるわけです. KVM メモリマッピング FreeBSD は, 様々なカーネル構造体を保持するため, KVM を利用します. ファイルシステムバッファキャッシュは, KVM 内で最も大きなものです. それはつまり, struct buf の実体に対するマッピングに他なりません. Linux と異なり, FreeBSD は全ての物理メモリを KVM にマッピングしません. これは, FreeBSD が 32 ビットプラットフォームで 4G バイトまでの メモリを扱える, ということを意味します. 実際, MMU がそれを可能にしているならば, 理論上, FreeBSD は 32 ビットプラットフォームで 8TB までのメモリを扱うことができることになります. しかし, 大部分の 32 ビットプラットフォームは 4G バイトの RAM しか マッピングできないようになっている, ということには議論の余地があるでしょう. KVM は, いくつかのメカニズムによって管理されています. 中心となっているのは, ゾーンアロケータ(zone allocator)です. ゾーンアロケータは, 特定の構造体型を確保するために KVM の部分(chunk)を得て, 一定の大きさのメモリブロックに分割します. vmstat -m コマンドで, ゾーンによって 分割された, 現在の KVM 利用状況一覧を得ることができます. FreeBSD VM システムのチューニング FreeBSD カーネルでは, 動的に自分自身をチューニングするために, 協調的な努力が行なわれています. 普通は, maxusers と NMBCLUSTERS という カーネルオプション, つまり, /usr/src/sys/i386/conf/CONFIG_FILE で 指定されるもの以外, 変更する必要はありません. 可能なカーネルオプションの一覧は, /usr/src/sys/i386/conf/LINT に 記載されています. 大きなシステムに対しては, maxusers を増やしたいと思うかも知れませんね. この値は普通, 10 から 128 の間の値にします. maxusers を増やしすぎるとシステムの利用可能な KVM がオーバフローしてしまい, 予測できない動作に陥ってしまうことに注意して下さい. maxusers はある適度な値にとどめておいて, 特定のリソースを制御する NMBCLUSTERS のような, 他のオプションを増加させる方が良いでしょう. もし, システムが負荷の高いネットワーク用途に使われるなら, NMBCLUSTERS を増やしたいと望むことでしょう. この値は普通, 1024 から 4096 の間です. NBUF パラメータも, 伝統的にシステムの規模を決めるのに使われます. これは, システムがファイルシステムバッファを I/O のために マッピングするのに使われる, KVA の大きさを決めるのに使われます. このパラメータは, 統合バッファキャッシュには何の影響も与えません. これは 3.0-RELEASE 以降のカーネルでは動的にチューニングされるため, 普通は手作業で調整されるべきものではありません. NBUF パラメータは, 指定しようとしないことを推奨します. システムに選択させれば良いのです. 小さすぎる値は極端に非効率的なファイルシステム動作を招き, 一方で, 大きすぎる値は wired 状態のページを数多くつくりだし, ページキューを枯渇させてしまうでしょう. デフォルトでは, FreeBSD カーネルは最適化されていません. カーネルコンフィグにある makeoption ディレクティブを使って 最適化とデバッグフラグをセットすることができます. ただし, それによって得られる大きな (7MB 超の)カーネルを相手にするのが嫌なら, オプションは使ってはいけません. - makeoptions DEBUG="-g" -makeoptions COPTFLAGS="-O2 -pipe" + +makeoptions DEBUG="-g" +makeoptions COPTFLAGS="-O -pipe" sysctl は, 実行時にカーネルパラメータをチューニングする 手段を提供しています. しかし, 普通は sysctl 変数, 特に VM に関連したものを変更する必要が 生じるようなことはありません. 実行時の VM とシステムのチューニングは, 比較的単純です. まず, 可能ならば UFS/FFS ファイルシステムで softupdates を使いましょう. /usr/src/contrib/sys/softupdates/README のファイルに, 設定方法に関する手順(と制限)について書かれています. - 次に, 十分なスワップを設定します. “作業” + 次に, 十分なスワップを設定します. 作業 ディスクを含む 各物理ディスク装置毎に一つずつ (最大四つまで)のスワップパーティションを 設定すべきです. 少なくとも, メインメモリの 2 倍の スワップ空間が望ましく, メモリがあまりない場合には, おそらくそれより多く必要になります. また, スワップパーティションのサイズは, 後でパーティションをつくり直しする必要がないように マシンに設定したいメモリ設定の最大値を基準に 決めるべきでしょう. もし, クラッシュダンプをとりたい場合, スワップパーティションは最低限メインメモリと同じの大きさで, /var/crash にはダンプを保持するのに十分な 空きがなければなければなりません. NFS 経由のスワップは, -4.x 以降のシステムで完全に動作しますが, NFS サーバ側では, ページングがその負荷の主な原因になることに 注意しなければなりません. + + + IPv6/IPsec の実装 + + 原作: &a.shin;, 2000 年 3 月 5 日. + + 訳: &a.jp.hino;, 2001 年 3 月 19 日. + + + 訳注 + + 訳語については IPv6 次世代インターネット・プロトコル, + クリスチャン・ウイテマ著, 村井純監修, WIDE プロジェクト + IPv6 分科会監訳, 松島栄樹訳, 1997, ISBN4-88735-010-4 + を参考にさせていただきました. + + + 本章では, IPv6 と IPsec に関連する実装の詳細について説明します. + これらの機能は + KAME + プロジェクトの成果を取り込んだものです. + + + IPv6 + + + 規格適合性 + + わたしたちの IPv6 関連の機能は, 最新の IPv6 仕様に準処してい + るか, または準処しようと努力しています. 今後の参考のために以下 + に参考文献を挙げておきます (注: これ + は完全なリストではありません - それを維持するのは大変ですか + ら...). + + 詳しくは, 本文書の各章や, RFC, マニュアル + ページ, そしてソースコード中のコメントを参照してください. + + 規格適合テストは, TAHI プロジェクトにより KAME STABLE + kit に対して行われました. その結果は, + http://www.tahi.org/report/KAME/ + で見ることができます. わたしたちはまた, + ニューハンプシャー大学で行われた IOL テスト + (http://www.iol.unh.edu/) + に以前のバージョンで参加したこともあります. + + + + RFC1639: FTP Operation Over Big Address Records + (FOOBAR) (大きなアドレスレコードを用いる FTP 操作) + + + + RFC2428 は RFC1639 よりも推奨されます. FTP クラ + イアントは, まず RFC2428 を試し, もしそれが失敗したな + ら RFC1639 を試します. + + + + + + RFC1886: DNS Extensions to support IPv6 (IPv6 をサポー + トするための DNS 拡張) + + + + RFC1933: Transition Mechanisms for IPv6 Hosts and + Routers (IPv6 ホストおよびルータのための移行機構) + + + + IPv4 互換アドレスはサポートされません. + + + + 自動トンネリング (RFC の 4.3 で述べられています) + はサポートされません. + + + + &man.gif.4; インタフェースは IPv[46]-over-IPv[46] + トンネルを包括的な方法で実装しており, それは仕様で述べ + られている "configured tunnel (構成されたトンネル)" を + カバーしています. 詳細は本文書の + 23.5.1.5をご覧ください. + + + + + + RFC1981: Path MTU Discovery for IPv6 (IPv6 における + 経路 MTU 探索) + + + + RFC2080: RIPng for IPv6 (IPv6 のための RIPng) + + + + usr.sbin/route6d がこれをサポートしています. + + + + + + RFC2292: Advanced Sockets API for IPv6 (IPv6 のため + の拡張ソケット API) + + + + サポートされているライブラリ関数やカーネルの API + については, sys/netinet6/ADVAPI + をご覧ください. + + + + + + RFC2362: Protocol Independent Multicast-Sparse + Mode (PIM-SM) (プロトコル独立マルチキャスト - 疎モード + (sparse mode)) + + + + RFC2362 は PIM-SM のパケットフォーマットを定義し + ています. + draft-ietf-pim-ipv6-01.txt はこれ + に準じて書かれています. + + + + + + RFC2373: IPv6 Addressing Architecture (IPv6 アドレス + 体系) + + + + ノードに必須のアドレス群をサポートし, スコープ要 + 求に準処しています. + + + + + + RFC2374: An IPv6 Aggregatable Global Unicast Address + Format (IPv6 集約可能グローバルユニキャストアドレス形式) + + + + 64 ビット長のインタフェース ID をサポートしていま + す. + + + + + + RFC2375: IPv6 Multicast Address Assignments (IPv6 に + おけるマルチキャストアドレス割り当て) + + + + ユーザランドのアプリケーション群は本 RFC で割り + 当てられている well-known なアドレスを使用しています. + + + + + + + RFC2428: FTP Extensions for IPv6 and NATs (IPv6 と + NAT のための FTP 拡張) + + + + RFC2428 は RFC1639 よりも推奨されます. FTP クラ + イアントは, まず RFC2428 を試し, もしそれが失敗したな + ら RFC1639 を試します. + + + + + + RFC2460: IPv6 specification (IPv6 仕様) + + + + RFC2461: Neighbor discovery for IPv6 (IPv6 における + 近隣探索) + + + + 詳しくは本文書の + 23.5.1.2 をご覧く + ださい. + + + + + + RFC2462: IPv6 Stateless Address Autoconfiguration + (IPv6 におけるステートレスアドレス自動設定) + + + + 詳しくは本文書の + 23.5.1.4 をご覧ください. + + + + + + RFC2463: ICMPv6 for IPv6 specification (IPv6 のため + の ICMPv6 仕様) + + + + 詳しくは本文書の + 23.5.1.9 をご覧ください. + + + + + + RFC2464: Transmission of IPv6 Packets over Ethernet + Networks (イーサネット上での IPv6 パケットの転送方式) + + + + RFC2465: MIB for IPv6: Textual Conventions and General + Group (IPv6 用 MIB: 文字列的変換法と一般グループ) + + + + 必要な統計情報はカーネルにより集計されています. + 実際の IPv6 MIB サポートは ucd-snmp に対するパッチキッ + トとして提供されています. + + + + + + RFC2466: MIB for IPv6: ICMPv6 group (IPv6 用 MIB: + ICMPv6 グループ) + + + + 必要な統計情報はカーネルにより集計されています. + 実際の IPv6 MIB サポートは ucd-snmp に対するパッチキッ + トとして提供されています. + + + + + + RFC2467: Transmission of IPv6 Packets over FDDI + Networks (FDDI ネットワーク上での IPv6 パケットの転送方式) + + + + RFC2497: Transmission of IPv6 packet over ARCnet + Networks (ARCnet ネットワーク上での IPv6 パケットの転送方 + 式) + + + + RFC2553: Basic Socket Interface Extensions for IPv6 + (IPv6 のための 基本的ソケットインタフェースの拡張) + + + + IPv4 射影アドレス (3.7) と IPv6 ワイルドカードバ + インドソケットの特別な動作 (3.8) をサポートしています. + 詳しくは本文書の + 23.5.1.12 + をご覧ください. + + + + + + RFC2675: IPv6 Jumbograms (IPv6 巨大パケット) + + + + 詳しくは本文書の + 23.5.1.7 をご覧ください. + + + + + + RFC2710: Multicast Listener Discovery for IPv6 (IPv6 + のためのマルチキャスト受信者探索) + + + + RFC2711: IPv6 router alert option (IPv6 ルータ警報オ + プション) + + + + draft-ietf-ipngwg-router-renum-08: + IPv6 におけるルータの再番号付け + + + + draft-ietf-ipngwg-icmp-namelookups-02: + ICMP による IPv6 名前検索 + + + + draft-ietf-ipngwg-icmp-name-lookups-03: + ICMP による IPv6 名前検索 + + + + draft-ietf-pim-ipv6-01.txt: + IPv6 用 PIM + + + + &man.pim6dd.8; は密モード (dense mode) を実装しています. + &man.pim6sd.8; は疎モード (sparse mode) を実装しています. + + + + + + draft-itojun-ipv6-tcp-to-anycast-00: + IPv6 エニーキャストアドレス向けに TCP 接続を切断 + + + + draft-yamamoto-wideipv6-comm-model-00 + + + + 詳細は本文書の + 23.5.1.6 を参照してください. + + + + + + draft-ietf-ipngwg-scopedaddr-format-00.txt + : IPv6 のスコープ化アドレス形式の拡張 + + + + + + 近隣探索 + + 近隣探索はきわめて安定しています. 現在, アドレス検索 + (Address Resolution), 重複アドレス検出 (Duplicated Address + Detection), 近隣到達不能性検出 (Neighbor Unreachability + Detection) がサポートされています. もうすぐ, カーネルに代理近 + 隣通知 (Proxy Neighbor Advertisement) サポートを加え, 管理者ツー + ルとして近隣探索取消要請 (Unsolicited Neighbor Advertisement) + を送出するコマンドを加える予定です. + + DAD (重複アドレス検出) が重複を検出した場合, そのアドレ + スは "重複している" という印が付けられ, syslog にメッセージが + 記録されます (そして通常はコンソールに表示されます). "重複して + いる" 印は &man.ifconfig.8; で調べることができます. 重複検出の + チェックおよび重複状態を解消することは管理者の責任となります. + この動作は近いうちに改良するべきです. + + いくつかのネットワークドライバは, そうしないようにと指示 + された場合でもマルチキャストパケットを自分自身に送り返してしま + います (特に無差別 (promiscuous) モードでは). このような状況で + は DAD は重複を検出するでしょう. なぜなら DAD を実行するプログ + ラムは NS パケットの到着を検出し (それが自ノードが出力したもの + であるにもかかわらず) それが重複を表しているとみなすからです. + この問題に対処する方法は, + sys/netinet6/nd6_nbr.c:nd6_dad_timer() 中の "heuristics" とマー + クされた #if 条件のあたりを見てください ("heuristics" 部分のプ + ログラムコードは仕様に反していることに注意してください). + + 近隣探索の仕様 (RFC2461) では, 以下に述べる状況での近隣 + 情報キャッシュの取り扱いについて記述されていません: + + + + 近隣情報キャッシュが空の時に, 下位層 (リンク層) アド + レスを持たない RS/NS/NA/redirect 削除要請パケットを受信 + + + + + 下位層アドレスを持たない通信メディアにおける近隣情報 + キャッシュの取り扱い (IsRouter ビットのために一つの近隣情 + 報キャッシュエントリが必要です) + + + + 一つめの場合については, IETF ipngwg メーリングリストで行 + われた議論に基づく対応策を実装しています. より詳しくは, ソース + コード中のコメントと, 1999 年 2 月 6 日の (IPng 7155) というメー + ルから始まったスレッドを参照してください. + + IPv6 における同一リンク上かどうかの判断ルール (RFC2461) + は, BSD のネットワークコードが想定している条件と全く異なります. + とりあえず, デフォルトルータのリストが空の時には同一リンク上か + どうかの判断ルールはサポートしていません (RFC2461 の 5.2 章, + 第二文節の最後の文 - この仕様のこの章では何カ所かで "host" と + "node" という単語の間違った使い方をしていることに注意). + + サービス妨害攻撃と無限ループをさけるために, ND パケット + 中のオプションは 10 個だけが受け付けられます. そのため, もし + RA に 20 個のプレフィックスを載せたとしても先頭の 10 個のプレ + フィックスしか理解されません. もしこのことが問題となるのなら, + FREEBSD-CURRENT メーリングリストに質問するか, または + sys/netinet6/nd6.c 中の nd6_maxndopt を変 + 更してください. もし多くの要求があるようなら, この変数を変更す + る sysctl 変数を用意できるでしょう. + + + + スコープ番号 + + IPv6 はスコープ化されたアドレスを使います. そのため, + IPv6 アドレスにスコープ番号 (リンクローカルアドレスではインタ + フェース番号, サイトローカルアドレスではサイト番号) を指定する + ことは非常に重要です. スコープ番号が無いと, カーネルにとってス + コープ化された IPv6 アドレスは曖昧なものとなり, そしてカーネル + はそのパケットを出力するインタフェースを選ぶことができないでしょ + う. + + ユーザランドのアプリケーションは, スコープ番号またはイン + タフェース番号を指定するために, 通常は拡張 API (RFC2292) を使 + うべきです. 同様の目的のために, RFC2553 において sockaddr_in6 + 構造体にsin6_scope_id メンバが定義されています. しかしながら, + sin6_scope_id の意味づけは少々曖昧です. もし, あなたが自分のア + プリケーションの移植性について気をつけたいのなら, + sin6_scope_id ではなく拡張 API を使うことをお勧めします. + + カーネル中では, リンクローカルスコープのアドレスに対応す + るインタフェース番号は IPv6 アドレスの二番目の 16 ビット語 (三 + 番めと四番めのバイト) に埋め込まれます. たとえばルーティングテー + ブルとインタフェースアドレス構造体 (struct in6_ifaddr) の中で, + 以下のような例を見ることができるでしょう: + + fe80:1::200:f8ff:fe01:6317 + + 上で述べたアドレスはリンクローカルなユニキャストアドレス + で, それはインタフェース番号が 1 であるネットワークインタフェー + スに属するものです. 埋め込まれた番号によって, 複数のインタフェー + スに対する IPv6 リンクローカルアドレス群を, 効率的に, かつ少々 + のプログラムの対応だけで, 識別することができます. + + &man.route6d.8; や &man.ifconfig.8; のような, ルーティン + グデーモンと設定プログラムは "埋め込まれた" スコープ番号を取り + 扱う必要があります. これらのプログラムはルーティング用のソケッ + トと (SIOCGIFADDR_IN6 のような) ioctl 群を使います. そしてカー + ネル API は二番目の 16 ビット語を書き込んでから IPv6 アドレス + を返します. これらの API はカーネル内部構造体を操作するための + ものです. これらの API を利用するプログラムは, どちらにしろカー + ネル間の違いについて意識する必要があります. + + コマンドラインでスコープ化されたアドレスを指定するときに + は, (ff02:1::1 や fe80:2::fedc のような) 埋め込まれた形式を ＊ + 絶対に＊ 使わないでください. たぶんこれでは動きません. インタ + フェースを指定するコマンドラインオプション (たとえば + ping6 -I ne0 ff02::1) を使うときには, 必ず + ff02::1 や fe80::fedc のような標準形式を使ってください. 一般的 + にいって, コマンドが出力インタフェースを指定するコマンドライン + オプションを持っていないのならば, そのコマンドはスコープ化され + たアドレスを受け付けることはできないでしょう. このことは IPv6 + の, "歯医者のオフィス" をサポートするという前提に反するように + 思えるでしょう. この問題に関して, わたしたちは仕様に何らかの改良を + 加える必要があると信じています. + + いくつかのユーザランドのツールは, + draft-ietf-ipngwg-scopedaddr-format-00.txt + で文書化されている, IPv6 拡張数値記法をサポートしています. + "fe80::1%ne0" というように, 出力インタフェースの名前を使って, + パケットを出力するリンクを指定することができます. この方法によっ + て, 特に問題なくリンクローカルなスコープ化されたアドレスを指定 + することができるでしょう. + + あなたのプログラムでこの拡張数値記法を使うためには, + &man.getaddrinfo.3;, と &man.getnameinfo.3; を NI_WITHSCOPEID + をつけて使用する必要があります. 現在の実装では, リンクとインタ + フェースとが一対一に対応していることを想定しています. これは仕 + 様で述べられているよりも強い想定です. + + + + プラグ & プレイ + + ほとんどの IPv6 ステートレスアドレス自動設定はカーネル中 + に実装されています. 近隣探索機能は全てカーネル内に実装されてい + ます. ルータ通知 (RA: Router Advertisement) のホストへの入力は + カーネル内で実装されています. ルータ要請 (RS: Router + Solicitation) の終端ホストからの出力, RS のルータへの入力, そ + してルータでの RA の出力はユーザランドで実装されています. + + + リンクローカルアドレスと特別アドレスの割り当て + + IPv6 リンクローカルアドレスは IEEE802 アドレス (イーサ + ネットの MAC アドレス) から生成されます. 各インタフェースに + は, そのインタフェースが利用可能になったとき (IFF_UP) に自動 + 的にリンクローカルアドレスが一つ割り当てられます. 同時に, そ + のリンクローカルアドレスに対する直接のルートがルーティングテー + ブルに加えられます. + + 以下に netstat コマンドの出力を示します: + + Internet6: +Destination Gateway Flags Netif Expire +fe80:1::%ed0/64 link#1 UC ed0 +fe80:2::%ep0/64 link#2 UC ep0 + + IEEE802 アドレスを持っていないインタフェース (トンネル + インタフェースのような疑似インタフェースや, ppp インタフェー + ス) は, できる限り, イーサネットインタフェースなどの他のイン + タフェースから IEEE802 アドレスを借用します. もし IEEE802 ア + ドレスを持ったハードウェアが一つもなければ, 最後の手段として + (MD5(ホスト名)で計算される) 疑似乱数値がリンクローカルアドレ + スの元として使われます. もしこれがあなたの用途に合わないなら, + リンクローカルアドレスを手動で設定する必要があるでしょう. + + もしあるインタフェースで IPv6 を使えない (たとえばマルチ + キャストをサポートしない, 等の理由で) ならば, そのインタフェー + スにはリンクローカルアドレスは割り当てられません. 詳細は 2 + 章をご覧ください. + + 各インタフェースは要請されたマルチキャストアドレスとリ + ンクローカルな「全ノード」マルチキャストアドレスに加わります + (すなわち, そのインタフェースがつながれたリンク上で, それぞ + れ fe80::1:ff01:6317 と ff02::1 です). リンクローカルアドレ + スに加え, ループバックアドレス (::1) がループバックインタフェー + スに割り当てられます. また, ::1/128 と ff01::/32 が自動的に + ルーティングテーブルに追加され, そしてループバックインタフェー + スはノードローカルマルチキャストグループである ff01::1 に加 + わります. + + + + ホスト上でのステートレスアドレス自動設定 + + IPv6 仕様では, ノードは二種類に分類されます: + ルータとホストです. + ルータは他宛のアドレスがついたパケットを転送します. ホストは + パケットの転送を行いません. net.inet6.ip6.forwarding によっ + て, このノードがルータであるかホストであるかが決定されます + (1 ならルータで, 0 ならホストです). + + ホストがルータ通知 (Router Advertisement) をルータから + 受信すると, ホストはステートレスアドレス自動設定によって自ら + を自動設定することができます. この動作は + net.inet6.ip6.accept_rtadv によって制御できます (1 にセット + されているとホストは自らを自動設定します). 自動設定によって, + この受信したインタフェースにネットワークアドレスプリフィック + ス (通常はグローバルアドレスプリフィックス) が追加されます. + デフォルトルートも同時に設定されます. ルータは定期的にルータ + 通知パケットを送出します. 隣接するルータに RA パケットを送出 + するよう要求するために, ホストはルータ要請 (Router + Solicitation) を送信することができます. 好きなときに RS パケッ + トを送出するためには, rtsol コマンドを + 使います. また, &man.rtsold.8; デーモンもあります. + &man.rtsold.8; は必要なときにはいつでもルータ要請を送出しま + す. これは移動体のような使い方 (ノート型やラップトップ型コン + ピュータ) をするときにとても調子良く働きます. もしルータ通知 + を無視したいのなら, sysctl で net.inet6.ip6.accept_rtadv を + 0 にしてください. + + ルータでルータ通知を送出するには &man.rtadvd.8 デーモ + ンを使います. + + IPv6 仕様では, 以下の事柄を想定しており, それらに合致 + しないケースに関しては仕様化されていないことに注意してくださ + い: + + + + ホストだけがルータ通知を待ち受けている + + + + ホストは (ループバック以外には) ネットワークインタ + フェースを一つだけ持つ + + + + 以上のことより, ルータや複数のインタフェースを持つホス + トで net.inet6.ip6.accept_rtadv を有効にすることは賢いことで + はないことが分かります. 設定を失敗したノードは変な動作をする + 可能性があります (経験をしてみたい人のために仕様にあわない設 + 定も許されています). + + sysctl 変数を整理すると: + + accept_rtadv forwarding ノードの役割 + --- --- --- + 0 0 ホスト (手動で設定された) + 0 1 ルータ + 1 0 自動設定されたホスト + (仕様ではホストはインタフェー + スを一つのみ持つことを想定して + いるので, 複数のインタフェース + を持つホストの自動設定は想定外) + 1 1 不正, または実験的 + (仕様の想定外) + + RFC2462 の 5.5.3 (e) には到着した RA プリフィックス情 + 報オプションの検証ルールが書いてあります. これは悪意のある + (または設定を失敗した) ルータが非常に短いプリフィックス生存 + 期間を通知してくることに対してホストを防御するためのものです. + ipngwg メーリングリストで Jim Bound による更新があり (メーリ + ングリストアーカイブの "(ipng 6712)" をご覧ください), ここで + の実装はこの Jim の更新を取り入れたものです. + + DAD と自動設定との関係については, 本文書の + 23.5.1.2 をご覧ください. + + + + + + 包括的トンネルインタフェース (Generic tunnel interface) + + GIF (包括的インタフェース: Generic Interface) は構成された + トンネルのための疑似インタフェースです. 詳細は &man.gif.4; に + 述べられています. 現在, + + + + v6 in v6 + + + + v6 in v4 + + + + v4 in v6 + + + + v4 in v4 + + + + が利用できます. gif インタフェースに物理的な (外側の) 始 + 点と終点アドレスを割り当てるためには &man.gifconfig.8; を使い + ます. 内側と外側の IP ヘッダで同じアドレスファミリを使う (v4 + in v4, または v6 in v6) 設定は危険です. 無限段数のトンネルを作っ + てしまうようにインタフェースとルーティングテーブルを設定するの + はとても簡単だからです.注意してください! + + + gif は ECN (Explicit Congestion Notification: 明示的輻輳 + 通知) とともに使えるように設定することができます. ECN との親和 + 性については 23.5.4.5 + をご覧ください. + また, 設定方法に関しては &man.gif.4; をご覧ください. + + もし IPv4-in-IPv6 トンネルを gif インタフェースを使って + 設定しようと思っているなら, &man.gif.4; を注意深く読んでくださ + い. gif インタフェースに自動的に割り当てられる IPv6 リンクロー + カルアドレスを削除する必要があるでしょう. + + + + 始点アドレスの選択 + + 現在の始点選択ルールはスコープ指向です (いくつかの例外も + あります - 以下を参照してください). ある終点アドレスに対する始 + 点 IPv6 アドレスは以下の規則に従って選択されます: + + + + もし始点アドレスがユーザにより明示的に指定 (たとえば拡 + 張 API を通じて) されていたならば, その指定されたアドレス + が使われる. + + + + 出力インタフェース (通常はルーティングテーブルを検索 + することにより決定される) にアドレスが割り当てられており, + そのアドレスが終点アドレスと同一のスコープを持っているなら + ば, そのアドレスが使われる. + + これがもっとも一般的な場合です. + + + + もし上記の場合を満たすアドレスがなかったときには, 送 + 出するノードが持つインタフェースのうちのどれか一つに割り当 + てられているグローバルアドレスを選択する. + + + + もし上記の場合を満たすアドレスがなかったときで, 終 + 点アドレスがサイトローカルスコープであった場合には, 送出す + るノードが持つインタフェースのうちのどれか一つに割り当てら + れているサイトローカルアドレスを選択する. + + + + もし上記の場合を満たすアドレスがなかったときは, 終 + 点に向かっているルーティングテーブルエントリに関連づけられ + たアドレスを選択する. これは最後の手段であり, スコープ違反 + を引き起こす可能性がある. + + + + たとえば, ff01::1 に対しては ::1 が選択され, + fe80:1::2a0:24ff:feab:839b に対しては + fe80:1::200:f8ff:fe01:6317 が選択されます (埋め込まれたインタ + フェース番号に注意 - + 23.5.1.3 で述べられている - + この番号により正しい始点アドレスが選択できます. これらの埋め込 + まれた番号は通信路 (wire) 上では存在しません). もし出力インタ + フェースが該当するスコープに対して複数のアドレスを持っていた場 + 合は, 始点は最長一致法 (規則 3) で選択されます. たとえば, 出力イ + ンタフェースに, 3ffe:501:808:1:200:f8ff:fe01:6317 と + 3ffe:2001:9:124:200:f8ff:fe01:6317 が付けられていたとします. + 終点アドレスが 3ffe:501:800::1 であるとすると, 始点アドレスと + しては 3ffe:501:808:1:200:f8ff:fe01:6317 が選択されます. + + 上記の規則は IPv6 仕様では文書化されていないことに注意し + てください. これは「実装に任された」項目と考えられているのです. + 上記の規則に則らないケースがいくつかあります. 一つの例は, 接続 + 済みの TCP セッションで, この場合は tcb に保存されているアドレ + スを始点とします. 他の例としては, 近隣通知 (Neighbor + Advertisement: NA) の際の始点アドレスです. 仕様 (RFC2461 + 7.2.2) によれば, NA の始点アドレスは対応する NS (近隣要請) の + ターゲットアドレスであるべきとされています. この場合は, 上記の + 最長一致規則ではなく仕様に従います. + + 新規に接続を行うとき (規則 1 に当てはまらないとき) に, + 他に選択肢がある限り, 推奨有効期間切れアドレス (preferred + lifetime が 0 であるアドレス）を始点アドレスとして選択すること + はありません. もし他の選択肢がなければ, 最後の手段として推奨有 + 効期限切れアドレスが使われます. もし複数の推奨有効期間切れアド + レスがあるときには, 上記のスコープ規則に従ってそれらのアドレス + からの選択が行われます. もし何らかの理由により推奨有効期間切れ + アドレスの使用を禁止したいのならば, + net.inet6.ip6.use_deprecated を 0 に設定してください. 推奨有効 + 期間切れアドレスに関連する問題は, RFC2462 5.5.4 に記述されてい + ます (注意: IETF の ipngwg では推奨有効期間切れアドレスをどの + ように使うべきかの議論がいくつか進行中です). + + + + 巨大ペイロード + + 巨大ペイロード中継点毎オプションは実装されており, 65,535 + バイトよりも長いペイロードを持つ IPv6 パケットを送信するときに + 利用できます. しかし, MTU が 65,535 よりも大きな物理インタフェー + スは現在サポートされていませんから, そのようなペイロードはルー + プバックインタフェース (たとえば lo0) 上でのみ利用できます. + + もし巨大ペイロードを試してみたいのならば, まず始めに, ルー + プバックインタフェースの MTU が 65,535 バイトよりも大きくなる + ようにカーネルの再構成を行わなければなりません; 以下の行をカー + ネル構成ファイルに追加してください: + + + options "LARGE_LOMTU" #To test jumbo payload + + + そして新しいカーネルをコンパイルしてください. + + 次に, &man.ping6.8; コマンドを -b と -s オプション付きで + 使うことで巨大ペイロードを試してみることができます. -b オプショ + ンはソケットバッファの大きさを拡大するために指定しなければなリ + ません. -s オプションによりパケット長を指定します. その値は + 65,535 よりも大きくなるでしょう. たとえば以下のように入力してく + ださい: + + + &prompt.user; ping6 -b 70000 -s 68000 ::1 + + + IPv6 仕様では, 巨大ペイロードオプションは分割された + (fragtment) ヘッダを持つパケットでは使えないことになっています. + この条件が破られると ICMPv6 Parameter Problem メッセージが送信 + 元に送られるはずです. この仕様には従っているのですが, 通常はこ + の ICMPv6 エラーを見ることはできないでしょう. + + IPv6 パケットが受信されると, そのフレーム長が調べられ, + そして IPv6 ヘッダ中のペイロード長フィールド, またはもしあれば + 巨大ペイロードオプションの値, で指定された長さと比較されます. + もし前者の方が後者よりも短ければ, パケットは廃棄され統計情報が + 更新されます. この統計情報は, &man.netstat.8; コマンドを `-s + -p ip6' オプション付きで実行すると見ることができます: + + + &prompt.user; netstat -s -p ip6 + ip6: + (snip) + 1 with data size < data length + + + それ故, カーネルはエラーを起こしたパケットが本当に巨大ペ + イロードである, すなわち, そのパケット長が 65,535 バイトよりも + 長い場合にしか ICMPv6 エラーを送りません. 上で述べたように, 現 + 在そのような巨大な MTU をもつ物理インタフェースはサポートされ + ていませんので, IPMPv6 エラーが返ることは滅多にないでしょう. + + + 現状では, 巨大パケット上の TCP/UDP はサポートされていま + せん. これはテストできる通信メディアが (ループバック以外) 存在 + しないためです. もしこれを必要としているなら, わたしたちに連絡して + ください. + + IPsec は巨大パケットの上では動作しません. これは, 巨大パ + ケットと AH を同時にサポートする場合の仕様の「ねじれ」のせいで + す (AH ヘッダサイズはペイロード長に影響を及ぼし, そしてこのこ + とが, 巨大ペイロードオプションと AH が両方付いた到着パケッ + トを認証することを本当に困難にしてしまうのです). + + *BSD において巨大パケットをサポートするには基本的な問題 + がいくつかあります. それらをここで指摘したいのですが, このリス + トを完成させるためにはもっと時間が必要です. その中のいくつかを + 以下に挙げます: + + + + 4.4BSD では mbuf の pkthdr.len フィールドは "int" 型 + ですから, 32 ビットアーキテクチャの CPU 上では 2 ギガバイ + ト以上の巨大パケットを保持できません. 巨大パケットを正しく + サポートするには, このフィールドは, 4 ギガバイト + IPv6 ヘッ + ダ + 下位層ヘッダを保持できるように拡張されなければなりま + せん. そのため, 少なくとも int64_t に拡張する必要がありま + す (u_int32_t では十分では＊ありません＊). + + + + 多くの場所で, パケット長を格納するための場所を誤って + "int" としてしまっています. それらをもっと大きな整数型に変 + 換する必要があります. この作業には細心の注意が必要です. な + ぜならパケット長の計算をするときにオーバフローを起こしてし + まうかもしれないからです. + + + + たくさんの場所で, パケットのペイロード長を調べるのに, + 間違って IPv6 ヘッダの ip6_plen フィールドをチェックしてい + ます. そうではなくて, mbuf の pkthdr.len を調べなければな + りません. ip6_input() が入力時に巨大ペイロードオプションの + 健全性をチェックするようにすれば, その後は mbuf の + pkthdr.len を安全に使うことができるでしょう. + + + + TCP のコードには, もちろん, たくさんの場所の注意深い更 + 新が必要でしょう. + + + + + + ヘッダ処理中のループ防止 + + IPv6 仕様はパケットに任意の数の拡張ヘッダがつくことを許 + しています. もし IPv6 パケット処理コードを BSD の IPv4 コード + が実装されているのと同様の方法で実装すると, 何重もの関数呼び出 + しのせいでカーネルスタックがオーバーフローしてしまうでしょう. + sys/netinet6 のコードは, カーネルスタックオーバフローを回避す + るように注意深く設計されています. そのために, sys/netinet6 の + コードでは独自のプロトコルスイッチ構造体を "struct ip6protosw" + (netinet6/ip6protosw.h を参照してください) + として定義しています. 互換性のために, IPv4 の部分 + (sys/netinet) にはこの変更を行っていませんが, しかし, 小さな変 + 更が pr_input() のプロトタイプについて行われています. そのため + "struct ipprotosw" も定義されています. 以上の理由により, 非常 + に多くの IPsec ヘッダを持つ IPsec-over-IPv4 パケットを受け取っ + たときにカーネルスタックがオーバーフローする可能性があります. + IPsec-over-IPv6 は大丈夫です. (もちろん, それら全ての IPsec ヘッ + ダが全て処理されるには, 一つ一つの IPsec ヘッダがそれぞれ + IPsec の試験をパスする必要があります. そのため, 外部の攻撃者が + そのような攻撃をすることは不可能です.) + + + + ICMPv6 + + RFC2463 が公開された後, IETF の ipngwg は, ネットワーク + メディア上の ICMPv6 ストームを引き起こさないように, ICMPv6 向 + け直し (redirect) に対して ICMPv6 エラーパケットを出さないよう + に決定しました. これはすでにカーネル内で実装されています. + + + + アプリケーション + + ユーザランドのプログラミングのために, RFC2553, RFC2292, + そして発行準備中の internet draft で定義されている, IPv6 ソケッ + ト API をサポートしています. + + IPv6 上の TCP/UDP は利用可能であり, きわめて安定していま + す. &man.telnet.1;, &man.ftp.1;, &man.rlogin.1;, &man.rsh.1;, + &man.ssh.1, 等を試してみてください. これらのアプリケーションは + プロトコル非依存となっています. つまり, DNS に従って自動的に + IPv4 と IPv6 を選択します. + + + + カーネルの内部 + + ip_forward() は ip_output() を呼びだしていますが, + ip6_forward() は ip_output() を直接呼びだします. これは, ルー + タは IPv6 のパケットを断片に分割してはいけないからです. + + ICMPv6 は最大 1280 まで, できる限り元のパケットをコピー + して含んでおく必要があります. たとえば, UDP6/IP6 ポート不到達 + ICMPv6 パケットは, 全ての拡張ヘッダと, ＊未変更の＊ UDP6 と + IP6 ヘッダを含まなければなりません. そのため, TCP を除く全ての + IP6 関数はオリジナルのパケットを保存しておくために, ネットワー + クバイト順をホストバイト順に変換しません. + + tcp_input() と udp6_input(), icmp6_input() は, 拡張ヘッ + ダがあるために, IP6 ヘッダのすぐ後ろにトランスポートヘッダがあ + ることを仮定できません. そのため, in6_cksum() は IP6 ヘッダと + トランスポートヘッダが連続しないようなパケットを処理できるよう + に実装されています. チェックサム計算のための TCP/IP6 ヘッダ構 + 造体も, UDP6/IP6 ヘッダ構造体も存在しません. + + IP6 ヘッダと, 拡張ヘッダ, トランスポートヘッダを容易に処 + 理できるように, ネットワークドライバに対する新たな要求事項とし + て, パケットを一つの内部 mbuf に納めるか, または, 一つ以上の外 + 部 mbuf に納める必要性を追加しました. 典型的な古いドライバは, + 96 から 204 バイトのデータ用の二つの内部 mbuf を用意しますが, + 今後はそのようなパケットデータは一つの外部 mbuf に記録されるこ + とになります. + + netstat -s -p ip6 を実行すると, ドラ + イバが上記の要求を満たしているかどうかが分かります. 以下の例で + は "cce0" は要求を満たしていません (詳細は 2 章をご覧ください.) + + + Mbuf statistics: + 317 one mbuf + two or more mbuf:: + lo0 = 8 + cce0 = 10 + 3282 one ext mbuf + 0 two or more ext mbuf + + + 各入力関数は始めの段階で, IP6 とそのヘッダが連続した領域 + にあるかどうかを調べるために IP6_EXTHDR_CHECK を呼び出します. + IP6_EXTHDR_CHECK は mbuf が M_LOOP フラグを持っているときのみ + m_pullup() を呼び出します. M_LOOP フラグは, パケットがループバッ + クインタフェースからきたことを示します. 物理的なネットワークイ + ンタフェースからきたパケットに対しては m_pullup() が呼ばれるこ + とはありません. + + IP と IP6 両方の再構成 (reassemble) 機能は m_pullup() を + 呼び出すことはありません. + + + + IPv4 射影アドレスと IPv6 ワイルドカードソケット + + RFC2553 では, IPv4 射影 (mapped) アドレス (3.7) と IPv6 + ワイルドカードバインドソケットの特別な振る舞い (3.8) が記述さ + れています. 仕様では以下の動作が許されています: + + + + AF_INET6 ワイルドカードバインドソケットで IPv4 接続 + を受け付ける. + + + + 特別な形式のアドレス, たとえば ::ffff:10.1.1.1 を使うこ + とで AF_INET6 ソケットから IPv4 のパケットを送出する. + + + + + しかし, 仕様自体が非常に込み入っており, またこの仕様では + ソケット層がどう動作すべきかということについて何も規定していま + せん. ここでは前者を "待ち受け側" と呼び, 後者を "開始側" と呼 + ぶことにします. + + 同一のポート上で, 両アドレスファミリのワイルドカードバイ + ンドを実行することができます. + + 以下の表に FreeBSD 4.x の動作を示します. + + + 待ち受け側 開始側 + (AF_INET6 ワイルド (::ffff:10.1.1.1 への接続) + カードソケットが + IPv4 接続を受ける.) + --- --- +FreeBSD 4.x 設定可能 サポートされている + デフォルト: 有効 + + + 以下の章で, より詳細を述べると共に, どうやってこの動作を + 設定するかを示します. + + 待ち受け側に対するコメント: + + RFC2553 は, ワイルドカードバインドの問題についてあまりに + も少ししか議論していません. 特に, ポート空間の問題, 失敗モード, + そして AF_INET/INET6 ワイルドカードバインド間の関連について. + この RFC に関しては, これに準処しているにもかかわらず異なった + 動作をするいくつかの別々の解釈が成り立ちます. そのため, 移植可 + 能なアプリケーションを実装する際には, カーネルの動作について一 + 切の仮定をおくべきではありません. &man.getaddrinfo.3; を使う + のがもっとも安全な方法です. ポート番号空間とワイルドカードバイ + ンドの問題は, 1999 年 3 月半ばに ipv6imp メーリングリストにお + いてつっこんだ議論がなされましたが, 最終的な合意は得られなかっ + たようです (つまり, 実装次第ということです). メーリングリスト + のアーカイブを調べてみてはいかがでしょうか. + + サーバアプリケーションで, IPv4 と IPv6 の両方の接続を受 + けたいのなら, 別の方法が二つあります. + + 一つは, AF_INET ソケットと AF_INET6 ソケットを使う方法で + す (二つのソケットが必要です). &man.getaddrinfo.3; を + ai_flags に AI_PASSIVE を設定して使い, そして, 返ってきた全て + のアドレスに対して &man.socket.2; と&man.bind.2; を使います. + 複数のソケットを開くことで, 適切なアドレスファミリを持つソケッ + ト上で接続を受けることができます. IPv4 接続は AF_INET ソケット + で受けられ, そして IPv6 接続は AF_INET6 ソケットで受けられるで + しょう. + + もう一つの方法は, AF_INET6 のワイルドカードバインドソケッ + トを使う方法です. ai_flags にAI_PASSIVE を, ai_family に + AF_INET6 を設定し, そして一つ目の引数であるホスト名を NULL に + して &man.getaddrinfo.3; を使ってください. そして返ってきたア + ドレス (IPv6 の未指定アドレスであるはずです) に対して + &man.socket.2; と &man.bind.2; を行います. この一つのソケット + で, IPv4 と IPv6 のパケットを受けることができます. + + 移植可能な方法で, AF_INET6 ワイルドカードバインドソケッ + トで IPv6 のみをサポートするには, 待ち受けしている AF_INET6 ソ + ケットに対して接続要求をしてきた相手アドレスを毎回チェックする + ようにしてください. もしそのアドレスが IPv4 射影アドレスであっ + たなら, その接続を遮断する必要があるかもしれません. この条件を + 判定するのに, IN6_IS_ADDR_V4MAPPED() マクロを使うことができま + す. + + この問題をもっと簡単に解決するために, システム依存の + &man.setsockopt.2; オプション, IPV6_BINDV6ONLY があります. そ + の使い方を以下に示します. + + + int on; + + setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, + (char *)&on, sizeof (on)) < 0)); + + + この呼び出しが成功すれば, このソケットは IPv6 パケットの + みを受信します. + + 開始側についてのコメント: + + アプリケーション実装者へのアドバイス: 移植可能な (複数種 + の IPv6 カーネル上で動作する) IPv6 アプリケーションを実装する + には, 以下に述べる点が成功への鍵となると信じます: + + + + ＊絶対に＊ AF_INET も AF_INET6 もハードコードしない. + + + + + システムを通じて &man.getaddrinfo.3; と + &man.getnameinfo.3; を使う. gethostby*() や, getaddrby*(), + inet_*(), getipnodeby*() を絶対に使わない (既存アプリケー + ションを簡単に IPv6 対応とするために, getipnodeby*() が便 + 利なこともあるでしょう. しかし, 可能であれば, コードを書き + 直して &man.getaddrinfo.3; と &man.getnameinfo.3; を使うよ + うに努力してみてください.) + + + + ある終点 (destination) に対して接続したいときは, + &man.telnet.1; のように, &man.getaddrinfo.3; を使って, 返っ + てきた全ての終点について試すようにしてください. + + + + いくつかの IPv6 プロトコルスタックは, バグありの + &man.getaddrinfo.3; 付きで出荷されています. 最低限きちんと + 動作するバージョンをあなたのアプリケーションと一緒に出荷し, + それを最後の手段として使いましょう. + + + + もし AF_INET6 ソケットから IPv4 と IPv6 の両方の接続を行 + いたいのなら, &man.getipnodebyname.3; を使う必要があるでしょう. + 既存のアプリケーションを工数最小で IPv6 対応に更新したいのなら + ば, この方法がよいでしょう. しかし, これは一時的な解であること + に注意してください. なぜなら, スコープ化された IPv6 アドレスを + 全く扱うことができないという欠点があるので + &man.getipnodebyname.3; 自身を推薦できないからです. IPv6 の名 + 前検索には, &man.getaddrinfo.3; が推奨される API です. ですか + ら, 時間があるときには, アプリケーションを &man.getaddrinfo.3; + を使うように書き換えるべきです. + + 外部に出ていく接続を行うアプリケーションを書くときに, も + し AF_INET と AF_INET6 とを完全に別々のアドレスファミリとして + 取り扱うのならば, 話は非常に単純になります. {set,get}sockopt + の問題は単純になり, DNS の問題も単純になるでしょう. IPv4 射影 + アドレスに依存する手法は推薦できません. + + + tcp と inpcb の統合コード + + FreeBSD 4.x では, tcp に関しては IPv4 と IPv6 でコード + を共有しています (sys/netinet/tcp* で). そして udp4/6 では別々 + のコードです. 統合した inpcb 構造体を使っています. + + このプラットフォームは IPv4 射影アドレスをサポートする + ように設定できます. カーネルの設定は以下のようにまとめられま + す: + + + + デフォルトでは, AF_INET6 ソケットはある条件下では + IPv4 接続をハンドリングできます. そして IPv4 射影の IPv6 + アドレス中に入っている IPv4 の終点へ向けて接続を開始する + ことができます. + + + + 以下のように sysctl を使ってシステム全体でそれを無 + 効にできます. + + + sysctl -w net.inet6.ip6.mapped_addr=0 + + + + + + + 待ち受け側 + + 各ソケットは特別な AF_INET6 ワイルドカードバインドを + サポートするように設定できます (デフォルトで有効です). 以 + 下のように, ソケット毎に &man.setsockopt.2; を使ってこれを + 無効にできます. + + + int on; + + setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, + (char *)&on, sizeof (on)) < 0)); + + + ワイルドカード AF_INET6 ソケットは, 以下の条件が成り + 立つときのみ, IPv4 接続をハンドリングできます: + + + + その IPv4 接続にマッチする AF_INET ソケットが存 + 在しない + + + + その AF_INET6 ソケットは IPv4 通信を受け付けるよ + うに設定されている, すなわち + getsockopt(IPV6_BINDV6ONLY) が 0 を返す. + + + + open/close の順番は問題となりません. + + + + 開始側 + + FreeBSD 4.x では, ノードが IPv4 射影アドレスをサポー + トするように設定されているときには, IPv4 射影アドレス + (::ffff:10.1.1.1) へ向けての接続がサポートされています. + + + + + + + sockaddr_storage + + RFC2553 が最後の仕上げにかかっている頃, sockaddr_storage + 構造体のメンバにどのように名前を付けるかという議論がありました. + 一つの提案は, それがいじってはいけないものであるのだから, メン + バ名の前に "__" を付ける ("__ss_len" のように), というものでし + た. 他の提案は, それらのメンバを直接操作する必要があるのだから, + なにも付けない ("ss_len" のように), というものでした. この件に + 関する明確な合意は得られませんでした. + + その結果として, RFC2553 では sockaddr_storage 構造体は以 + 下のように定義されました: + + + struct sockaddr_storage { + u_char __ss_len; /* address length */ + u_char __ss_family; /* address family */ + /* and bunch of padding */ + }; + + + これに反して, XNET ドラフトでは以下のように定義されまし + た: + + + struct sockaddr_storage { + u_char ss_len; /* address length */ + u_char ss_family; /* address family */ + /* and bunch of padding */ + }; + + + 1999 年 12 月に, RFC2553bis では後者 (XNET) の定義を採用 + することで合意がなされました. + + 現在の実装は, RFC2553bis の議論の結果, XNET の定義に適合 + するようになっています. + + 複数の IPv6 実装を調べたならば, 両方の定義を見ることにな + るでしょう. ユーザランドのプログラマとして, この件に対応するもっ + とも移植性が高い方法は: + + + + GNU autoconf を使って, ss_family と/または ss_len + がこのプラットフォームで利用可能であることを確かめる, + + + + + -Dss_family=__ss_family として (ヘッダファイルも含め + て) 全てを __ss_family に統合してしまう, または + + + + __ss_family には絶対に手を出さない. sockaddr * へキャ + ストして, 以下の例のように sa_family を使う: + + + struct sockaddr_storage ss; + family = ((struct sockaddr *)&ss)->sa_family + + + + + + + + + ネットワークドライバ + + ここで, 以下の二項目を標準的なドライバでサポートすることが必須 + となります: + + + + mbuf クラスタリングが要求されます. この安定版リリース + においては, 全てのドライバが期待通りに動くように, 全てのオペ + レーティングシステムにおいて MINCLSIZE を MHLEN+1 に変更しま + した. + + + + マルチキャスト. もしあるインタフェースについて + &man.ifmcstat.8; が一つもマルチキャストグループを示さないな + ら, そのインタフェースは修正が必要です. + + + + もしあるドライバが上記要求をサポートしないなら, そのドラ + イバでは IPv6 と/または IPsec 通信には使えません. もしあなた + のカードで IPv6/IPsec の使用に関して何か問題を見つけたなら, 是 + 非それを freebsd-bugs@FreeBSD.org に報告してくだ + さい. + + (注: かつて, 全ての PCMCIA ドライバに in6_ifattach() を呼 + ぶことを要求したことがありました. 現在では, もはやこの要求は + 取り下げています) + + + + トランスレータ + + ここでは IPv4/IPv6 トランスレータを四つに分類します: + + + + トランスレータ A --- 移行の初期 + の段階で使われるもので, IPv6 島上の IPv6 ホストから IPv4 + 海上の IPv4 ホストへの接続を確立できるようにするものです. + + + + + トランスレータ B --- 移行の初期 + の段階で使われるもので, IPv4 海上の IPv4 ホストから IPv6 + 島上の IPv6 ホストへの接続を確立できるようにするものです. + + + + + トランスレータ C --- 移行の後期 + の段階で使われるもので, IPv4 島上の IPv4 ホストから IPv6 + 海上の IPv6 ホストへの接続を確立できるようにするものです. + + + + + トランスレータ D --- 移行の後期 + の段階で使われるもので, IPv6 海上の IPv6 ホストから IPv4 + 島上の IPv4 ホストへの接続を確立できるようにするものです. + + + + + 分類 A のための TCP 中継トランスレータはサポートされてい + ます. これは "FAITH" と呼ばれます. 分類 A のための IP ヘッダト + ランスレータも提供しています. (後者は FreeBSD 4.x ではまだ取り + 込まれていません.) + + + FAITH TCP 中継トランスレータ + + FAITH システムはカーネルの助けを借りた &man.faithd.8; と + 呼ばれる TCP 中継デーモンを利用します. FAITH は IPv6 アドレス + プリフィックスを一つ予約し, そのプリフィックスに向かう TCP 接 + 続を IPv4 終点に向けて中継します. + + たとえば, 予約された IPv6 プリフィックスが + 3ffe:0501:0200:ffff:: で, TCP 接続の IPv6 終点が + 3ffe:0501:0200:ffff::163.221.202.12 であるならば, その接続は + 163.221.202.12 という IPv4 終点に向けて中継されます. + + + 終点 IPv4 ノード (163.221.202.12) + ^ + | 163.221.202.12 へ向けた IPv4 tcp + FAITH-中継 二重スタックノード + ^ + | 3ffe:0501:0200:ffff::163.221.202.12 へ向けた IPv6 TCP + 始点 IPv6 ノード + + + FAITH-中継 二重スタックノードでは &man.faithd.8; を起動 + しておく必要があります. + + より詳細な情報は, + src/usr.sbin/faithd/README をご覧ください. + + + + + IPsec + + IPsec は主に三つの構成要素からなります. + + + + ポリシ管理 + + + + 鍵管理 + + + + AH と ESP のハンドリング + + + + + ポリシ管理 + + 現在のカーネルには実験的なポリシ管理コードが実装されてい + ます. セキュリティポリシを管理するには二つの方法があります. 一 + つは, &man.setsockopt.2; を使ってソケット一つずつにポリシを設 + 定する方法です. この場合のポリシ設定は + &man.ipsec.set.policy.3; で説明されています. もう一つの方法は, + &man.setkey.8; によって PF_KEY インタフェース経由でカーネル内 + のパケットフィルタをもとにしたポリシを設定する方法です. + + ポリシエントリはその番号によって並び替えられることはない + ので, エントリを追加するときの順番がとても重要になります. + + + + 鍵管理 + + このキットで実装されている鍵管理コード (sys/netkey) は, + 自家製の PFKEY v2 実装です. これは RFC2367 に準処しています. + + + 自家製の IKE デーモンである "racoon" がこのキットに含ま + れています (kame/kame/racoon). 基本的に, racoon はデーモンとし + て走らせる必要があり, それから鍵を要求するポリシをセットアップ + します (たとえば, ping -P 'out ipsec + esp/transport//use' というように). カーネルは鍵を交 + 換するために, 必要に応じて racoon デーモンにアクセスします. + + + + AH と ESP のハンドリング + + IPsec のモジュールは, 標準の IPv4/IPv6 処理中の "フック" + として実装されています. パケットを送信するときに, + ip{,6}_output() は 一致する SPD (Security Policy Database: セ + キュリティポリシデータベース) があるかどうかをチェックして + ESP/AH 処理が必要かどうかを判断します. もし ESP/AH が必要なら, + {esp,ah}{4,6}_output() が呼ばれ, mbuf が適切に更新されます. パ + ケットを受信したときは, プロトコル番号に従って, すなわち + (*inetsw[proto])() という形で {esp,ah}4_input() が呼ばれます. + {esp,ah}4_input() はそのパケットの認証情報を解読 / 試験し, そ + して数珠繋ぎのヘッダと ESP/AH のためのパディングを取り除きます. + パケット受信時に ESP/AH ヘッダを取り除いてしまっても安全です. + なぜなら受信したパケットを "あるがまま" の形で使うことは絶対に + ないからです. + + ESP/AH を使うことによって, TCP4/6 における実効データセグ + メント長は ESP/AH によって挿入される数珠繋ぎのヘッダの増加分だ + け影響を受けます. わたしたちのコードはこの場合を考慮に入れています. + + + 基本的な暗号機能は "sys/crypto" ディレクトリの中にありま + す. ESP/AH 変換は wrapper 関数と一緒に {esp,ah}_core.c に記述され + ています. もしアルゴリズムを追加したかったら, wrapper 関数を + {esp,ah}_core.c に追加し, そして追加する暗号アルゴリズムを実装 + したコードを src/crypto に追加してください. + + このリリースでは, トンネルモードは以下の制限と共に部分的 + にサポートされています: + + + + IPsec トンネルは GIF による包括的トンネリングインタ + フェースと結合されていません. ip_output() と + tunnelifp->if_output() の間で無限ループを構成してしまうか + もしれないので, 非常に注意深く作業する必要があります. 統合 + した方がよいか, よくないか, 意見はいろいろ出ています. + + + + MTU と 分割禁止ビット (IPv4) についての考慮はさらな + るチェックを必要としています, が, 基本的にはうまく動いてい + ます. + + + + AH トンネルのための認証モデルは再考する必要があるで + しょう. 今後, ポリシ管理エンジンを改良する必要が出てくると + 思われます. + + + + + + RFC と ID への準処 + + カーネル内の IPsec コードは以下の標準に準処しています + (もしくは, 準処しようと努力しています): + + rfc182[5-9].txt で文書化されている + "old IPsec" 仕様 + + rfc240[1-6].txt と, + rfc241[01].txt, + rfc2451.txt, + draft-mcdonald-simple-ipsec-api-01.txt + (このドラフトは期限切れですが, + + ftp://ftp.kame.net/pub/internet-drafts/ から入手できま + す) で文書化されている "new IPsec" 仕様. + (注: IKE 仕様, rfc241[7-9].txt はユーザラ + ンドの "racoon" IKE デーモンとして実装されています) + + 現在サポートしているアルゴリズムは: + + + + old IPsec AH + + + + 空の暗号チェックサム (文書化されていません. デ + バッグのためだけのものです) + + + + 128 ビットの暗号チェックサムと鍵付き MD5 + (rfc1828.txt) + + + + 128 ビットの暗号チェックサムと鍵付き SHA1 + (文書化されていません) + + + + 128 ビットの暗号チェックサムと HMAC MD5 + (rfc2085.txt) + + + + 128 ビットの暗号チェックサムと HMAC SHA1 + (文書化されていません) + + + + + + old IPsec ESP + + + + 空の暗号化 (文書化されていません, + rfc2410.txt と似たものです) + + + + DES-CBC モード (rfc1829.txt) + + + + + + new IPsec AH + + + + 空の暗号チェックサム (文書化されていません. デ + バッグのためだけのものです) + + + + 96 ビットの暗号チェックサムと鍵付き MD5 + (文書化されていません) + + + + 96 ビットの暗号チェックサムと鍵付き SHA1 + (文書化されていません) + + + + 96 ビットの暗号チェックサムと HMAC MD5 + (rfc2403.txt) + + + + 96 ビットの暗号チェックサムと HMAC SHA1 + (rfc2404.txt) + + + + + + new IPsec ESP + + + + 空の暗号化 + (rfc2410.txt) + + + + DES-CBC with derived IV + (draft-ietf-ipsec-ciph-des-derived-01.txt, + draft expired) + + + + DES-CBC with explicit IV + (rfc2405.txt) + + + + 3DES-CBC with explicit IV + (rfc2451.txt) + + + + BLOWFISH CBC + (rfc2451.txt) + + + + CAST128 CBC + (rfc2451.txt) + + + + RC5 CBC + (rfc2451.txt) + + + + 上記のそれぞれは, 以下と結合可能: + + + + HMAC-MD5(96 ビット) による ESP 認証 + + + + HMAC-SHA1(96 ビット) による ESP 認証 + + + + + + + + 以下のアルゴリズムはサポートされて ＊いません＊: + + + + old IPsec AH + + + + 128 ビットの暗号チェックサムと HMAC MD5 + 64 ビット + の再送攻撃防止 (rfc2085.txt) + + + + 160 ビット暗号チェックサムと鍵付き SHA1 + 32 ビッ + トのパディング + (rfc1852.txt) + + + + + + IPsec (カーネル内) と IKE (ユーザランドの "racoon") は, + 何回もの相互接続性試験イベントで試験されていて, そこでの結果とし + て, 多くの他の実装とうまく相互接続可能であることがわかっていま + す. また, 現在の IPsec 実装は, RFC に記述された IPsec 暗号ア + ルゴリズムを非常に広くカバーしています (知的所有権の問題がない + アルゴリズムに限ってカバーしています). + + + + IPsec トンネルにおける ECN の考察 + + ECN と親和性のある IPsec トンネルは, + draft-ipsec-ecn-00.txt で述べられている方 + 法を用いてサポートされています. + + 通常の IPsec トンネルは RFC2401 で記述されています. カプ + セル化されるときに, 内側の IP ヘッダの IPv4 TOS フィールド (ま + たは, IPv6 トラフィッククラスフィールド) が外側の IP ヘッダに + コピーされます. カプセル解放の時には外側の IP ヘッダは単に削ら + れるだけです. 外側の IP ヘッダの TOS / トラフィッククラスフィー + ルド中の ECN ビットが失われてしまうため, このカプセル解放規則 + は ECN と互換性がありません. + + IPsec トンネルを ECN と親和性があるようにするために, カ + プセル化手順とカプセル解放手順を変更する必要がありました. これ + については, + + http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt + の 3 章で記述されています. + + net.inet.ipsec.ecn (または net.inet6.ipsec6.ecn) に設定 + する値によって, IPsec トンネルの実装は三通りの動作を行います: + + + + RFC2401: ECN を考慮しない (sysctl の値が -1 の時) + + + + ECN 禁止 (sysctl の値が 0 の時) + + + + ECN 許可 (sysctl の値が 1 の時) + + + + この振る舞いはノード毎に設定可能であり SA 毎ではないこ + とに注意してください (draft-ipsec-ecn-00 では SA 毎の設定を要 + 求していますが, それは大変すぎます). + + ここで述べた動作をまとめると以下のようになります (より詳 + しくはソースコードをご覧ください): + + + カプセル化 カプセル解放 + --- --- +RFC2401 内側から外側へ 外側の TOS ビットを落とす + 全ての TOS ビットをコピー. (内側の TOS ビットをそのまま使う) + +ECN 禁止 内側から外側へ ECN ビット以外 外側の TOS ビットを落とす + (0xfc でマスク) の TOS ビット (内側の TOS ビットをそのまま使う) + をコピー. ECN ビットを 0 に. + +ECN 許可 内側から外側へ ECN CE 以外 内側の TOS ビットを変更して使う. + (0xfe でマスク) の TOS ビット もし外側の ECN CE ビットが 1 な + をコピー. ECN CE ビットを 0 に. ら, 内側の ECN CE ビットを有効に. + + + 設定方法に関する一般的な戦略は以下のようになります: + + + + もし IPsec トンネルの両端が ECN に親和性がある動作を + するのなら, その両方を "ECN 許可" と設定した方がよいでしょ + う (sysctl の値を 1 に設定). + + + + もし反対側の端が TOS ビットに関して非常に厳密に動作 + するなら, "RFC2401" を使ってください (sysctl の値を -1 に + 設定). + + + + その他の場合, "ECN 禁止" (sysctl の値を 0 に設定). + + + + デフォルトの動作は, "ECN 禁止" (sysctl の値が 0) です. + + より詳しくは, 以下を参照してください: + + + http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, + RFC2481 (Explicit Congestion Notification: 明示的輻輳通知), + src/sys/netinet6/{ah,esp}_input.c + + (詳しい分析をしてくれた, 長 健二朗 氏 + kjc@csl.sony.co.jp に感謝します) + + + + 相互接続性 + + 以下に, これまでに KAME と IPsec/IKE の相互接続性試験を + 行ったプラットフォーム (の一部) を挙げます. これらのプラット + フォームも KAME も, 試験以降に何らかの実装の変更を行っているで + しょうから, 以下のリストは参考にとどめてください. + + Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure), + Ericsson ACC, FreeS/WAN, HITACHI, IBM AIX, IIJ, Intel, + Microsoft WinNT, NIST (linux IPsec + plutoplus), Netscreen, OpenBSD, + RedCreek, Routerware, SSH, Secure Computing, Soliton, Toshiba, + VPNet, Yamaha RT100i + + + diff --git a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml index ced328eff7..d3db4068de 100644 --- a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2890 +1,2857 @@ PPP と SLIP - 改訂: &a.jim;, 2000 年 3 月 1 日 . - + 改訂: &a.jim;, + 2000 年 3 月 1 日. + この章では - もしあなたがモデムを使ってインターネットに接続したり, - 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を - 提供しようとしているのでしたら, PPP または SLIP - 接続を選択することができます. + もしあなたがモデムを使ってインターネットに接続したり, + 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を + 提供しようとしているのでしたら, PPP または SLIP + 接続を選択することができます. - この節では PPP の 3 つの形態について記述しています; - ユーザ, カーネル, そして + この節では 3 種類の PPP について説明しています. + それは ユーザ, カーネル, そして PPPoE (PPP オーバイーサネット) です. また SLIP のクライアントとサーバの設定についても記述しています. - - 最初に記述される形態の PPP はユーザ PPP です. ユーザ PPP は FreeBSD + + 最初に説明するのは, ユーザ PPP です. ユーザ PPP は FreeBSD に 2.0.5-RELEASE の時に, 既に存在していたカーネル実装の PPP に加えて導入されました. ユーザ PPP とカーネル PPP の主な違いは何かと疑問に思われるかも - 知れません. その答えは簡単です. ユーザ PPP はデーモンとしては実行されず + 知れませんが, その答えは簡単です. ユーザ PPP はデーモンとしては実行されず 必要に応じて実行されるのです. PPP インタフェイスを組み込んだカーネルは 必要ではなく, ユーザプロセスとして実行されカーネルとのデータの やり取りにはトンネルデバイスドライバ (tun) を 使用します. この節ではこれ以降ユーザ PPP のことは, pppd のような他の PPP ソフトウエアと特に区別する必要がある場合を除いて, 単に ppp と記述します. またこの節に記述されているコマンドは すべて root で実行されなければなりません. ユーザ ppp の利用 原作: &a.brian;, 協力: - &a.nik;, &a.dirkvangulik;, &a.pjc;. + &a.nik;, &a.dirkvangulik;, &a.pjc;. ユーザ PPP 前提条件 - 以下の情報を手に入れておく必要があるでしょう: - - + 以下の情報を手に入れておく必要があるでしょう: + + - PPP で接続するインターネットサービスプロバイダ (ISP) - のアカウント. さらに, 接続済みのモデム - (またはその他のデバイス) があり, - プロバイダとの接続が可能なように正しく設定されている. + PPP で接続するインターネットサービスプロバイダ (ISP) + のアカウント. さらに, 接続済みのモデム + (またはその他のデバイス) があり, + プロバイダとの接続が可能なように正しく設定されている. - - - プロバイダの電話番号. - - - - ログイン名とパスワード. これは通常の unix - 形式のログイン名と パスワードの組という場合もありますし, - PPP PAP または CHAP の - ログイン名とパスワードの組という場合もあります. - - - - 一つ以上のネームサーバの IP アドレス. 通常, - プロバイダから IP アドレスを二つ指示されている はずです. - 一つすら提供されていないならば, ppp.conf - ファイル中で enable dns コマンドを使って - ppp にネームサーバを設定するよう - 指示できます. - - - - プロバイダからは以下の情報が提供されているはずですが, - どうしても必要というわけではありません: - - - - プロバイダのゲートウェイの IP アドレス. - ゲートウェイとは, あなたがそこに接続をおこなって, - デフォルトルート - として設定することになるマシンです. - プロバイダがこのアドレスを明示していなくても, 最初は - 適当に設定しておいて, 接続時にプロバイダの PPP サーバから - 正しいアドレスを教えてもらうことができます. - - このアドレスは, ppp から - HISADDRとして参照されます. - - - - プロバイダのネットマスク設定. - プロバイダが明示していないとしても, ネットマスクとして - 255.255.255.0 - を使用しておけば問題ありません. - - - - もしプロバイダから固定の IP - アドレスとホスト名の割り当てを 受けていれば, - その情報を指定しておくこともできます. - 割り当てを受けていなければ, 接続先から適切な IP - アドレスを指定してもらいます. - - - - もし, 必要な情報が不足していれば, プロバイダに連絡を取って - 確認しておいてください. + + + プロバイダの電話番号. + + + + ログイン名とパスワード. これは通常の unix + 形式のログイン名と パスワードの組という場合もありますし, + PPP PAP または CHAP の + ログイン名とパスワードの組という場合もあります. + + + + 一つ以上のネームサーバの IP アドレス. 通常, + プロバイダから IP アドレスを二つ指示されている はずです. + 一つすら提供されていないならば, ppp.conf + ファイル中で enable dns コマンドを使って + ppp にネームサーバを設定するよう + 指示できます. + + + + プロバイダからは以下の情報が提供されているはずですが, + どうしても必要というわけではありません: + + + + プロバイダのゲートウェイの IP アドレス. + ゲートウェイとは, あなたがそこに接続をおこなって, + デフォルトルート + として設定することになるマシンです. + プロバイダがこのアドレスを明示していなくても, 最初は + 適当に設定しておいて, 接続時にプロバイダの PPP サーバから + 正しいアドレスを教えてもらうことができます. + + このアドレスは, ppp から + HISADDRとして参照されます. + + + + プロバイダのネットマスク設定. + プロバイダが明示していないとしても, ネットマスクとして + 255.255.255.0 + を使用しておけば問題ありません. + + + + もしプロバイダから固定の IP + アドレスとホスト名の割り当てを 受けていれば, + その情報を指定しておくこともできます. + 割り当てを受けていなければ, 接続先から適切な IP + アドレスを指定してもらいます. + + + + もし, 必要な情報が不足していれば, プロバイダに連絡を取って + 確認しておいてください. - + - ppp 対応カーネルの構築 - - 説明でも述べているように, ppp - はカーネルの tun デバイスを使います. - そのため, このデバイスがカーネルに組み込まれているかどうかを - 確認しておかなくてはいけません. - - これを確認するには, カーネルコンパイルディレクトリ - (/sys/i386/conf または - /sys/pc98/conf) に移動して, - カーネルコンフィグレーションファイルを調べます. - 以下の行がどこかに含まれている必要があります. - + ppp 対応カーネルの構築 + + 説明でも述べているように, ppp + はカーネルの tun デバイスを使います. + 使っているカーネルがどれであっても, + tun デバイスを設定しなければなりません. + FreeBSDに付属しているデフォルトの + GENERIC カーネルに合うように + tun デバイスは前もって設定されています. + しかしながら, 自分で修正したカーネルをインストールするのであれば, + pppが正しく動くよう, カーネルが設定されているか確認しなくてはいけません. + + これを確認するには, カーネルコンパイルディレクトリ + (/sys/i386/conf または + /sys/pc98/conf) に移動して, + カーネルコンフィグレーションファイルを調べます. + 以下の行がどこかに含まれている必要があります. + pseudo-device tun 1 - この行がカーネルコンフィグレーションファイルに - 含まれていない場合, この行を追加して - カーネルの再コンパイルとインストールをおこなう必要があります. - 元々の GENERIC カーネルは - 標準でこれを含んでいますので, - カスタムカーネルをインストールしているのではなかったり, - /sys ディレクトリが存在しないのであれば, - 何も変更する必要はありません. - カーネルコンフィグレーションの詳細については, FreeBSD - カーネルのコンフィグレーション - を参照してください. - - 以下のコマンドを実行することで, - 現在のカーネルにトンネルデバイスが - いくつ組み込まれているかを調べることができます: + この行がカーネルコンフィグレーションファイルに + 含まれていない場合, この行を追加して + カーネルの再コンパイルとインストールをおこなう必要があります. + 元々の GENERIC カーネルは + 標準でこれを含んでいますので, + カスタムカーネルをインストールしているのではなかったり, + /sys ディレクトリが存在しないのであれば, + 何も変更する必要はありません. + カーネルコンフィグレーションの詳細については, + FreeBSD + カーネルのコンフィグレーション + を参照してください. + + 以下のコマンドを実行することで, + 現在のカーネルにトンネルデバイスが + いくつ組み込まれているかを調べることができます: &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - この例ではトンネルデバイスが四つ存在し, そのうち二つに - 設定がおこなわれ, 使用中であることがわかります. 上の例で - RUNNING フラグがオンになっている - ものがありますが, これは - そのインターフェースが何かに使用されていることを示している - だけであるということに注意してください. つまり, - RUNNING になっていない - インターフェースがあったとしても, それはエラーではありません. - - - トンネルデバイスがカーネルに組み込まれておらず, - 何らかの理由で - カーネルの再構築ができない場合でも, - 方法がないわけではありません. - 動的にデバイスをロードすることができるはずです. - 詳細については - &man.modload.8; や &man.lkm.4; など, - 適切なマニュアルを参照してください. + + FreeBSD 4.0やより最近のリリースでは, すでに使われている + tun デバイスしか見つけることが + できないでしょう. これは, 全く + tun デバイスを見つけることが + できないかもしれないということです. しかし, もしこうなって + しまっても, 心配することはありません. そのデバイスは + ppp が使おうとする時に動的に作られるはず + だからです. + + + この例ではトンネルデバイスが四つ存在し, そのうち二つに + 設定がおこなわれ, 使用中であることがわかります. 上の例で + RUNNING フラグがオンになっている + ものがありますが, これは + そのインターフェースが何かに使用されていることを示している + だけであるということに注意してください. つまり, + RUNNING になっていない + インターフェースがあったとしても, それはエラーではありません. + + + トンネルデバイスがカーネルに組み込まれておらず, + 何らかの理由で + カーネルの再構築ができない場合でも, + 方法がないわけではありません. + 動的にデバイスをロードすることができるはずです. + 詳細については + &man.modload.8; や &man.lkm.4; など, + 適切なマニュアルを参照してください. - + - tun デバイスの確認 - - ほとんどのユーザは tun デバイス - (/dev/tun0) が一つあれば充分でしょう. - より多くのデバイスを使う場合 (すなわち, - カーネルコンフィグレーション ファイルで pseudo-device - tun の行に 1 - 以外の数値を指定している場合), 以下で - tun0 と書かれている部分をすべて, - あなたが使うデバイスの番号に - あわせて読みかえてください. - - tun0 - デバイスが正しく作成されていることを確認する最も簡単な方法は, - それを作り直すことです. そのためには, - 以下のコマンドを実行します: - - &prompt.root; cd /dev + tun デバイスの確認 + + ほとんどのユーザは tun デバイス + (/dev/tun0) が一つあれば充分でしょう. + より多くのデバイスを使う場合 (すなわち, + カーネルコンフィグレーション ファイルで pseudo-device + tun の行に 1 + 以外の数値を指定している場合), 以下で + tun0 と書かれている部分をすべて, + あなたが使うデバイスの番号に + あわせて読みかえてください. + + tun0 + デバイスが正しく作成されていることを確認する最も簡単な方法は, + それを作り直すことです. そのためには, + 以下のコマンドを実行します: + + &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 - カーネルに 16 個のトンネルデバイスを組み込んだのであれば, - tun0 だけでなく他の tun - デバイスも作成しておく必要があるでしょう: + カーネルに 16 個のトンネルデバイスを組み込んだのであれば, + tun0 だけでなく他の tun + デバイスも作成しておく必要があるでしょう: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 - また, カーネルが正しく設定されているかどうかを調べるために - 以下のコマンドを実行して, - このような出力が得られることを確認します: + また, カーネルが正しく設定されているかどうかを調べるために + 以下のコマンドを実行して, + このような出力が得られることを確認します: - &prompt.root; ifconfig tun0 + &prompt.root; ifconfig tun0 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 - まだ RUNNING - フラグがセットされていない場合もあります. - その時は以下のような出力が得られるでしょう: - - &prompt.root; ifconfig tun0 + まだ RUNNING + フラグがセットされていない場合もあります. + その時は以下のような出力が得られるでしょう: + + &prompt.root; ifconfig tun0 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - + 前述したように, FreeBSD 4.0 以降のリリースでは + tun デバイスは要求に応じて + 作られるので, もしそのデバイスがまだ使われていなければ, + 見つけられないかもしれないということを思い出してください. + + - 名前の解決に関する設定 - - リゾルバ (resolver) はシステムの一部分で, IP - アドレスとホスト名との 変換をおこないます. IP - アドレスとホスト名を対応させるためのマップを, - 二つの場所のうちの一つから探すように設定できます. 一つめは - /etc/hosts (man 5 - hosts) と呼ばれるファイルです. 二つめはインターネット - ドメインネームサービス (DNS) と呼ばれる - 分散データベースですが, これに関する議論は - このドキュメントで扱う範囲を 越えていますので, - これについての説明はおこないません. - - リゾルバは名前のマッピングを - おこなうシステムコールの集合体です. ただし - どこからマッピング情報を見つけるのかは, - 最初に指示しておく必要があります. これは まず - /etc/host.conf - ファイルを編集することでおこないます. 混乱の元になりますので, - このファイルを /etc/hosts.conf と - 呼んだりしてはいけません (余分な - s がついていますね). - + 名前の解決に関する設定 + + リゾルバ (resolver) はシステムの一部分で, IP + アドレスとホスト名との 変換をおこないます. IP + アドレスとホスト名を対応させるためのマップを, + 二つの場所のうちの一つから探すように設定できます. 一つめは + /etc/hosts (man 5 + hosts) と呼ばれるファイルです. 二つめはインターネット + ドメインネームサービス (DNS) と呼ばれる + 分散データベースですが, これに関する議論は + このドキュメントで扱う範囲を 越えていますので, + これについての説明はおこないません. + + リゾルバは名前のマッピングを + おこなうシステムコールの集合体です. ただし + どこからマッピング情報を見つけるのかは, + 最初に指示しておく必要があります. これは まず + /etc/host.conf + ファイルを編集することでおこないます. 混乱の元になりますので, + このファイルを /etc/hosts.conf と + 呼んだりしてはいけません (余分な + s がついていますね). + - <filename>/etc/host.conf</filename> ファイルの編集 + <filename>/etc/host.conf</filename> ファイルの編集 - このファイルには 以下の 2 行が (この順番で) - 書かれているはずです: + このファイルには 以下の 2 行が (この順番で) + 書かれているはずです: - + hosts bind - これは, 最初に /etc/hosts - ファイルを調べ, そこで目的の名前が 見つけられなかった場合に - DNS を引きにいくようリゾルバに指示します. + これは, 最初に /etc/hosts + ファイルを調べ, そこで目的の名前が 見つけられなかった場合に + DNS を引きにいくようリゾルバに指示します. - + - /etc/hosts(5) ファイルの編集 - - - このファイルはローカルネットワーク上に存在するマシンの - IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp - を動作させるマシンのエントリが 含まれている必要があります. - そのマシンのホスト名が foo.bar.com で, IP アドレスが - 10.0.0.1 であると仮定すると, - /etc/hosts は - 以下の行を含んでいなければいけません: - - + /etc/hosts(5) ファイルの編集 + + + このファイルはローカルネットワーク上に存在するマシンの + IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp + を動作させるマシンのエントリが 含まれている必要があります. + そのマシンのホスト名が foo.bar.com + で, IP アドレスが + 10.0.0.1 であると仮定すると, + /etc/hosts は + 以下の行を含んでいなければいけません: + + 127.0.0.1 localhost.bar.com localhost 127.0.0.1 localhost.bar.com. 10.0.0.1 foo.bar.com foo 10.0.0.1 foo.bar.com. - 一つめの行は localhost - を現在のマシンの別名として定義しています. マシン固有の IP - アドレスが何であっても, この行の IP アドレスは 常に 127.0.0.1 でなければいけません. - 二つめの行はホスト名 foo.bar.com (と, その省略形 - foo) を IP アドレス 10.0.0.1 にマップします. - - もしプロバイダから固定の IP - アドレスとホスト名を割り当てられて いるのであれば, それを - 10.0.0.1 - エントリのかわりに使ってください. + 一つめの行は localhost + を現在のマシンの別名として定義しています. マシン固有の IP + アドレスが何であっても, この行の IP アドレスは 常に + 127.0.0.1 でなければいけません. + 二つめの行はホスト名 foo.bar.com + (と, その省略形 + foo) を IP アドレス + 10.0.0.1 にマップします. + + もしプロバイダから固定の IP + アドレスとホスト名を割り当てられて いるのであれば, それを + 10.0.0.1 + エントリのかわりに使ってください. - + - <filename>/etc/resolv.conf</filename> ファイルの編集 - - /etc/resolv.conf - はリゾルバの振舞いを指定します. もし自前の DNS - サーバを走らせているのなら, このファイルは空のままに - しておくこともできます. 通常は, - 以下のように書いておく必要があるでしょう: - - + <filename>/etc/resolv.conf</filename> ファイルの編集 + + /etc/resolv.conf + はリゾルバの振舞いを指定します. もし自前の DNS + サーバを走らせているのなら, このファイルは空のままに + しておくこともできます. 通常は, + 以下のように書いておく必要があるでしょう: + + domain bar.com nameserver x.x.x.x nameserver y.y.y.y - x.x.x.x - と y.y.y.y - はプロバイダから指示されたアドレスで, - 接続するプロバイダが提供しているネームサーバを - すべて書いてください. domain - に指定するのは このマシンのデフォルトのドメイン名で, - おそらく 書かなくても問題は無いでしょう. - このファイルの各エントリの詳細については, - resolv.conf - のマニュアルページを参照してください. - - バージョン 2 以降の ppp を使用している場合には, - enable dns - コマンドを使用してネームサーバのアドレスを - プロバイダに問い合わせるように指示することができます. - 上の指定とは異なるアドレスをプロバイダが指定してきた場合 - (または /etc/resolv.conf - でネームサーバが指定されていない場合), ppp - はプロバイダが指定したアドレスで - resolv.conf を書きかえます. + x.x.x.x + と y.y.y.y + はプロバイダから指示されたアドレスで, + 接続するプロバイダが提供しているネームサーバを + すべて書いてください. domain + に指定するのは このマシンのデフォルトのドメイン名で, + おそらく 書かなくても問題は無いでしょう. + このファイルの各エントリの詳細については, + resolv.conf + のマニュアルページを参照してください. + + バージョン 2 以降の ppp を使用している場合には, + enable dns + コマンドを使用してネームサーバのアドレスを + プロバイダに問い合わせるように指示することができます. + 上の指定とは異なるアドレスをプロバイダが指定してきた場合 + (または /etc/resolv.conf + でネームサーバが指定されていない場合), ppp + はプロバイダが指定したアドレスで + resolv.conf を書きかえます. - + - <command>ppp</command> の設定 - - ユーザ ppp と pppd (カーネルレベルの - PPP 実装) は どちらも /etc/ppp - ディレクトリに置かれた設定ファイルを使います. - ここには設定ファイルのサンプルが用意されていて, ユーザ ppp - の設定を おこなう際に大変参考になりますので, - 削除したりしないでください. - - ppp の設定をするためには, - 必要に応じていくつかのファイルを編集する必要が あります. - 書き込む内容は, プロバイダが静的に IP アドレスを割り当てる - (つまり, 固定の IP アドレスを一つ与えられて, 常にそれを使う) - か, または動的に IP アドレスを割り当てる (つまり, PPP - セッションごとに IP アドレスが変化する可能性がある) - かということに ある程度依存します. - + <command>ppp</command> の設定 + + ユーザ ppp と pppd (カーネルレベルの + PPP 実装) は どちらも /usr/share/examples/ppp + ディレクトリに置かれた設定ファイルを使います. + ここには設定ファイルのサンプルが用意されていて, ユーザ ppp + の設定を おこなう際に大変参考になりますので, + 削除したりしないでください. + + ppp の設定をするためには, + 必要に応じていくつかのファイルを編集する必要が あります. + 書き込む内容は, プロバイダが静的に IP アドレスを割り当てる + (つまり, 固定の IP アドレスを一つ与えられて, 常にそれを使う) + か, または動的に IP アドレスを割り当てる (つまり, PPP + セッションごとに IP アドレスが変化する可能性がある) + かということに ある程度依存します. + - 静的 IP アドレスによる PPP 接続 - - まず /etc/ppp/ppp.conf - という設定ファイルを作成する必要があります. - これは以下の例とほとんど同じようなものになるでしょう. - - - : で終る行は 1 カラム目から始め, - その他の行はスペースまたはタブで以下の例のように - 段をつける (インデントする) 必要があります. - - - + 静的 IP アドレスによる PPP 接続 + + まず /etc/ppp/ppp.conf + という設定ファイルを作成する必要があります. + これは以下の例とほとんど同じようなものになるでしょう. + + + : で終る行は 1 カラム目から始め, + その他の行はスペースまたはタブで以下の例のように + 段をつける (インデントする) 必要があります. + + + 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: 6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns - - ファイルでは行番号を取り除いておいてください. - これは解説の際に参照する行を示すためにつけたものです. - - - Line 1: - - デフォルトエントリを指定します. - このエントリ中のコマンドは ppp - が起動された際に自動的に実行されます. - - - - Line 2: - - モデムが接続されているデバイスを指定します. - COM1: は - /dev/cuaa0 に, - COM2: は - /dev/cuaa1 になります. - - - - Line 3: - - 通信速度 (DTE 速度) を指定します. もし 115200 - が使えない (最近のモデムなら大抵使えるはずですが) - 場合には, かわりに 38400 - を指定してみてください. - - - - Line 4: - - ダイアルスクリプトを指定します. ユーザ PPP は + + ファイルでは行番号を取り除いておいてください. + これは解説の際に参照する行を示すためにつけたものです. + + + Line 1: + + デフォルトエントリを指定します. + このエントリ中のコマンドは ppp + が起動された際に自動的に実行されます. + + + + Line 2: + + モデムが接続されているデバイスを指定します. + COM1: は + /dev/cuaa0 に, + COM2: は + /dev/cuaa1 になります. + + + + Line 3: + + 通信速度 (DTE 速度) を指定します. もし 115200 + が使えない (最近のモデムなら大抵使えるはずですが) + 場合には, かわりに 38400 + を指定してみてください. + + + + Line 4: + + ダイアルスクリプトを指定します. ユーザ PPP は &man.chat.8; 言語に似た, 受信待ち文字列と - 送信文字列の対からなるスクリプトを使用します. - この言語の機能に関しては, - マニュアルページを参照してください. - - - - Line 5: - - 接続するプロバイダの名前 “provider” を - エントリ名として指定します. - - - - Line 6: - - このプロバイダの電話番号を指定します. - 複数の電話番号を : や - | で区切って指定することができます. - これら区切り文字の違いについては, &man.ppp.8 - に 詳しく書かれています. - 要約すると, 毎回違う番号に かけたいのであれば - : を使います. 常に - まず先頭の番号にかけてみて, つながらない時にだけ 2 - 番目以降の番号に かけたいのであれば - | を使います. - 例に示されているように, 常に電話番号全体を引用符で - くくって (クォートして) おきます. - - - - Line 7: - - ダイアルスクリプトと同様に, ログインスクリプトも - chat 言語風の記述をおこないます. この例は, - 以下のようなログインセッションを使用する - プロバイダのためのものです: - + 送信文字列の対からなるスクリプトを使用します. + この言語の機能に関しては, + マニュアルページを参照してください. + + + + Line 5: + + 接続するプロバイダの名前 provider を + エントリ名として指定します. + + + + Line 6: + + このプロバイダの電話番号を指定します. + 複数の電話番号を : や + | で区切って指定することができます. + これら区切り文字の違いについては, &man.ppp.8 + に 詳しく書かれています. + 要約すると, 毎回違う番号に かけたいのであれば + : を使います. 常に + まず先頭の番号にかけてみて, つながらない時にだけ 2 + 番目以降の番号に かけたいのであれば + | を使います. + 例に示されているように, 常に電話番号全体を引用符で + くくって (クォートして) おきます. + + + + Line 7: + + ダイアルスクリプトと同様に, ログインスクリプトも + chat 言語風の記述をおこないます. この例は, + 以下のようなログインセッションを使用する + プロバイダのためのものです: + J. Random Provider login: foo password: bar protocol: ppp - このスクリプトは必要に応じて - 書きかえなければならないでしょう. - 初めてスクリプトを書く時には, 予想した通りに - 処理が進んだかどうかを確認するため, “chat” - ログを とるようにしておいた方が良いでしょう. - - PAP や CHAP を使用する場合には, - ここでログインすることは ありませんから, - ログイン文字列は空白のままにしておくべきです. - 詳細については PAP - および CHAP - による認証を参照してください. - - - - Line 8: - - デフォルトの接続タイムアウト時間を (秒数で) - 指定します. この例では, 300 秒間 - 通信がおこなわれなければ - 自動的に接続を切るように指定しています. - タイムアウトさせたくない場合には, この値を 0 - に設定します. - - - - Line 9: - - インターフェースのアドレスを指定します. 文字列 - x.x.x.x は - プロバイダに割り当てられた IP - アドレスで置きかえてください. 文字列 - y.y.y.y - はプロバイダから指示されたゲートウェイ - (接続先となるマシン) の IP - アドレスで置きかえてください. - プロバイダがゲートウェイのアドレスを - 指示していない場合は, 10.0.0.2/0 - を使用しておいてください. もし“仮の” - アドレスを使用する必要がある場合には, 動的 IP アドレスによる - PPP 接続に関する指示に従って, - /etc/ppp/ppp.linkup - にエントリを作成していることを 確認してください. - この行が省略されている場合, ppp を - - モードで動作させることはできません. - - - - Line 10: - - プロバイダのゲートウェイへの経路を - デフォルトルートとして 追加します. 特殊文字列 - HISADDR は, 9 行目で指定された - ゲートウェイのアドレスで置きかえられます. - HISADDR は 9 - 行目までは初期化されていませんので, - その行よりも後でしか使えないことに - 注意してください. - - - - Line 11: - - ネームサーバのアドレスが正しいか - どうかを確認するため, - プロバイダに問い合わせをおこなうよう ppp に指示します. - プロバイダがこの機能をサポートしていれば, ppp は - /etc/resolv.conf - のネームサーバエントリを - 正しいアドレスに更新することができます. - - - - - 静的な IP アドレスを持っていて, - 接続が完了する前にルーティングテーブルの - エントリが正しく設定されているのであれば, - ppp.linkup に - エントリを追加する必要はありません. しかし, - この場合でもエントリを追加して, 接続が完了した時点で - プログラムを呼び出したいことがあるかもしれません. - これについては後ほど sendmail を例として説明します. - - これらの設定ファイルのサンプルが - /etc/ppp ディレクトリに - 置かれています. + このスクリプトは必要に応じて + 書きかえなければならないでしょう. + 初めてスクリプトを書く時には, 予想した通りに + 処理が進んだかどうかを確認するため, chat + ログを とるようにしておいた方が良いでしょう. + + PAP や CHAP を使用する場合には, + ここでログインすることは ありませんから, + ログイン文字列は空白のままにしておくべきです. + 詳細については PAP + および CHAP + による認証を参照してください. + + + + Line 8: + + デフォルトの接続タイムアウト時間を (秒数で) + 指定します. この例では, 300 秒間 + 通信がおこなわれなければ + 自動的に接続を切るように指定しています. + タイムアウトさせたくない場合には, この値を 0 + に設定します. + + + + Line 9: + + インターフェースのアドレスを指定します. 文字列 + x.x.x.x は + プロバイダに割り当てられた IP + アドレスで置きかえてください. 文字列 + y.y.y.y + はプロバイダから指示されたゲートウェイ + (接続先となるマシン) の IP + アドレスで置きかえてください. + プロバイダがゲートウェイのアドレスを + 指示していない場合は, 10.0.0.2/0 + を使用しておいてください. もし 仮の + アドレスを使用する必要がある場合には, + 動的 IP アドレスによる + PPP 接続に関する指示に従って, + /etc/ppp/ppp.linkup + にエントリを作成していることを 確認してください. + この行が省略されている場合, ppp を + + モードで動作させることはできません. + + + + Line 10: + + プロバイダのゲートウェイへの経路を + デフォルトルートとして 追加します. 特殊文字列 + HISADDR は, 9 行目で指定された + ゲートウェイのアドレスで置きかえられます. + HISADDR は 9 + 行目までは初期化されていませんので, + その行よりも後でしか使えないことに + 注意してください. + + + + Line 11: + + ネームサーバのアドレスが正しいか + どうかを確認するため, + プロバイダに問い合わせをおこなうよう ppp に指示します. + プロバイダがこの機能をサポートしていれば, ppp は + /etc/resolv.conf + のネームサーバエントリを + 正しいアドレスに更新することができます. + + + + + 静的な IP アドレスを持っていて, + 接続が完了する前にルーティングテーブルの + エントリが正しく設定されているのであれば, + ppp.linkup に + エントリを追加する必要はありません. しかし, + この場合でもエントリを追加して, 接続が完了した時点で + プログラムを呼び出したいことがあるかもしれません. + これについては後ほど sendmail を例として説明します. + + これらの設定ファイルのサンプルが + /usr/share/examples/ppp ディレクトリに + 置かれています. - + - 動的 IP アドレスによる PPP 接続 - - プロバイダが静的な IP - アドレスの割り当てをおこなっていない場合, - ppp が相手側のホスト (ゲートウェイ) - と交渉して, こちら側と相手側のアドレスを - 決めるように設定することができます. これは, - 起動時には“仮の”アドレスを使っておいて, - 接続後に IP コンフィグレーション プロトコル (IPCP) - を使用して ppp が IP - アドレスを正しく設定できるようにすることで実現されます. - 静的 IP アドレスによる PPP - 接続に 以下の変更を加える以外は, - ppp.conf の設定は同じです: - - + 動的 IP アドレスによる PPP 接続 + + プロバイダが静的な IP + アドレスの割り当てをおこなっていない場合, + ppp が相手側のホスト (ゲートウェイ) + と交渉して, こちら側と相手側のアドレスを + 決めるように設定することができます. これは, + 起動時には仮のアドレスを使っておいて, + 接続後に IP コンフィグレーション プロトコル (IPCP) + を使用して ppp が IP + アドレスを正しく設定できるようにすることで実現されます. + 静的 IP アドレスによる PPP + 接続に 以下の変更を加える以外は, + ppp.conf の設定は同じです: + + 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 - 繰り返しますが, 行番号は取り除いておいてください. - これは解説の際に参照する行を示すためにつけたものです. なお, - 少なくともスペース 1 個分の段づけ (インデント) - が必要です. - - - Line 9: - - / 文字の後ろの数字は, - アドレス交渉の際に固定しておきたい ビットの数です. - 場合によっては, もっと適切な IP アドレスを - 指定しておきたいこともあるかもしれませんが, - ほとんどの場合には 上の例の通りで問題ありません. - - - 最後の引数 (0.0.0.0) は, - アドレスの交渉の際に 10.0.0.1 ではなく 0.0.0.0 を使用するよう ppp - に指示するためのものです. set - ifaddr コマンドの最初の引数として - 0.0.0.0 を指定してはいけません. - さもないと, - モードで動作させる際に - 初期経路を設定することができなくなります. - - - - - バージョン 1.X の ppp を使用する場合, - /etc/ppp/ppp.linkup - にもエントリを作成しておく必要があります. - ppp.linkup - は接続が確立された後に使用されます. この時点では, - ppp は実際にどの IP - アドレスを使うべきなのか わかっているはずです. - 以下のエントリは存在する仮の経路を削除し, - 正しい経路を作成します: - - + 繰り返しますが, 行番号は取り除いておいてください. + これは解説の際に参照する行を示すためにつけたものです. なお, + 少なくともスペース 1 個分の段づけ (インデント) + が必要です. + + + Line 9: + + / 文字の後ろの数字は, + アドレス交渉の際に固定しておきたい ビットの数です. + 場合によっては, もっと適切な IP アドレスを + 指定しておきたいこともあるかもしれませんが, + ほとんどの場合には 上の例の通りで問題ありません. + + + 最後の引数 (0.0.0.0) は, + アドレスの交渉の際に 10.0.0.1 + ではなく 0.0.0.0 を使用するよう ppp + に指示するためのものです. set + ifaddr コマンドの最初の引数として + 0.0.0.0 を指定してはいけません. + さもないと, + モードで動作させる際に + 初期経路を設定することができなくなります. + + + + + バージョン 1.X の ppp を使用する場合, + /etc/ppp/ppp.linkup + にもエントリを作成しておく必要があります. + ppp.linkup + は接続が確立された後に使用されます. この時点では, + ppp は実際にどの IP + アドレスを使うべきなのか わかっているはずです. + 以下のエントリは存在する仮の経路を削除し, + 正しい経路を作成します: + + 1 provider: 2 delete ALL 3 add default HISADDR - - Line 1: - - 接続を確立する際に, ppp - は以下のルールに従って - ppp.linkup - のエントリを検索します: まず - ppp.conf - で使用されたのと同じラベルを探します. - もし見つからなければ, ゲートウェイの IP - アドレスのエントリを 探します. このエントリは 4 - オクテットの IP アドレス形式の ラベルです. それでも - まだエントリが見つからなければ, - MYADDR エントリを探します. - - - - Line 2: - - この行は, 使用する tun - インターフェースに関する既存の経路を - (ダイレクトルートのエントリを除き) すべて削除するよう - ppp に指示します. - - - - Line 3: - - この行は HISADDR - への経路をデフォルトルートとして 追加するように ppp - に指示します. HISADDR は IPCP で - 決定されたゲートウェイの IP - アドレスで置きかえられます. - - - - - 詳細なサンプルについては, - /etc/ppp/ppp.conf.sample ファイル中の - pmdemand エントリと - /etc/ppp/ppp.linkup.sample - を参照してください. - - バージョン 2 の ppp から “sticky routes” - が導入されました. MYADDR や - HISADDR を含む add - コマンドと delete コマンドを記憶して, - MYADDR や HISADDR の - アドレスが変化した際には経路の再設定をおこないます. - したがって, これらのコマンドを - ppp.linkup に - 繰り返し記述する必要は無くなりました. + + + Line 1: + + + 接続を確立する際に, ppp + は以下のルールに従って + ppp.linkup + のエントリを検索します: まず + ppp.conf + で使用されたのと同じラベルを探します. + もし見つからなければ, ゲートウェイの IP + アドレスのエントリを 探します. このエントリは 4 + オクテットの IP アドレス形式の ラベルです. それでも + まだエントリが見つからなければ, + MYADDR エントリを探します. + + + + + Line 2: + + + この行は, 使用する tun + インターフェースに関する既存の経路を + (ダイレクトルートのエントリを除き) すべて削除するよう + ppp に指示します. + + + + + Line 3: + + + この行は HISADDR + への経路をデフォルトルートとして 追加するように ppp + に指示します. HISADDR は IPCP で + 決定されたゲートウェイの IP + アドレスで置きかえられます. + + + + + 詳細なサンプルについては, + /usr/share/examples/ppp/ppp.conf.sample + ファイル中のpmdemand エントリと + /usr/share/examples/ppp/ppp.linkup.sample + を参照してください. + + バージョン 2 の ppp から sticky routes + が導入されました. MYADDR や + HISADDR を含む add + コマンドと delete コマンドを記憶して, + MYADDR や HISADDR の + アドレスが変化した際には経路の再設定をおこないます. + したがって, これらのコマンドを + ppp.linkup に + 繰り返し記述する必要は無くなりました. - + - かかってきた電話を <command>ppp</command> - で受けるには - - かかってきた電話を ppp - が受けるように設定する際に, そのマシンが LAN - に接続されているのであれば, パケットを LAN - に転送するかどうかを決定する必要があります. - 転送をおこなう場合には, その LAN のサブネットから IP - アドレスを ppp クライアントに割り当て, - 以下のコマンドを指定するのが良いでしょう. - - + かかってきた電話を <command>ppp</command> + で受けるには + + かかってきた電話を ppp + が受けるように設定する際に, そのマシンが LAN + に接続されているのであれば, パケットを LAN + に転送するかどうかを決定する必要があります. + 転送をおこなう場合には, その LAN のサブネットから IP + アドレスを ppp クライアントに割り当て, + 以下のコマンドを指定するのが良いでしょう. + + gateway_enable=YES - どの getty を使いますか? - - getty - でダイアルアップサービスをおこなう場合の優れた解説が FreeBSD - でダイアルアップサービスをおこなうための設定 - にあります. - - getty に代わるものとしては, - mgetty があります. これは - getty をより柔軟にしたもので, - ダイアルアップ回線での使用を意図して - 設計されています. - - mgetty を使う場合の利点は, - mgetty - が積極的にモデムと通信する - ということです. つまり, もし - /etc/ttys でポートを閉じている場合, - モデムは電話をとらなくなります. - - 最近のバージョンの mgetty (0.99beta - 以降) では, PPP ストリームの - 自動検出もサポートされています. これにより, - クライアント側で スクリプトを準備しなくてもサーバに - アクセスすることができます. - - mgetty に関する, - より詳細な情報については Mgetty と AutoPPP - を参照してください. + どの getty を使いますか? + + getty + でダイアルアップサービスをおこなう場合の優れた解説が + FreeBSD + でダイアルアップサービスをおこなうための設定 + にあります. + + getty に代わるものとしては, + + mgetty があります. これは + getty をより柔軟にしたもので, + ダイアルアップ回線での使用を意図して + 設計されています. + + mgetty を使う場合の利点は, + mgetty + が積極的にモデムと通信する + ということです. つまり, もし + /etc/ttys でポートを閉じている場合, + モデムは電話をとらなくなります. + + 最近のバージョンの mgetty (0.99beta + 以降) では, PPP ストリームの + 自動検出もサポートされています. これにより, + クライアント側で スクリプトを準備しなくてもサーバに + アクセスすることができます. + + mgetty に関する, + より詳細な情報については + Mgetty と AutoPPP + を参照してください. - + - ppp の実行許可 - - ppp は通常, ID 0 のユーザ (root) - として動作しなければいけませんが, 以下で説明するように, - ppp - を通常のユーザとしてサーバモードで実行させたい 場合には, - そのユーザを /etc/group の - network グループに 追加して, ppp - を実行する許可を与えておかなければいけません. - - また, そのユーザが設定ファイル内の目的のエントリに - アクセスできるように, 以下のように - allow - コマンドで許可を与えておく必要があります: - - + ppp の実行許可 + + ppp は通常, ID 0 のユーザ (root) + として動作しなければいけませんが, 以下で説明するように, + ppp + を通常のユーザとしてサーバモードで実行させたい 場合には, + そのユーザを /etc/group の + network グループに 追加して, ppp + を実行する許可を与えておかなければいけません. + + また, そのユーザが設定ファイル内の目的のエントリに + アクセスできるように, 以下のように + allow + コマンドで許可を与えておく必要があります: + + allow users fred mary - このコマンドがデフォルトエントリに - 書かれている場合には, 指定されたユーザは - すべてのエントリをアクセスできるようになります. + このコマンドがデフォルトエントリに + 書かれている場合には, 指定されたユーザは + すべてのエントリをアクセスできるようになります. - + - 動的 IP ユーザのための ppp シェルの設定 - - /etc/ppp/ppp-shell という名前で, - 以下のような内容のファイルを 作成します: + 動的 IP ユーザのための ppp シェルの設定 + + /etc/ppp/ppp-shell という名前で, + 以下のような内容のファイルを 作成します: - + #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT - このスクリプトには実行可能属性をつけておきます. 次に, - 以下のコマンドを実行し, ppp-dialup - という名前で このスクリプトへのリンクを作成します: + このスクリプトには実行可能属性をつけておきます. 次に, + 以下のコマンドを実行し, ppp-dialup + という名前で このスクリプトへのリンクを作成します: - &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup + &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup - すべてのダイアルアップ ppp - ユーザのログインシェルとして - このスクリプトを使用します. 以下は - pchilds というユーザ名の - ダイアルアップユーザを /etc/password - へ登録した場合の例です. - (パスワードファイルを直接エディタで編集したりせず, - vipw を使ってください) + すべてのダイアルアップ ppp + ユーザのログインシェルとして + このスクリプトを使用します. 以下は + pchilds というユーザ名の + ダイアルアップユーザを /etc/password + へ登録した場合の例です. + (パスワードファイルを直接エディタで編集したりせず, + vipw を使ってください) - + pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup - 任意のユーザが読むことのできる, - /home/ppp ディレクトリを 作成します. - /etc/motd - が表示されないようにするため, - このディレクトリには以下のように大きさが 0 - バイトのファイルを 作成しておきます. + 任意のユーザが読むことのできる, + /home/ppp ディレクトリを 作成します. + /etc/motd + が表示されないようにするため, + このディレクトリには以下のように大きさが 0 + バイトのファイルを 作成しておきます. - -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin + -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts - - 静的 IP ユーザのための PPP シェルの設定 - - 上記と同じように ppp-shell - ファイルを作成し, 静的な IP - アドレスを割り当てるアカウントそれぞれについて - ppp-shell - へのシンボリックリンクを作成します. - - 例えば, クラス C ネットワークの経路制御を必要とする, - 三人のダイアルアップユーザ fred, - sam, mary - がいるとすると, - 以下のコマンドを実行することになります: - - &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred + 静的 IP ユーザのための PPP シェルの設定 + + 上記と同じように ppp-shell + ファイルを作成し, 静的な IP + アドレスを割り当てるアカウントそれぞれについて + ppp-shell + へのシンボリックリンクを作成します. + + 例えば, クラス C ネットワークの経路制御を必要とする, + 三人のダイアルアップユーザ fred, + sam, mary + がいるとすると, + 以下のコマンドを実行することになります: + + &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary - これらのユーザのダイアルアップアカウントでは, - 上で作成した それぞれのシンボリックリンクを - ログインシェルとして設定しておきます. (つまり, ユーザ - mary のログインシェルは - /etc/ppp/ppp-mary に - なります). + これらのユーザのダイアルアップアカウントでは, + 上で作成した それぞれのシンボリックリンクを + ログインシェルとして設定しておきます. (つまり, ユーザ + mary のログインシェルは + /etc/ppp/ppp-mary に + なります). - + - 動的 IP ユーザのための ppp.conf の設定 - - /etc/ppp/ppp.conf ファイルは, - 大体以下のような内容になるでしょう: - - + 動的 IP ユーザのための ppp.conf の設定 + + /etc/ppp/ppp.conf ファイルは, + 大体以下のような内容になるでしょう: + + default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy - - - 上の例のように段をつける (インデントする) - 必要があることに注意してください. - - - default: - エントリはセッションごとにロードされます. - /etc/ttys - で有効にしてある各ダイアルアップ回線ごとに一つ, 上記の - ttyd0: のようなエントリを作成します. - 各行の相手側アドレスとして, それぞれ別の IP アドレスを - 動的 IP ユーザのための IP - アドレスのプールから割り当てておく必要があります. + + + 上の例のように段をつける (インデントする) + 必要があることに注意してください. + + + default: + エントリはセッションごとにロードされます. + /etc/ttys + で有効にしてある各ダイアルアップ回線ごとに一つ, 上記の + ttyd0: のようなエントリを作成します. + 各行の相手側アドレスとして, それぞれ別の IP アドレスを + 動的 IP ユーザのための IP + アドレスのプールから割り当てておく必要があります. - + - 静的 IP ユーザのための <filename>ppp.conf</filename> - の設定 - - 上のサンプルの /etc/ppp/ppp.conf - の内容に加えて, 静的に IP - を割り当てられたダイアルアップユーザ - それぞれのためのエントリを追加する必要があります. - ここでも fred, - sam, mary - の例を使うことにしましょう. - - + 静的 IP ユーザのための <filename>ppp.conf</filename> + の設定 + + 上のサンプルの + /usr/share/examples/ppp/ppp.conf + の内容に加えて, 静的に IP + を割り当てられたダイアルアップユーザ + それぞれのためのエントリを追加する必要があります. + ここでも fred, + sam, mary + の例を使うことにしましょう. + + fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 - 必要であれば, それぞれの静的 IP - ユーザに対する経路制御情報も - /etc/ppp/ppp.linkup - ファイルに書いておくべきでしょう. - 以下の例ではクライアントの PPP リンクを経由する, クラス C - の 203.14.101.0 - ネットワークへの経路を追加しています. + 必要であれば, それぞれの静的 IP + ユーザに対する経路制御情報も + /etc/ppp/ppp.linkup + ファイルに書いておくべきでしょう. + 以下の例ではクライアントの PPP リンクを経由する, クラス C + の 203.14.101.0 + ネットワークへの経路を追加しています. - + fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR - + <command>mgetty</command>, AutoPPP, マイクロソフト拡張の詳細 - + <command>mgetty</command> と AutoPPP - + AUTO_PPP オプションつきでコンパイルした mgetty を使えば, mgetty が PPP 接続の LCP フェーズを検出して, 自動的に PPP シェルを起動するように 設定することができます. しかし この場合, デフォルトの login/password シーケンスは発生しないので, ユーザの認証は PAP または CHAP を使っておこなう必要があります. このセクションでは, ユーザ (あなた) が問題なく AUTO_PPP オプションつきの mgetty (v0.99beta またはそれ以降) の設定, コンパイル, インストールができているものと仮定しています. /usr/local/etc/mgetty+sendfax/login.config ファイルが 以下の行を含んでいることを確認してください: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup これにより, PPP 接続を検出したら mgetty が ppp-pap-dialup スクリプトを実行するようになります. /etc/ppp/ppp-pap-dialup という名前で, 以下のような内容のファイルを 作成します (このファイルには実行可能属性を つけておく必要があります): #!/bin/sh exec /usr/sbin/ppp -direct pap さらに, かかってきた電話すべてを自分で扱うエントリを /etc/ppp/ppp.conf に作成します. pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy この方法でログインする それぞれのユーザは, PAP によるユーザ認証を おこなうために /etc/ppp/ppp.secret ファイルにユーザ名とパスワードを 書いておくか, または /etc/password ファイルを使うように, enable passwdauth ユーザに静的な IP アドレスを割り当てる場合には, そのアドレスを /etc/ppp/ppp.secret の第三引数として指定することができます. サンプルについては, - /etc/ppp/ppp.secret.sample + /usr/share/examples/ppp/ppp.secret.sample を参照してください. マイクロソフト拡張 クライアントからの要求に応じて, ppp が DNS や NetBIOS ネームサーバの アドレスを通知するように 設定をおこなうこともできます. バージョン 1.X の ppp で これらの拡張機能を有効にするには, 以下の行を /etc/ppp/ppp.conf の適切なセクションに追加する必要があるでしょう. enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 バージョン 2 以降の ppp では, 以下のようになります: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 これにより, クライアントはプライマリと セカンダリのネームサーバアドレス および NetBIOS ネームサーバホストを知ることができます. バージョン 2 以降の ppp では, set dns の行を省略した場合には /etc/resolv.conf に書かれているネームサーバのアドレスを使用します. - + - PAP および CHAP による認証 - - いくつかのプロバイダでは, PAP または CHAP - のいずれかの認証メカニズムを - 使用して接続時の認証をおこなうように - システムを設定しています. この場合, プロバイダは接続の際に - login: プロンプトを送信せず, 最初から PPP - で通信を始めようとするでしょう. - - PAP ではパスワードがそのまま送られてしまうため, CHAP - に比べると安全性が 低くなりますが, - このパスワードはシリアル回線のみを通して送られます. - そのため, - クラッカーが“盗み聞き”する余地は多くないので, - 通常ここの セキュリティは問題にはなりません. - - 静的 IP アドレスによる - PPP 接続または 動的 IP アドレスによる PPP - 接続の セクションに戻って, - 以下の変更をおこないます: - - + PAP および CHAP による認証 + + いくつかのプロバイダでは, PAP または CHAP + のいずれかの認証メカニズムを + 使用して接続時の認証をおこなうように + システムを設定しています. この場合, プロバイダは接続の際に + login: プロンプトを送信せず, 最初から PPP + で通信を始めようとするでしょう. + + PAP ではパスワードがそのまま送られてしまうため, CHAP + に比べると安全性が 低くなりますが, + このパスワードはシリアル回線のみを通して送られます. + そのため, + クラッカーが 盗み聞き する余地は多くないので, + 通常ここの セキュリティは問題にはなりません. + + 静的 IP アドレスによる + PPP 接続または + 動的 IP アドレスによる PPP + 接続の セクションに戻って, + 以下の変更をおこないます: + + 7 set login … 12 set authname MyUserName 13 set authkey MyPassword - これまでと同様に, 行番号は取り除いておいてください. - これは解説の際に参照する行を示すためにつけたものです. なお, - 少なくともスペース 1 個分の段づけ (インデント) - が必要です. - - - Line 7: - - PAP または CHAP を使用する場合, 通常 - プロバイダはサーバへの ログインを必要としません. - そのため, "set login" 文字列を - 無効にしておかなければいけません. - - - - Line 12: - - この行は PAP/CHAP ユーザ名を指定します. - MyUserName に - 正しい値を入れておく必要があります. - - - - Line 13: - - この行は PAP/CHAP パスワードを指定します. - MyPassword に - 正しい値を入れておく必要があります. - PAP と CHAP はデフォルトで両方とも - 受け付けられるようになって - いますが, PAP や CHAP を使用するという - 意思を明示するために, - - + これまでと同様に, 行番号は取り除いておいてください. + これは解説の際に参照する行を示すためにつけたものです. なお, + 少なくともスペース 1 個分の段づけ (インデント) + が必要です. + + + + Line 7: + + + PAP または CHAP を使用する場合, 通常 + プロバイダはサーバへの ログインを必要としません. + そのため, set login 文字列を + 無効にしておかなければいけません. + + + + + Line 12: + + + この行は PAP/CHAP ユーザ名を指定します. + MyUserName に + 正しい値を入れておく必要があります. + + + + + Line 13: + + + この行は PAP/CHAP パスワードを指定します. + MyPassword に + 正しい値を入れておく必要があります. + PAP と CHAP はデフォルトで両方とも + 受け付けられるようになって + いますが, PAP や CHAP を使用するという + 意思を明示するために, + + 15 accept PAP - または + または - + 15 accept CHAP - という行を追加しておくのも良いでしょう. - - - + という行を追加しておくのも良いでしょう. + + + - 動作中の ppp の設定変更 + 動作中の ppp の設定変更 - 適切な診断ポートが設定されている場合には, - バックグラウンドで動作中の ppp - プログラムと通信することができます. - この設定をおこなうためには, - 以下の行を設定ファイルに追加しておきます: + 適切な診断ポートが設定されている場合には, + バックグラウンドで動作中の ppp + プログラムと通信することができます. + この設定をおこなうためには, + 以下の行を設定ファイルに追加しておきます: - + set server /var/run/ppp-tun%d DiagnosticPassword 0177 - これにより, ppp は指定された unix ドメインの - ソケットをモニタして, - クライアントから正しいパスワードを受け取った後に - アクセスを許可します. このソケット名に含まれる - %d は, この ppp が使用している - tun - デバイスの デバイス番号で置きかえられます. - - 一旦ソケットの設定が終了したら, スクリプト中で - &man.pppctl.8; を 使用して, 動作中の ppp - を操作することができるでしょう. + これにより, ppp は指定された unix ドメインの + ソケットをモニタして, + クライアントから正しいパスワードを受け取った後に + アクセスを許可します. このソケット名に含まれる + %d は, この ppp が使用している + tun + デバイスの デバイス番号で置きかえられます. + + 一旦ソケットの設定が終了したら, スクリプト中で + &man.pppctl.8; を 使用して, 動作中の ppp + を操作することができるでしょう. - システムの最終設定 - - これで ppp の設定は終りました. しかし - ppp を動かす前に, - まだ少し必要なことがあります. それらの設定は, すべて - /etc/rc.conf ファイルを - 編集することでおこないます. (このファイルは以前には - /etc/sysconfig と呼ばれていました) - - このファイルを上から順に設定していきます. まずは - hostname= - の行が設定されていることを確認します. - 例えば以下のように: - - + システムの最終設定 + + これで ppp の設定は終りました. しかし + ppp を動かす前に, + まだ少し必要なことがあります. それらの設定は, すべて + /etc/rc.conf ファイルを + 編集することでおこないます. (このファイルは以前には + /etc/sysconfig と呼ばれていました) + + このファイルを上から順に設定していきます. まずは + hostname= + の行が設定されていることを確認します. + 例えば以下のように: + + hostname="foo.bar.com" - もしプロバイダが静的な IP - アドレスとホスト名を割り当てているのなら, - ホスト名としてそれを使うのが おそらくベストでしょう. - - 次に network_interfaces 変数を調べます. - 必要に応じて (on demand) - プロバイダにダイアルするようにシステムを設定したい場合には, - tun0 - デバイスがこのリストに追加されていることを確認しておきます. - それ以外の場合には, tun0 - デバイスをリストから削除しておきます. - - - + もしプロバイダが静的な IP + アドレスとホスト名を割り当てているのなら, + ホスト名としてそれを使うのが おそらくベストでしょう. + + 次に network_interfaces 変数を調べます. + 必要に応じて (on demand) + プロバイダにダイアルするようにシステムを設定したい場合には, + tun0 + デバイスがこのリストに追加されていることを確認しておきます. + それ以外の場合には, tun0 + デバイスをリストから削除しておきます. + + + network_interfaces="lo0 tun0" ifconfig_tun0= - - ifconfig_tun0 変数が空で, - /etc/start_if.tun0 という名前の - ファイルが作成されていなければなりません. - このファイルの内容は以下のようになります. - - + + ifconfig_tun0 変数が空で, + /etc/start_if.tun0 という名前の + ファイルが作成されていなければなりません. + このファイルの内容は以下のようになります. + + ppp -auto mysystem - このスクリプトはネットワークの設定時に実行され, ppp - デーモンを自動モードで立ち上げます. このマシンがもし LAN - のゲートウェイであれば, - スイッチも使用したいと思うかもしれません. 詳細に関しては, - マニュアルページを参照してください. - + このスクリプトはネットワークの設定時に実行され, ppp + デーモンを自動モードで立ち上げます. このマシンがもし LAN + のゲートウェイであれば, + スイッチも使用したいと思うかもしれません. 詳細に関しては, + マニュアルページを参照してください. + - 以下のようにルータプログラムを NO - に設定します. + 以下のようにルータプログラムを NO + に設定します. - + router_enable="NO" - routed は, ppp - が作成したデフォルトのルーティングテーブル - エントリを削除してしまう場合がありますので, - (初期設定では起動されるようになっている) - routed デーモンが - 起動されないようにしておくことが重要です. - - sendmail_flags 行が - オプションを含まないように 設定しておいた方がよいでしょう. - さもないと, sendmail が - アドレスを調べようとして発信をおこなってしまう場合があります. - 以下のような設定で良いでしょう: - - + routed は, ppp + が作成したデフォルトのルーティングテーブル + エントリを削除してしまう場合がありますので, + (初期設定では起動されるようになっている) + routed デーモンが + 起動されないようにしておくことが重要です. + + sendmail_flags 行が + オプションを含まないように 設定しておいた方がよいでしょう. + さもないと, sendmail が + アドレスを調べようとして発信をおこなってしまう場合があります. + 以下のような設定で良いでしょう: + + sendmail_flags="-bd" - この結果, PPP リンクを立ち上げた時には - いつでも以下のコマンドを実行して, キューにたまっているメールを - sendmail - に送信させる作業が必要になるでしょう. + この結果, PPP リンクを立ち上げた時には + いつでも以下のコマンドを実行して, キューにたまっているメールを + sendmail + に送信させる作業が必要になるでしょう. - &prompt.root; /usr/sbin/sendmail -q + &prompt.root; /usr/sbin/sendmail -q - ppp.linkup 中で - !bg コマンドを使用することで, - これを自動的に おこなうこともできます: + ppp.linkup 中で + !bg コマンドを使用することで, + これを自動的に おこなうこともできます: - + 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m - こうするのが嫌であれば, SMTP - トラフィックをブロックするように “dfilter” - を設定しておくこともできます. - 詳細についてはサンプルファイルを参照してください. - - 後はマシンをリブートするだけです. - - リブートが終ったら, - - &prompt.root; ppp - - コマンドを実行し, 続いて PPP セッションを開始させるために - dial provider と入力することもできますし, - (start_if.tun0 - スクリプトを作成していない場合に), - 外部へのトラフィックが発生した時に, ppp - が自動的に セッションを確立してくれるようにしたいのであれば, - 以下のコマンドを実行することもできます. - - &prompt.root; ppp -auto provider + こうするのが嫌であれば, SMTP + トラフィックをブロックするように dfilter + を設定しておくこともできます. + 詳細についてはサンプルファイルを参照してください. + + 後はマシンをリブートするだけです. + + リブートが終ったら, + + &prompt.root; ppp + + コマンドを実行し, 続いて PPP セッションを開始させるために + dial provider と入力することもできますし, + (start_if.tun0 + スクリプトを作成していない場合に), + 外部へのトラフィックが発生した時に, ppp + が自動的に セッションを確立してくれるようにしたいのであれば, + 以下のコマンドを実行することもできます. + + &prompt.root; ppp -auto provider - まとめ - - 要約すると, 初めて ppp を設定する際には, - 以下のステップが不可欠です: - - クライアント側: - - - - カーネルに tun - デバイスが組み込まれていることを確認. - - - - /dev ディレクトリに - tunX - デバイスファイルが 存在することを確認. - - - - /etc/ppp/ppp.conf - にエントリを作成. ほとんどのプロバイダでは, - pmdemand の例で充分でしょう. - - - - 動的 IP アドレスを使用するなら, - /etc/ppp/ppp.linkup に - エントリを作成. - - - - /etc/rc.conf (または - sysconfig) ファイルを更新. - - - - 必要に応じてダイヤル (demand dialing) - したいのであれば, start_if.tun0 - スクリプトを作成. - - - - サーバ側: - - - - カーネルに tun - デバイスが組み込まれていることを確認. - - - - /dev ディレクトリに - tunX - デバイスファイルが 存在することを確認. - - - - (&man.vipw.8; コマンドを使って) - /etc/passwd にエントリを作成. - - - - このユーザのホームディレクトリに ppp -direct - direct-server - か何かを実行するプロファイルを作成. - - - - /etc/ppp/ppp.conf - にエントリを作成. direct-server - の例で充分でしょう. - - - - /etc/ppp/ppp.linkup - にエントリを作成. - - - - /etc/rc.confファイルを更新. - - + まとめ + + 要約すると, 初めて ppp を設定する際には, + 以下のステップが不可欠です: + + クライアント側: + + + + カーネルに tun + デバイスが組み込まれていることを確認. + + + + /dev ディレクトリに + tunX + デバイスファイルが 存在することを確認. + + + + /etc/ppp/ppp.conf + にエントリを作成. ほとんどのプロバイダでは, + pmdemand の例で充分でしょう. + + + + 動的 IP アドレスを使用するなら, + /etc/ppp/ppp.linkup に + エントリを作成. + + + + /etc/rc.conf (または + sysconfig) ファイルを更新. + + + + 必要に応じてダイヤル (demand dialing) + したいのであれば, start_if.tun0 + スクリプトを作成. + + + + サーバ側: + + + + カーネルに tun + デバイスが組み込まれていることを確認. + + + + /dev ディレクトリに + tunX + デバイスファイルが 存在することを確認. + + + + (&man.vipw.8; コマンドを使って) + /etc/passwd にエントリを作成. + + + + このユーザのホームディレクトリに ppp -direct + direct-server + か何かを実行するプロファイルを作成. + + + + /etc/ppp/ppp.conf + にエントリを作成. direct-server + の例で充分でしょう. + + + + /etc/ppp/ppp.linkup + にエントリを作成. + + + + /etc/rc.confファイルを更新. + + - + カーネル PPP の利用 - + 原作: &a.gena;, &a.rhuff;. 訳: &a.jp.graphite;. - 6 September 1996. + 1996 年 9 月 6 日. - Setting up Kernel PPP - - PPP の設定を始める前に, pppd が - /usr/sbin にあり, また - /etc/ppp という - ディレクトリが存在することを確認してください. - - pppd はふたつのモードで動作します. - - - - “クライアント”モード. - シリアル接続やモデムを利用して, そのマシンを - 外部のネットワークに PPP 接続したい場合に用います. - - - - “サーバ”モード. - そのマシンがネットワーク上にあるときに, PPP を使って - ほかのコンピュータを接続する際に用います. - - - - どちらの場合でも, オプションファイルを設定する必要があります - (/etc/ppp/options または, そのマシン上で - PPP を使用する人が 複数いる場合には - ~/.ppprc). - - また, ダイヤルとリモートホストへの接続をおこなうために, - シリアル接続やモデムを 操作する, - なんらかのソフトウェアが必要です (kermit - が適しているでしょう). - + カーネル PPP の設定 + PPP の設定を始める前に, pppd が + /usr/sbin にあり, また + /etc/ppp という + ディレクトリが存在することを確認してください. + + pppd はふたつのモードで動作します. + + + + クライアント モード. + シリアル接続やモデムを利用して, そのマシンを + 外部のネットワークに PPP 接続したい場合に用います. + + + + サーバ モード. + そのマシンがネットワーク上にあるときに, PPP を使って + ほかのコンピュータを接続する際に用います. + + + + どちらの場合でも, オプションファイルを設定する必要があります + (/etc/ppp/options または, そのマシン上で + PPP を使用する人が 複数いる場合には + ~/.ppprc). + + また, ダイヤルとリモートホストへの接続をおこなうために, + シリアル接続やモデムを 操作する, + なんらかのソフトウェアが必要です (kermit + が適しているでしょう). + + PPP クライアントとしての動作 - 私は, CISCO ターミナルサーバの PPP 回線に接続するために, + わたしは, CISCO ターミナルサーバの PPP 回線に接続するために, 下記のような /etc/ppp/options を使用しています. crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here :<remote_ip> # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be your # default router 接続方法: kermit (またはその他のモデム操作プログラム) を使ってリモートホストに ダイヤルし, 接続してください. そして, あなたのユーザ名とパスワード (必要 であれば, その他にもリモートホストで PPP を有効にするための操作) を入力 します. kermit を抜けてください. (回線を切断せずに) 下記のように入力します: &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 (通信速度とデバイス名には, あなたの環境に適したものを入れてください) これでこのコンピュータは PPP で接続されました. もし, なんらかの理由で 接続に失敗したならば, /etc/ppp/options ファイルに オプションを追加して, 問題点を突き止めるために, コンソールに表示される メッセージを調べてください. 下記の /etc/ppp/pppup スクリプトは, 上記の作業を すべて自動的におこないます: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 /etc/ppp/kermit.dial は kermit 用のスクリプトで, ダイヤルして, リモートホストでの認証に必要なすべての処理をおこないます. (そのようなスクリプトの例は この文書の終わりに添付してあります) PPP 接続を切断するには, 下記のような /etc/ppp/pppdown スクリプトを 使用します: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest PPP が動作中かどうかを調べます (/usr/etc/ppp/ppptest): #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 モデム回線を切断します (/etc/ppp/kermit.hup): set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit 次は kermit の代わりに chat を使う方法です. 原作: &a.rhuff;. pppd 接続を確立するためには, 次の二つのファイルの設定だけで十分です. /etc/ppp/options: /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain <your.domain> # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be # your default router /etc/ppp/login.chat.script: (実際には一行になります.) ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id> TIMEOUT 5 sword: <password> 正しくインストールし編集した後は, 必要な事はこれだけです &prompt.root; pppd このサンプルは主に Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> から寄せられた情報に基づいており, 承諾を得て使用しています. PPP サーバとしての動作 /etc/ppp/options: crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line 下記のような /etc/ppp/pppserv スクリプトで, そのマシンを PPP サーバにすることができます. #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 PPP サーバを終了するには, この /etc/ppp/pppservdown スクリプト を使用します: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans 下記の kermit スクリプトは, モデムの自動応答機能を有効, または無効にします (/etc/ppp/kermit.ans): set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit この /etc/ppp/kermit.dial スクリプトは, リモートホストに ダイヤルし, 認証手続きをするのに使用します. あなたは必要に応じて, これを 変更しないといけないでしょう. あなたのユーザ名とパスワードをこの スクリプトに書かなければいけませんし, モデムやリモートホストからの 応答によっては, 入力待ちの文を変更する必要もあります. ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: PPP オーバイーサネット (PPPoE) の利用 - 原作: &a.jim; (node.to より) 10 Jan 2000. + 原作: &a.jim; ( node.to より) 10 Jan 2000. 以下の解説は, PPPoE として知られる, PPP オーバイーサネットの設定法です. 必要なもの あなたのシステムで PPPoE を適切に機能させるためには, 以下のものが必要です. - FreeBSD &rel.current;-STABLE のカーネルソース + FreeBSD 3.4やそれより新しいバージョンのカーネルソース - FreeBSD &rel.current;-STABLE の - ppp と pppd - - - - - 上にあげたものが依存している, すべてのもの + FreeBSD 3.4やそれより新しいバージョンのppp カーネルコンフィギュレーション 以下に示すオプションをカーネルコンフィギュレーションファイルに 追加して, その後 新しいカーネルを コンパイルする必要があります. options NETGRAPH + - - options NETGRAPH_ASYNC - - - - options NETGRAPH_BPF - - - - options NETGRAPH_CISCO - - - - options NETGRAPH_ECHO - - - - options NETGRAPH_FRAME_RELAY - - - - options NETGRAPH_HOLE - - - - options NETGRAPH_IFACE - - - - options NETGRAPH_KSOCKET - - - - options NETGRAPH_LMI - - - - options NETGRAPH_PPP - - + 以下は任意 + + options NETGRAPH_PPPOE - - options NETGRAPH_PPTPGRE - - - - options "NETGRAPH_RFC1490" - - options NETGRAPH_SOCKET - - - options NETGRAPH_TEE - - - - options NETGRAPH_TTY - - - - options NETGRAPH_UI - - - - options NETGRAPH_VJC - - 上述のオプションをカーネルコンフィギュレーションに追加し, - カーネルの再構築を行なって下さい. それが完了したら, - カーネルをインストールしてシステムを再起動させます. + + この機能は実行時には有効ではありませんが, 要求に応じて + ppp は関係のあるモジュールを + 読み込みます. + <filename>ppp.conf</filename> の設定 これは動作している ppp.conf の 例です: default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device - set MRU 1490 - set MTU 1490 + set mru 1492 + set mtu 1492 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial - set login "TIMEOUT 1.5 name:-\\r-login:\\U word:\\P ocol:PPP HELLO" # this isn't necessary + set login set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net - set cd off - set crtscts off papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD + + + + オプションを付けてPPPoE + を起動する際には注意するべきです. + + <application>PPP</application> の起動 - 下のいずれかを root 権限において実行することで, - 起動させることができます.: + 以下を root 権限において実行することで, + 起動させることができます.: - &prompt.root; ppp -dedicated - - または - - &prompt.root; ppp -dedicated name_of_service_provider - - です. これは, ppp.conf をあなたがどのように - 設定したかによります. + &prompt.root; ppp -ddial name_of_service_provider システム起動時に <application>PPP</application> を立ち上げる /etc/rc.conf ファイルに以下の行を追加 してください: ppp_enable="YES" -ppp_mode="dedicated" +ppp_mode="ddial" ppp_nat="YES" ppp_profile="default" # or your provider SLIP の利用 - + 原作: &a.asami;,&a.ghelmer;, 協力: &a.wilko;, &a.piero;. - 訳: &a.hanai;8 August 1996. + + 訳: &a.hanai; + 1996 年 8 月 8 日. - SLIPクライアントのセットアップ - - ここには FreeBSD - マシンを静的アドレスのネットワークにつなげる場合の - SLIPのセットアップの一つの方法を書いてあります. - ホスト名を動的に割り当てる(つまり, - ダイヤルアップするたびにアドレスが かわる)ためには, - おそらくもっと凝ったことが必要です. - - まず, - モデムがどのシリアルポートにつながっているか決めましょう. 私は - /dev/cuaa1 から - /dev/modemへというシンボリックリンクを張り, - コンフィグレーションではその名前だけを使っています. - /etc や.kermrc - など, システム全体に散らばっているファイルを修正する - 必要がでるとまったく煩わしいのです! - - - ここで, /dev/cuaa0は - COM1であり, - cuaa1はCOM2です. - - - カーネルのコンフィグレーションファイルに + SLIPクライアントのセットアップ + + ここには FreeBSD + マシンを静的アドレスのネットワークにつなげる場合の + SLIPのセットアップの一つの方法を書いてあります. + ホスト名を動的に割り当てる(つまり, + ダイヤルアップするたびにアドレスが かわる)ためには, + おそらくもっと凝ったことが必要です. + + まず, + モデムがどのシリアルポートにつながっているか決めましょう. 私は + /dev/cuaa1 から + /dev/modemへというシンボリックリンクを張り, + コンフィグレーションではその名前だけを使っています. + /etc や.kermrc + など, システム全体に散らばっているファイルを修正する + 必要がでるとまったく煩わしいのです! + + + ここで, /dev/cuaa0は + COM1であり, + cuaa1はCOM2です. + - + カーネルのコンフィグレーションファイルに + + pseudo-device sl 1 - という記述があるのを確認してください. - これは GENERIC カーネルに含まれている - ので削除していない限り大丈夫でしょう. + という記述があるのを確認してください. + これは GENERIC カーネルに含まれている + ので削除していない限り大丈夫でしょう. 最初の設定 - - - /etc/hosts - ファイルにあなたのマシンのゲートウェイとネームサーバ - を加えてください. 私のは以下のようになっています. + + + /etc/hosts + ファイルにあなたのマシンのゲートウェイとネームサーバ + を加えてください. 私のは以下のようになっています. - + 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 - - /etc/host.conf ファイル中で - が - よりも前にあること を確認してください. - さもないとヘンなことが起こるかもしれません. - - - - /etc/rc.conf - ファイルを編集してください. なお, お使いの FreeBSD が - 2.2.2 よりも前のバージョンのものの場合は, - /etc/sysconfig - を編集してください. - - - - 行 - - -hostname=myname.my.domain - - を編集してホスト名をセットしてください. - 完全なInternetホスト名を与えるべきです. - - - - 行 - - -network_interfaces="lo0" - - を - - -network_interfaces="lo0 sl0" - - へ変更することにより - ネットワークインタフェースのリストに sl0 - を加えてください. - - - - 行 - - + + /etc/host.conf ファイル中で + が + よりも前にあること を確認してください. + さもないとヘンなことが起こるかもしれません. + + + + /etc/rc.conf + ファイルを編集してください. なお, お使いの FreeBSD が + 2.2.2 よりも前のバージョンのものの場合は, + /etc/sysconfig + を編集してください. + + + + 行 + + +hostname=myname.my.domain + + を編集してホスト名をセットしてください. + 完全なInternetホスト名を与えるべきです. + + + + 行 + + +network_interfaces="lo0" + + を + + +network_interfaces="lo0 sl0" + + へ変更することにより + ネットワークインタフェースのリストに sl0 + を加えてください. + + + + 行 + + ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" - を加えて sl0 - のスタートアップフラグをセットしてください. - - - - 行 - - -defaultrouter=NO - - を - - -defaultrouter=slip-gateway - - へ変更してデフォルトのルータを - 指定してください. - - - - - - 次の - - + を加えて sl0 + のスタートアップフラグをセットしてください. + + + + 行 + + +defaultrouter=NO + + を + + +defaultrouter=slip-gateway + + へ変更してデフォルトのルータを + 指定してください. + + + + + + 次の + + domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 - - という内容を含むファイル - /etc/resolv.conf を作ってください. - 見ればわかるように, - これらはネームサーバホストを設定しています. もちろん, - 実際のドメイン名やアドレスは - あなたの環境に依存します. - - - - root と toor - (及びパスワードを持っていない他のアカウントすべて) - のパスワード を設定してください. - passwdコマンドを使いましょう. - /etc/passwd や - /etc/master.passwd - といったファイルを編集してはいけません! - - - - マシンを再起動して正しいホスト名で - 立ち上がることを確認してください. - - + + という内容を含むファイル + /etc/resolv.conf を作ってください. + 見ればわかるように, + これらはネームサーバホストを設定しています. もちろん, + 実際のドメイン名やアドレスは + あなたの環境に依存します. + + + + root と toor + (及びパスワードを持っていない他のアカウントすべて) + のパスワード を設定してください. + passwdコマンドを使いましょう. + /etc/passwd や + /etc/master.passwd + といったファイルを編集してはいけません! + + + + マシンを再起動して正しいホスト名で + 立ち上がることを確認してください. + + - + - SLIP接続をおこなう - - - - モデムを起動, つながったらプロンプトで - slipとタイプし, マシン名と - パスワードを入力してください. - 入力する必要があるものは環境に よって異なります. - 私は次のようなスクリプトでkermitを使っています. - - + SLIP接続をおこなう + + + + モデムを起動, つながったらプロンプトで + slipとタイプし, マシン名と + パスワードを入力してください. + 入力する必要があるものは環境に よって異なります. + 私は次のようなスクリプトでkermitを使っています. + + # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a - - (もちろん, - ホスト名とパスワードは変える必要があります). - 接続するためには kermit のプロンプトで - slipとタイプするだけです. - - - ファイルシステムのどんなところにもプレインテキスト - にパスワードを書いておくのは一般的にはよくありません. - 覚悟の上で やってください. - 私は単に不精なだけです. - - - - - ここでkermitから抜け出し - (zでkermitをサスペンドできます), root - で - - &prompt.root; slattach -h -c -s 115200 /dev/modem - - と入力しましょう. もしルータの向う側のホストへ - ping できるなら接続成功です! もしうまく - いかなければslattachへの引数として - の代わりにとやってみてください. - - + + (もちろん, + ホスト名とパスワードは変える必要があります). + 接続するためには kermit のプロンプトで + slipとタイプするだけです. + + + ファイルシステムのどんなところにもプレインテキスト + にパスワードを書いておくのは一般的にはよくありません. + 覚悟の上で やってください. + 私は単に不精なだけです. + + + + + ここでkermitから抜け出し + (zでkermitをサスペンドできます), root + で + + &prompt.root; slattach -h -c -s 115200 /dev/modem + + と入力しましょう. もしルータの向う側のホストへ + ping できるなら接続成功です! もしうまく + いかなければslattachへの引数として + の代わりにとやってみてください. + + - + - 接続の切り方 - - slattachを殺すためにrootで - - &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` - - とタイプしてください. そして kermit に戻り - (もしkermitをサスペンドしていたなら - fg), kermitから抜けてください - (q). - - slattachのマニュアルページにはインタフェースを落すために - ifconfig sl0 - downをしなければいけないと書いていますが, - 私には差がないように見えます. (ifconfig - sl0とやっても同じ結果が得られる.) - - 時にはモデムがキャリアを落すのを - 拒絶するかもしれません(私のは よくそうなります). - その時は単にkermitをスタートしてまた終了 してください. - 普通は2回目で落ちます. + 接続の切り方 + + slattachを殺すためにrootで + + &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` + + とタイプしてください. そして kermit に戻り + (もしkermitをサスペンドしていたなら + fg), kermitから抜けてください + (q). + + slattachのマニュアルページにはインタフェースを落すために + ifconfig sl0 + downをしなければいけないと書いていますが, + 私には差がないように見えます. (ifconfig + sl0とやっても同じ結果が得られる.) + + 時にはモデムがキャリアを落すのを + 拒絶するかもしれません(私のは よくそうなります). + その時は単にkermitをスタートしてまた終了 してください. + 普通は2回目で落ちます. - + - トラブルシューティング - - もし動かなければ自由に私に質問してください. - 今までいろんな人がつまずいた のは次のようなことです. - - - - slattach で や - を使わなかった(私はなぜこれが致命的になり得るのか - わかりませんが, このフラグを付けることで少なくとも一人の - 問題は解決しました.) - - - - の代わりに - を使った(いくつかのフォントでは見分けるのは難しい - かもしれません). - - - - インタフェースの状態を見るために ifconfig - sl0 をやってみてください. 私は, - - &prompt.root; ifconfig sl0 + トラブルシューティング + + もし動かなければ自由に私に質問してください. + 今までいろんな人がつまずいた のは次のようなことです. + + + + slattach で や + を使わなかった(私はなぜこれが致命的になり得るのか + わかりませんが, このフラグを付けることで少なくとも一人の + 問題は解決しました.) + + + + の代わりに + を使った(いくつかのフォントでは見分けるのは難しい + かもしれません). + + + + インタフェースの状態を見るために ifconfig + sl0 をやってみてください. 私は, + + &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 - となります. - - - - また, pingが "no route to host" - というメッセージを返す時には netstat - -rでルーティングテーブルを確認しましょう. - 私のは, - + となります. + + + + また, pingが no route to host + というメッセージを返す時には netstat + -rでルーティングテーブルを確認しましょう. + 私のは, + &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) - となります. - (これはたくさんのファイルを転送した後でのもので, - あなたの見る数字はもっと小さいかも - しれません). - - + となります. + (これはたくさんのファイルを転送した後でのもので, + あなたの見る数字はもっと小さいかも + しれません). + + - + - SLIPサーバのセットアップ方法 - 訳: &a.jp.ts;. - 6 September 1996. - - この文書の目的は, SLIPサーバ機能を - FreeBSDシステムのもとで設定するため の助言を提供することです. - SLIPサーバ機能を設定するということは, リモー トの - SLIPクライアントがログインできるようにするために, 自動的に接続処 - 理をおこなうようにすることです. - この文書は著者の経験に基づいておりますが, - 実際のシステム構成や要望は異なりますから, - すべての疑問にこの文書が答え ることはできません. なお, - ここでの助言を試みた結果, あなたのシステムへ - の悪影響やデータの損失が生じたとしても, - 著者が責任を持つことはできませ - んのでご了解をお願いします. - + SLIPサーバのセットアップ方法 + + 訳: &a.jp.ts;. + 1996 年 9 月 6 日. + + この文書の目的は, SLIPサーバ機能を + FreeBSDシステムのもとで設定するため の助言を提供することです. + SLIPサーバ機能を設定するということは, リモー トの + SLIPクライアントがログインできるようにするために, 自動的に接続処 + 理をおこなうようにすることです. + この文書は著者の経験に基づいておりますが, + 実際のシステム構成や要望は異なりますから, + すべての疑問にこの文書が答え ることはできません. なお, + ここでの助言を試みた結果, あなたのシステムへ + の悪影響やデータの損失が生じたとしても, + 著者が責任を持つことはできませ + んのでご了解をお願いします. + - 前提 - - この文書の内容はテクニカルなものなので, - 前提知識が必要です. すなわち, - TCP/IPネットワークプロトコルについての知識, 特に, - ネットワークとノード のアドレス指定をはじめ, - ネットワークアドレスマスク, サブネット化, ルー ティング, - および RIPなどのルーティングプロトコルなどに関する知識を前提 - としています. ダイヤルアップサーバで - SLIP機能を設定するためには, これ - らの概念についての知識が必要ですから, - もし不案内であると思われる方は, O'Reilly & Associates, - Inc.から出版されている Craig Hunt氏の TCP/IP - Network Administration (ISBN 0-937175-82-X)か, - または Douglas Comer氏の - TCP/IPプロトコルに関する一連の書籍をお読みください. - - 前提知識に加え, さらに, モデムの設定が完了しており, - そのモデムを経由し てログインできるように, - システムファイル群が適切に記述できているものと 仮定しています. - もしモデムの準備ができていないときには, あらかじめダイヤ - ルアップ機能の設定についてのチュートリアルをお読みください. - Webブラ ウザが使えるのであれば http://www.FreeBSD.org/ - におけるチュー トリアルの一覧を調べてください. - あるいは, この文書を見つけた場所を調べ て, - dialup.txt - やそれに類似した名前の文書をお読みください. 関連す - るマニュアルページとしては, - シリアルポート向けデバイスドライバについて - の &man.sio.4; をはじめ, モデムからのログインを - 受理できるようにシステ - ムを設定するための &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, - &man.init.8; など, さらには, シリアルポート関連パラメタ ( たと - えば直接接続シリアルインタフェースの - clocal ) についての - &man.stty.1; なども助けになるかもしれません. + 前提 + + この文書の内容はテクニカルなものなので, + 前提知識が必要です. すなわち, + TCP/IPネットワークプロトコルについての知識, 特に, + ネットワークとノード のアドレス指定をはじめ, + ネットワークアドレスマスク, サブネット化, ルー ティング, + および RIPなどのルーティングプロトコルなどに関する知識を前提 + としています. ダイヤルアップサーバで + SLIP機能を設定するためには, これ + らの概念についての知識が必要ですから, + もし不案内であると思われる方は, O'Reilly & Associates, + Inc.から出版されている Craig Hunt氏の TCP/IP + Network Administration (ISBN 0-937175-82-X)か, + または Douglas Comer氏の + TCP/IPプロトコルに関する一連の書籍をお読みください. + + 前提知識に加え, さらに, モデムの設定が完了しており, + そのモデムを経由し てログインできるように, + システムファイル群が適切に記述できているものと 仮定しています. + もしモデムの準備ができていないときには, あらかじめダイヤ + ルアップ機能の設定についてのチュートリアルをお読みください. + Webブラ ウザが使えるのであれば + http://www.FreeBSD.org/ + におけるチュー トリアルの一覧を調べてください. + あるいは, この文書を見つけた場所を調べ て, + dialup.txt + やそれに類似した名前の文書をお読みください. 関連す + るマニュアルページとしては, + シリアルポート向けデバイスドライバについて + の &man.sio.4; をはじめ, モデムからのログインを + 受理できるようにシステ + ムを設定するための &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, + &man.init.8; など, さらには, シリアルポート関連パラメタ ( たと + えば直接接続シリアルインタフェースの + clocal ) についての + &man.stty.1; なども助けになるかもしれません. - + - 概要 - - 一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, - その動作は次 のようになります. まず, SLIPユーザが FreeBSD - による SLIPサーバへ電話し て, SLIP専用IDでログインします. - なお, このIDを持ったユーザはシェルとし て - /usr/sbin/sliplogin を使います. この - sliplogin は, ファ イル - /etc/sliphome/slip.hosts の中から, - ログインIDと一致する 記述行を探します. もし一致する行があれば, - ログインしたシリアル回線を, 利用可能な - SLIPインタフェースへ接続し, その後にシェルスクリプト - /etc/sliphome/slip.login で - SLIPインタフェースを設定します. - + 概要 + + 一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, + その動作は次 のようになります. まず, SLIPユーザが FreeBSD + による SLIPサーバへ電話し て, SLIP専用IDでログインします. + なお, このIDを持ったユーザはシェルとし て + /usr/sbin/sliplogin を使います. この + sliplogin は, ファイル + /etc/sliphome/slip.hosts の中から, + ログインIDと一致する 記述行を探します. もし一致する行があれば, + ログインしたシリアル回線を, 利用可能な + SLIPインタフェースへ接続し, その後にシェルスクリプト + /etc/sliphome/slip.login で + SLIPインタフェースを設定します. + - SLIPサーバへのログイン例 - - 仮に SLIPユーザIDが Shelmerg - とします. すると, /etc/master.passwd - における Shelmerg のエントリは次のよ - うなものになります (実際には一つの行に続いている) . - - + SLIPサーバへのログイン例 + + 仮に SLIPユーザIDが Shelmerg + とします. すると, /etc/master.passwd + における Shelmerg のエントリは次のよ + うなものになります (実際には一つの行に続いている) . + + Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin - Shelmerg がログインすると, - sliplogin は, ファイル - /etc/sliphome/slip.hosts - からユーザIDと一致する行を探しま す. いま仮に, - /etc/sliphome/slip.hosts - に次のような記述がなさ れていたとします. - - + Shelmerg がログインすると, + sliplogin は, ファイル + /etc/sliphome/slip.hosts + からユーザIDと一致する行を探しま す. いま仮に, + /etc/sliphome/slip.hosts + に次のような記述がなされていたとします. + + Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - sliplogin - が上記のエントリを見つけると, Shelmerg が使用して - いるシリアル回線を, 利用可能な - SLIPインタフェースのなかの最初のものへ 接続し, 次の内容の - /etc/sliphome/slip.login - を実行します. - - + sliplogin + が上記のエントリを見つけると, + Shelmerg が使用して + いるシリアル回線を, 利用可能な + SLIPインタフェースのなかの最初のものへ 接続し, 次の内容の + /etc/sliphome/slip.login + を実行します. + + /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - もし上記の手順が正常に処理されると, - /etc/sliphome/slip.login は, - sliplogin が割り当てた SLIPインタフェース - (この例では slip.login - で与えられたパラメタのうちで最初の値である SLIP - インタフェース0である) に対して ifconfig - を実行し, ローカル IPアドレス - (dc-slip)をはじめ, リモート IPアドレス - (sl-helmer), - SLIPインタフェースへのネットワークマスク (0xfffffc00), およびその他のフラグ - (autocomp)を設定 します. 逆に, - さきほどの手順が正常に終了しなかった場合, 通常は - sliplogin は十分な情報を syslog の - daemon 機能経由で - /var/log/messages へ記録します - ( &man.syslogd.8; や - &man.syslog.conf.5; のマニュアルページを参照のうえ, さらに - /etc/syslog.conf を調べて - syslogd がどのファイルへ記 - 録するかを確認のこと) . - - 例はこのくらいにして, - さっそくシステムのセットアップを始めてみましょう. + もし上記の手順が正常に処理されると, + /etc/sliphome/slip.login は, + sliplogin が割り当てた SLIPインタフェース + (この例では slip.login + で与えられたパラメタのうちで最初の値である SLIP + インタフェース0である) に対して ifconfig + を実行し, ローカル IPアドレス + (dc-slip)をはじめ, リモート IPアドレス + (sl-helmer), + SLIPインタフェースへのネットワークマスク + (0xfffffc00), およびその他のフラグ + (autocomp)を設定 します. 逆に, + さきほどの手順が正常に終了しなかった場合, 通常は + sliplogin は十分な情報を syslog の + daemon 機能経由で + /var/log/messages へ記録します + ( &man.syslogd.8; や + &man.syslog.conf.5; のマニュアルページを参照のうえ, さらに + /etc/syslog.conf を調べて + syslogd がどのファイルへ記 + 録するかを確認のこと) . + + 例はこのくらいにして, + さっそくシステムのセットアップを始めてみましょう. - + - カーネルのコンフィグレーション - - FreeBSD のデフォルトのカーネルには, 通常, 二つの - SLIPインタフェースが 準備されています - (sl0 と sl1) - . これらのインタフェー - スが使用中のカーネルに準備されているかどうかを調べるには, - netstat -i を実行してください. - - netstat -i の出力例 - - Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll + カーネルのコンフィグレーション + + FreeBSD のデフォルトのカーネルには, 通常, 二つの + SLIPインタフェースが 準備されています + (sl0 と sl1) + . これらのインタフェー + スが使用中のカーネルに準備されているかどうかを調べるには, + netstat -i を実行してください. + + netstat -i の出力例 + + Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 - netstat -i の出力に - sl0 と sl1 - のインタフェー スが含まれているということから, - カーネルには二つの SLIPインタフェー - スが組み込まれているということを示しています. - (sl0 と sl1 - に付いたアスタリスクは, netstat -i - の実行時点で はインタフェースが “ダウン” - していることを表しています. ) - - なお, パケットのフォワード機能は FreeBSD - のデフォルトのカーネルでは設定 されていません - (すなわちルータとしては動作しない) . もしインターネット - 接続ホストについての RFC要件 ( RFC 1009 [Requirements for - Internet Gateways] と 1122 [Requirements for Internet Hosts - — Communication Layers], おそらく 1127 [A Perspective on - the Host Requirements RFCs] も ) に準拠して, FreeBSDによる - SLIPサー バをルータとして動作させたいときには, - /etc/rc.conf (バージョ ン 2.2.2 より前の - FreeBSD では /etc/sysconfig) ファイル の - gateway 変数を - としてください. もし古いシステ ムで - /etc/sysconfig ファイルすらないときには, - 次のコマン ドを /etc/rc.local - へ追加してください. - - + netstat -i の出力に + sl0 と sl1 + のインタフェー スが含まれているということから, + カーネルには二つの SLIPインタフェー + スが組み込まれているということを示しています. + (sl0 と sl1 + に付いたアスタリスクは, netstat -i + の実行時点で はインタフェースが ダウン + していることを表しています. ) + + なお, パケットのフォワード機能は FreeBSD + のデフォルトのカーネルでは設定 されていません + (すなわちルータとしては動作しない) . もしインターネット + 接続ホストについての RFC要件 ( RFC 1009 [Requirements for + Internet Gateways] と 1122 [Requirements for Internet Hosts + — Communication Layers], おそらく 1127 [A Perspective on + the Host Requirements RFCs] も ) に準拠して, FreeBSDによる + SLIPサー バをルータとして動作させたいときには, + /etc/rc.conf (バージョ ン 2.2.2 より前の + FreeBSD では /etc/sysconfig) ファイル の + gateway_enable 変数を + としてください. もし古いシステ ムで + /etc/sysconfig ファイルすらないときには, + 次のコマン ドを /etc/rc.local + へ追加してください. + + sysctl -w net.inet.ip.forwarding = 1 - この新しい設定を有効とするには, - リブートする必要があります. - - デフォルトのカーネルコンフィグレーションファイル - (/sys/i386/conf/GENERIC) の最後の部分に, - 次のような行がありま す. - - + この新しい設定を有効とするには, + リブートする必要があります. + + デフォルトのカーネルコンフィグレーションファイル + (/sys/i386/conf/GENERIC) の最後の部分に, + 次のような行がありま す. + + pseudo-device sl 2 - この行によって, 使用可能な SLIPデバイスの総数が決まります. - すなわち, 行 末の数値が, 同時に動作可能な - SLIP接続の最大数となります. - - カーネルの再構築については, FreeBSDカー - ネルのコンフィグレーション を参照ください. + この行によって, 使用可能な SLIPデバイスの総数が決まります. + すなわち, 行 末の数値が, 同時に動作可能な + SLIP接続の最大数となります. + + カーネルの再構築については, + FreeBSDカー + ネルのコンフィグレーション を参照ください. - + - Sliploginのコンフィグレーション - - すでにご説明したように, - /usr/sbin/sliplogin のコンフィグレー - ションのために, - 3種類のファイルが/etc/sliphome - ディレクトリに あります (sliplogin - についての実際のマニュアルページとしては - &man.sliplogin.8; を参照のこと) . - ファイル slip.hosts は - SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル - slip.login は, - SLIPインタフェースを設定することだけに使 - 用します. slip.logout - はオプションのファイルで, - slip.login で設定した内容を, - シリアル接続が終了した時点で解除 - するときに使用します. - - - <filename>slip.hosts</filename> + <title>Sliploginのコンフィグレーション + + すでにご説明したように, + /usr/sbin/sliplogin のコンフィグレー + ションのために, + 3種類のファイルが/etc/sliphome + ディレクトリに あります (sliplogin + についての実際のマニュアルページとしては + &man.sliplogin.8; を参照のこと) . + ファイル slip.hosts は + SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル + slip.login は, + SLIPインタフェースを設定することだけに使 + 用します. slip.logout + はオプションのファイルで, + slip.login で設定した内容を, + シリアル接続が終了した時点で解除 + するときに使用します. + + + <filename>slip.hosts</filename> のコンフィグレーション - - /etc/sliphome/slip.hosts には, - 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) - で区切って指定します. - - - - SLIPユーザのログインID - - - - SLIPリンクのローカル (SLIPサーバ側) アドレス - - - - SLIPリンクのリモートアドレス - - - - ネットワークマスク - - - - ホスト名をローカルおよびリモートのアドレスとして - 記述できます (IPアドレ スの決定は, - /etc/host.conf の指定内容に応じて, - /etc/hosts か - DNSのいずれかによって決定される) . また, ネット - ワークマスクも /etc/networks - ファイルに記述された名前を参照す ることで, - 指定することもできると思います. これまでの例としてあげたシス - テムでの /etc/sliphome/slip.hosts - は次のようになります. - - + + /etc/sliphome/slip.hosts には, + 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) + で区切って指定します. + + + + SLIPユーザのログインID + + + + SLIPリンクのローカル (SLIPサーバ側) アドレス + + + + SLIPリンクのリモートアドレス + + + + ネットワークマスク + + + + ホスト名をローカルおよびリモートのアドレスとして + 記述できます (IPアドレ スの決定は, + /etc/host.conf の指定内容に応じて, + /etc/hosts か + DNSのいずれかによって決定される) . また, ネット + ワークマスクも /etc/networks + ファイルに記述された名前を参照す ることで, + 指定することもできると思います. これまでの例としてあげたシス + テムでの /etc/sliphome/slip.hosts + は次のようになります. + + # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp - それぞれの行の最後には, - 次に示すオプションを一つ以上指定できます. - - - - — ヘッダを圧縮しない - - - - — ヘッダを圧縮する - - - - — - リモートの設定に応じて, ヘッダを圧縮する - - - - — - ICMPパケットを禁止する - (“ping”パケットは送出されず, - バンド幅を占有しない) - - - - なお, FreeBSDバージョン2の初期リリースの - sliplogin は, 旧 FreeBSD - 1.xでは有効であった上記のオプションを無視していましたので, - , , - , そして - などのオ プションは FreeBSD - 2.2でサポートされるまでは効果がありませんでした (た - だしこれらのフラグを使うためには - slip.login スクリプトへ記述する - 必要がある) . - - SLIPリンクでのローカルとリモート向けのアドレスの - 選び方は, TCP/IPサブネッ トを専用に割り当てるか, - または“プロキシ ARP”を - SLIPサーバへ用いるかによっ て違います (プロキシ - ARPという用語のここでの使い方は本来のものではない が, - 説明のためにこの用語を使う) . もし, - どちらの方式を選ぶべきか判らな かったり, - IPアドレスの割り当て方が不明のときには, 上述の 前提 の節で紹介した - TCP/IP関連書籍を参考になさるか, またはあなたの - IPネットワークを管理している方に相談なさると - よいでしょう. - - 独立したサブネットを SLIPクライアントへ適用するときには, - すでに割り当 てられている - IPネットワーク番号の範囲からサブネット番号を割り当て, 同 - 時にそのサブネットの範囲内で有効な IPアドレスを - SLIPクライアントの IP 番号として割り当てる必要があります. - さらに, この SLIPサブネットから SLIPサーバを経由して最も近い - IPルータへの経路を静的に設定するか, また は - gated を FreeBSDによる - SLIPサーバへインストールして, 適当 - なルーティングプロトコルを使って, - SLIPサーバ経由のサブネットへの経路情 - 報をルータ群へ通知できるように設定するか, - のいずれかをおこなう必要がありま す. - - “プロキシ ARP” 方式を採用するときには, - SLIPクライアント向けの IPアドレス - として, SLIPサーバのサブネットの範囲から - 選んで割り当てるとともに, - &man.arp.8; コマンドを使うために - /etc/sliphome/slip.login - と/etc/sliphome/slip.logout - のスクリプトを修正して, SLIPサー - バにおける ARPテーブル内のプロキシ ARPエントリへ - 反映させる必要がありま - す. + それぞれの行の最後には, + 次に示すオプションを一つ以上指定できます. + + + + — ヘッダを圧縮しない + + + + — ヘッダを圧縮する + + + + — + リモートの設定に応じて, ヘッダを圧縮する + + + + — + ICMPパケットを禁止する + ( ping パケットは送出されず, + バンド幅を占有しない) + + + + なお, FreeBSDバージョン2の初期リリースの + sliplogin は, 旧 FreeBSD + 1.xでは有効であった上記のオプションを無視していましたので, + , , + , そして + などのオプションは FreeBSD + 2.2でサポートされるまでは効果がありませんでした (た + だしこれらのフラグを使うためには + slip.login スクリプトへ記述する + 必要がある) . + + SLIPリンクでのローカルとリモート向けのアドレスの + 選び方は, TCP/IPサブネッ トを専用に割り当てるか, + または プロキシ ARP を + SLIPサーバへ用いるかによって違います ( プロキシ + ARP という用語のここでの使い方は本来のものではないが, + 説明のためにこの用語を使う) . もし, + どちらの方式を選ぶべきか判らなかったり, + IPアドレスの割り当て方が不明のときには, 上述の + 前提 の節で紹介した + TCP/IP関連書籍を参考になさるか, またはあなたの + IPネットワークを管理している方に相談なさると + よいでしょう. + + 独立したサブネットを SLIPクライアントへ適用するときには, + すでに割り当てられている + IPネットワーク番号の範囲からサブネット番号を割り当て, 同 + 時にそのサブネットの範囲内で有効な IPアドレスを + SLIPクライアントの IP 番号として割り当てる必要があります. + さらに, この SLIPサブネットから SLIPサーバを経由して最も近い + IPルータへの経路を静的に設定するか, または + gated を FreeBSDによる + SLIPサーバへインストールして, 適当 + なルーティングプロトコルを使って, + SLIPサーバ経由のサブネットへの経路情 + 報をルータ群へ通知できるように設定するか, + のいずれかをおこなう必要があります. + + プロキシ ARP 方式を採用するときには, + SLIPクライアント向けの IPアドレス + として, SLIPサーバのサブネットの範囲から + 選んで割り当てるとともに, + &man.arp.8; コマンドを使うために + /etc/sliphome/slip.login + と/etc/sliphome/slip.logout + のスクリプトを修正して, SLIPサー + バにおける ARPテーブル内のプロキシ ARPエントリへ + 反映させる必要がありま + す. - + - <filename>slip.login</filename> - のコンフィグレーション - - ファイル /etc/sliphome/slip.login - の一般的な内容は次にように なります. + <filename>slip.login</filename> + のコンフィグレーション + + ファイル /etc/sliphome/slip.login + の一般的な内容は次にようになります. - + #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 - この slip.login - ファイルの役目は単に, SLIPインタフェースにつ - いてのローカルとリモートのアドレス, - およびそのネットワークマスクを ifconfig - コマンドで設定することです. - - もし“プロキシ ARP”方式を採用する - (SLIPクライアントへ独立したサブネットを 使わない) ときには, - ファイル /etc/sliphome/slip.login - は次の ような内容になります. - - + この slip.login + ファイルの役目は単に, SLIPインタフェースにつ + いてのローカルとリモートのアドレス, + およびそのネットワークマスクを ifconfig + コマンドで設定することです. + + もし プロキシ ARP 方式を採用する + (SLIPクライアントへ独立したサブネットを使わない) ときには, + ファイル /etc/sliphome/slip.login + は次のような内容になります. + + #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub - この slip.login で追加された行 - arp -s $5 00:11:22:33:44:55 pub は, - SLIPサーバにおける ARPテーブルへ新たなエントリを作ります. - SLIPサーバ は, この ARPエントリが作られると, - SLIPクライアントの IPアドレスと話し たい他の - IPノードが要求してきたときにはいつも, SLIPサーバ の Ethernet - MACアドレスを返すようになります. - - 上記の例を実際に流用なさるときには, 例にある Ethernet - MACアドレス (00:11:22:33:44:55) - を, あなたのシステムの実際のEthernetカー ドの - MACアドレスと置き換えなければ“プロキシ - ARP”はうまく動作しません! SLIPサーバの Ethernet - MACアドレスを調べるには netstat -i コマ - ンドを利用してください. - 実行結果の第2行は次のようなものになるはずです. - - ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 - - この例での Ethernet MACアドレスは - 00:02:c1:28:5f:4a であると - 読みます. なお &man.arp.8; における MAC - アドレスの指定に際しては, - コマンド netstat -i が付けた - Ethernet MACアドレスのピリオド記 - 号をコロン記号と置き換え, かつ単一桁の 16 - 進数にはゼロを先頭に加える必 - 要があります. この指定についての正確な情報は &man.arp.8; - を参照く - ださい. - - - /etc/sliphome/slip.login と - /etc/sliphome/slip.logout - を作成したならば, ファイル属性の“実行”ビット - (すなわち chmod 755 /etc/sliphome/slip.login - /etc/sliphome/slip.logout) を - 設定しなければなりません. さもなければ - sliplogin が - うまく実行されません. - + この slip.login で追加された行 + arp -s $5 00:11:22:33:44:55 pub は, + SLIPサーバにおける ARPテーブルへ新たなエントリを作ります. + SLIPサーバ は, この ARPエントリが作られると, + SLIPクライアントの IPアドレスと話し たい他の + IPノードが要求してきたときにはいつも, SLIPサーバ の Ethernet + MACアドレスを返すようになります. + + 上記の例を実際に流用なさるときには, 例にある Ethernet + MACアドレス (00:11:22:33:44:55) + を, あなたのシステムの実際のEthernetカー ドの + MACアドレスと置き換えなければ プロキシ + ARP はうまく動作しません! SLIPサーバの Ethernet + MACアドレスを調べるには netstat -i コマ + ンドを利用してください. + 実行結果の第2行は次のようなものになるはずです. + + ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 + + この例での Ethernet MACアドレスは + 00:02:c1:28:5f:4a であると + 読みます. なお &man.arp.8; における MAC + アドレスの指定に際しては, + コマンド netstat -i が付けた + Ethernet MACアドレスのピリオド記 + 号をコロン記号と置き換え, かつ単一桁の 16 + 進数にはゼロを先頭に加える必 + 要があります. この指定についての正確な情報は &man.arp.8; + を参照く + ださい. + + + /etc/sliphome/slip.login と + /etc/sliphome/slip.logout + を作成したならば, ファイル属性の 実行 ビット + (すなわち chmod 755 /etc/sliphome/slip.login + /etc/sliphome/slip.logout) を + 設定しなければなりません. さもなければ + sliplogin が + うまく実行されません. + - + - <filename>slip.logout</filename> - のコンフィグレーション - - ファイル /etc/sliphome/slip.logout - は必ずしも必要なものではあ りません (ただし“プロキシ - ARP”を利用する場合を除く) . もしこのファイルを - 作成するときには, 次に示す標準的な - slip.logout スクリプト例を - 参考にしてください. - - + <filename>slip.logout</filename> + のコンフィグレーション + + ファイル /etc/sliphome/slip.logout + は必ずしも必要なものではあ りません (ただし プロキシ + ARP を利用する場合を除く) . もしこのファイルを + 作成するときには, 次に示す標準的な + slip.logout スクリプト例を + 参考にしてください. + + #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down - “プロキシ ARP”を利用する場合, この - /etc/sliphome/slip.logout を 使って, - 特定の SLIPクライアント向けの - ARPエントリを削除したくなるよう なときがあります. + プロキシ ARP を利用する場合, この + /etc/sliphome/slip.logout を 使って, + 特定の SLIPクライアント向けの + ARPエントリを削除したくなるようなときがあります. - + #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 - - コマンド arp -d $5 は, - SLIPクライアントがログインした 際に, “プロキシ - ARP”を使った slip.login - によって追加され た ARPエントリを削除します. - - これによって, 繰り返して利用することができるわけです. - 必ず, /etc/sliphome/slip.logout - を作成した後に, 実行ビットを設定し てください ( - chmod 755 /etc/sliphome/slip.logout ) - . + + コマンド arp -d $5 は, + SLIPクライアントがログインした 際に, プロキシ + ARP を使った slip.login + によって追加され た ARPエントリを削除します. + + これによって, 繰り返して利用することができるわけです. + 必ず, /etc/sliphome/slip.logout + を作成した後に, 実行ビットを設定し てください ( + chmod 755 /etc/sliphome/slip.logout ) + . - ルーティングについての考慮点 - - “プロキシ ARP”方式を利用せずに - SLIPクライアントとその他のネットワーク (Internetも含む) - の構成要素との間でパケットをルーティングするときには, - SLIPサーバ経由で - SLIPクライアントが属するサブネットまでの経路を, 最も - 近いデフォルトのルータ群へ静的な経路情報として - 追加しなければならないか, または gated を - FreeBSDによる SLIPサーバへインストールして, SLIP - サブネットについての経路情報を, - 適当なルーティングプロトコルでルー - タ群へ通知できるように設定するか, - のどちらかをおこなわなければなりません. - + ルーティングについての考慮点 + + プロキシ ARP 方式を利用せずに + SLIPクライアントとその他のネットワーク (Internetも含む) + の構成要素との間でパケットをルーティングするときには, + SLIPサーバ経由で + SLIPクライアントが属するサブネットまでの経路を, 最も + 近いデフォルトのルータ群へ静的な経路情報として + 追加しなければならないか, または gated を + FreeBSDによる SLIPサーバへインストールして, SLIP + サブネットについての経路情報を, + 適当なルーティングプロトコルでルー + タ群へ通知できるように設定するか, + のどちらかをおこなわなければなりません. + - 静的な経路 - - 静的な経路を最も近いデフォルトの - ルータ群へ追加することが困難なことがあ ります - (経路情報を追加できる権限がなければそもそも不可能となる). - もし あなたの組織に複数のルータで構成された - ネットワークがあるならば, ある種 のルータ (たとえば Ciscoや - Proteonなど) は, 静的な経路を SLIPサブネッ - トへ使うようにルータを設定しなければならないだけでなく, - その静的経路を 他のどのルータへ知らせるのかもあらかじめ - 指定しておく必要がありますから, - 静的経路に基づくルーティングを軌道に乗せるには - それなりの専門的技術やト - ラブルシューティングやコツが必要だと思います. + 静的な経路 + + 静的な経路を最も近いデフォルトの + ルータ群へ追加することが困難なことがあ ります + (経路情報を追加できる権限がなければそもそも不可能となる). + もし あなたの組織に複数のルータで構成された + ネットワークがあるならば, ある種 のルータ (たとえば Ciscoや + Proteonなど) は, 静的な経路を SLIPサブネッ + トへ使うようにルータを設定しなければならないだけでなく, + その静的経路を 他のどのルータへ知らせるのかもあらかじめ + 指定しておく必要がありますから, + 静的経路に基づくルーティングを軌道に乗せるには + それなりの専門的技術やト + ラブルシューティングやコツが必要だと思います. - + - <command>gated</command>の稼働 - - 静的経路についての頭痛への代替手段は, - gated を FreeBSDによる SLIPサー - バへインストールして, 適切なルーティングプロトコル - (RIP/OSPF/BGP/EGP) を使って - SLIPサブネットについての経路情報を他のルータへ知らせるように - 設定することです. ports - コレクションから gated - を用いることもできますし, - the GateD 匿名 FTP サイト - から探して自分自身で構築することもで きます. - この文章を執筆時点の最新バージョンは - gated-R3_5Alpha_8.tar.Z であり, - このファイルだけで FreeBSDで 動作させることができます. - gated についてのすべての情報と文書 は - - Merit GateD コンソーシアム からはじまる Web - 上で入手でき ます. gated - のコンパイルとインストールを行ったならば, - 独自の 設定のために /etc/gated.conf - ファイルを記述してください. 次の 例は, - 筆者が FreeBSDによる SLIP - サーバで使っている内容と類似のものです. - - + <command>gated</command>の稼働 + + 静的経路についての頭痛への代替手段は, + gated を FreeBSDによる SLIPサー + バへインストールして, 適切なルーティングプロトコル + (RIP/OSPF/BGP/EGP) を使って + SLIPサブネットについての経路情報を他のルータへ知らせるように + 設定することです. ports + コレクションから gated + を用いることもできますし, + + the GateD 匿名 FTP サイト + から探して自分自身で構築することもで きます. + この文章を執筆時点の最新バージョンは + gated-R3_5Alpha_8.tar.Z であり, + このファイル だけで FreeBSDで 動作させることができます. + gated についてのすべての情報と文書 は + + Merit GateD コンソーシアム からはじまる Web + 上で入手でき ます. gated + のコンパイルとインストールを行ったならば, + 独自の 設定のために /etc/gated.conf + ファイルを記述してください. 次の 例は, + 筆者が FreeBSDによる SLIP + サーバで使っている内容と類似のものです. + + # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; - この gated.conf ファイルの例では, - SLIPのサブネット xxx.xxx.yy - についての経路情報を RIPを使って Ethernetへブロー - ドキャストしています. もし ed - ドライバ以外の Ethernetドライバを使 うのであれば, - ed - インタフェースの記述を適切なものに置き換えてくだ さい. - またこの例では, - gatedの動作をデバッグするために, - /var/tmp/gated.output - へトレース情報を出力するように指示して います. - gated が希望通りに動作したならば, - このトレースオプショ ンを止めることができます. なお, - 例における xxx.xxx.yy を, あ - なた自身の - SLIPサブネットのネットワークアドレスに換えてください (また - proto direct - 部分のネットワークマスクも換えることを忘れないこ と) - . - - gated - のコンパイルとインストールが終了し, コンフィグレーショ - ンファイルの作成も完了したら, - FreeBSDシステムではデフォルトの - routedに代わって gated - を起動してください. そのため には, - /etc/netstart の - routed/gated 起動パラメタを - 適切な値に設定してください. gated - のコマンドラインパラメタにつ いての情報は, - gated - のマニュアルページを参照してください. + この gated.conf ファイルの例では, + SLIPのサブネット xxx.xxx.yy + についての経路情報を RIPを使って Ethernetへブロー + ドキャストしています. もし ed + ドライバ以外の Ethernetドライバを使うのであれば, + ed + インタフェースの記述を適切なものに置き換えてくだ さい. + またこの例では, + gatedの動作をデバッグするために, + /var/tmp/gated.output + へトレース情報を出力するように指示して います. + gated が希望通りに動作したならば, + このトレースオプショ ンを止めることができます. なお, + 例における xxx.xxx.yy を, あ + なた自身の + SLIPサブネットのネットワークアドレスに換えてください (また + proto direct + 部分のネットワークマスクも換えることを忘れないこ と) + . + + gated + のコンパイルとインストールが終了し, コンフィグレーショ + ンファイルの作成も完了したら, + FreeBSDシステムではデフォルトの + routedに代わって gated + を起動してください. そのため には, + /etc/netstart の + routed/gated 起動パラメタを + 適切な値に設定してください. gated + のコマンドラインパラメタにつ いての情報は, + gated + のマニュアルページを参照してください. diff --git a/ja_JP.eucJP/books/handbook/security/chapter.sgml b/ja_JP.eucJP/books/handbook/security/chapter.sgml index 995c01df53..094b1703fa 100644 --- a/ja_JP.eucJP/books/handbook/security/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/security/chapter.sgml @@ -1,2013 +1,2991 @@ セキュリティ + この章の多くの部分は&a.dillon;によって書かれた + &man.security.7; マニュアルページからの引用です. + + 訳: &a.jp.hino;, (jpman プロジェクトの成果を利用させ + ていただきましたした). + + + この章では + + この章では, 基本的なシステムセキュリティの考え方, + 覚えておくべき一般的なルールを紹介し, + そして S/Key, OpenSSL, Kerberos + などの高度な話題について簡単に説明します. + + + + はじめに + + セキュリティとは, システム管理者をいつも悩ませる仕事の一つです. + すべての BSD UNIX マルチユーザシステムは, + 従来からいくつかのセキュリティ機構を備えていますが, + ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し + 保守する仕事はおそらく, システム管理者としてもっとも大きな責務の一つでしょう. + マシンの安全性に反映されるのは, 管理者が作業したことだけです. + またセキュリティ問題は, 快適な環境に必要なものと競合します. + 一般に UNIX システムは膨大な数のプロセスを同時に動作させることができ, + そのプロセスの大部分は, サーバ – + 外部から接続し, 通信するものとして動作します. + かつてのミニコンとメインフレームがデスクトップにとってかわり, + さらにコンピュータが相互に接続されたネットワークを形成するようになった今日, + セキュリティは非常に大きな関心事になってきています. + + セキュリティを実装するには, + タマネギのように階層化する手法 + (a layered onion approach) + が最適です. + どうすれば良いのか簡単に説明すると, + 便利な機能と同じ数だけセキュリティの階層を作り, + システムへの侵入を注意深く監視するのです. + あなたはセキュリティを過度に厳重にしたり, + 侵入の監視に時間をとられたいとは思わないでしょう. + この侵入の発見という部分は, + あらゆるセキュリティ機構において最も重要な部分の一つなのです. + たとえば, システムの各バイナリに schg フラグ + を設定するのは, 大して意味がありません. + フラグを設定すると一時的にバイナリが保護され, + 侵入してきたクラッカーによってシステムに加えられる変更のうち, + 容易に検出可能な変更は行なえなくなります. + しかしその結果として, セキュリティ機構がその侵入者を検出することも + まったくできなくなってしまうでしょう. + + また, システムセキュリティには, + さまざまな形での攻撃に対処することとも関係しています. + この攻撃には root 権限を奪おうとするものだけでなく, + クラッシュやシステムの不安定状態を引き起こそうとするものを含まれます. + このセキュリティ問題は, いくつかに分類することが可能です. + + + + サービス妨害攻撃 (denial of service attack) + + + + ユーザアカウントの不正利用 (user account compromise) + + + + アクセス可能なサーバを使った root 権限の不正利用 + + + + ユーザアカウントを経由した root 権限の不正使用 + + + + バックドアの設置 + + + + サービス妨害攻撃 (DoS 攻撃) とは, + マシンから必要な資源を奪う行為です. + 通常, サービス妨害攻撃はそのマシンで実行されるサーバや + ネットワークスタックを過負荷状態にしてマシンをクラッシュさせたり, + マシンを使えなくしたりするような力任せの方法です. + サービス妨害攻撃の中には, + ネットワークスタックのバグを利用して, + パケット一つでマシンをクラッシュさせようとするものもあります. + 後者には, カーネルにバグ修正を施すことによってのみ対応することができます. + サーバプロセスに対する攻撃は, オプションを適切に指定することによって, + 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで + 対応できる場合が多いです. これらに比べると, + ネットワークへの力任せの攻撃への対応はずっと難しくなります. + たとえば, 偽造パケットによる攻撃 (spoof-packet attack) は, + インターネットからシステムを切り離す以外の方法で + 防ぐことはほとんど不可能です. + この攻撃によって, マシンを落としてしまうことはできないかもしれませんが, + 接続しているインターネット回線を混雑させていっぱいにしてしまうことはできます. + + ユーザアカウントの不正利用は, サービス妨害攻撃 + よりもずっとよくある問題です. このご時勢でも, 自分たちのマシンで + 標準の telnetd, rlogind, rshd, ftpd サーバを実行させているシステ + ム管理者は多いのです. これらのサーバは, デフォルトでは, 暗号化さ + れたコネクション上で動作していません. その結果, 抱えているユーザ + 数が標準くらいであれば, リモートログイン (そのシステムにログイン + するには最も普通で便利な方法です) しているユーザのうち一人以上は, + パスワードを覗き見られてしまうでしょう. システム管理者が注意深い + 人ならば, たとえログインが成功していたとしても, リモートアクセス + ログを解析して, 疑わしい送信元アドレスを探すものです. + + ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると, + 攻撃者が root の権限を破る可能性があることを仮定するべきです. し + かし, セキュリティを十分維持し, 手入れの行き届いたシステムにおい + ては, あるユーザアカウントへのアクセスが可能となっても, 攻撃者に + 必ずしも root へのアクセス権を与えるとは限りません. こ + の違いは重要です. というのは, 一般的に root へのアクセス権がなければ, + 攻撃者は自分の侵入の痕跡を隠蔽することができませんし, そ + のユーザのファイルを引っかき回したり, マシンをクラッシュさせたり + できるのがせいぜいです. ユーザアカウントの不正利用は + めずらしいことではありません. それは一般ユーザに, システム管 + 理者ほど注意を払わない傾向があるからです. + + + システム管理者は「あるマシン上で root の権限を破る方法は, 潜 + 在的に何通りもあるのだ」ということを心しておかねばなりません. 攻撃 + 者が root のパスワードを知ってしまうかもしれませんし, 攻撃者が + root の権限で実行されるサーバのバグを見つけ, ネットワークからそ + のサーバへ接続して root の権限を破ることができるかもしれません. + ひとたびユーザアカウントを破ると, ユーザアカウントから root の権 + 限を破ることを可能にするような suid-root プログラムに存在するバグを + 攻撃者は知っているかもしれません. あるマシン上で攻撃者 + が root の権限を破る方法を知ったとすると, 攻撃者は, 裏口を作る必 + 要はありません. これまでに発見され, ふさがれた root の + 穴の多くには, クラッカーが侵入した跡を消そうとしてたくさん仕事し + た結果が含まれています. そのためにこそ, 多くのクラッカーは裏口を + 作るのです. 攻撃者は裏口を使ってシステムへの root アクセスを再び + 簡単に得ることができます. しかしこの裏口は, クラッカーの検出をす + るのに便利なものでもあります. クラッカーに裏口を作らせないように + するということは, セキュリティにとっては実際には良くないことかも + しれません. なぜなら, そうすることで, クラッカーが最初に侵入して + くるために発見したセキュリティホールがふさがるわけではないからで + す. + + セキュリティを改善する方法は, 常に, タマネギの皮 + のように階層化する手法 (a multi-layered onion peel approach) で実装されるべきです. これら + は次のように分類できます. + + + + root とスタッフのアカウントの安全性を高める. + + + + root の安全性を高める – root 権限で動作するサーバ + と suid/sgid バイナリ. + + + + ユーザアカウントの安全性を高める. + + + + パスワードファイルの安全性を高める. + + + + カーネルのコア, raw デバイス, ファイルシステムの安全性を + 高める. + + + + システムに対して行なわれた, 不適切な変更をすばやく検出す + る. + + + + 必要と思われる以上の対応をとる (paranoia). + + + + 本章の次の節では, 上記の各項目についてより深く掘り下げていき + ます. + + + + FreeBSDの安全性を高める + + 以下の節では, 本章の前節 + でとりあげた FreeBSD システムの安全性を高める方法について + 述べます. + + + root アカウントとスタッフアカウントの安全性を高める + + root のアカウントの安全性を確保しないうちからスタッフのア + カウントの安全性をうんぬんしてもしかたがありません. ほとんどの + システムでは, root アカウントに割り当てたパスワードが 1 つあり + ます. まず最初にすべきことは, このパスワードはいつで + も不正利用の危険に晒されていると仮定することです. これは + root のパスワードを消すべきだと言っているのではありません. + root のパスワードは, マシンにコンソールからアクセスするのには, + ほとんどいつでも必要なものです. ここで言いたいのは, コンソール + 以外からは, そして可能なら &man.su.1; コマンドを実行する場合も + root のパスワードを使えないようにするべきである, ということで + す. たとえば, あなたが使っている pty が, + /etc/ttys ファイルで unsecure と指定 + されているか確認してください. そうすると, + telnet や rlogin 経由では + root で直接ログインできないようになります. + sshd のような, 別のログインサービス + を使っている場合でも同様に, 直接 root へログインすることを許し + ていないかどうか確認してください. すべてのアクセス手段 – + たとえば ftp のようなサービスが, 良くクラックの対象となることを + 考えましょう. root への直接ログインは, シス + テムコンソール経由でのみ可能であるべきなのです. + + また当然, システム管理者として自分が root になれるようにしておく必要が + ありますから, そのための穴をいくつか開けておきます. し + かし, それらの穴を動作させるには, さらに追加のパスワード認証が + 必要であるようにしておくことが重要です. root でアクセス可能と + する方法の一つとして, 適切なスタッフアカウントを + (/etc/group 中の) + wheel グループに加えることがありま + す. wheel グループに入っているスタッフメン + バは su を使って root になることが許されま + す. パスワードエントリにおいて, スタッフメンバを + wheel グループに置くことによって直接 wheel + 権限を与えてはいけません. スタッフメンバのアカウントは + staff グループに所属させるべきで, そして + /etc/group ファイルを通して + wheel グループに加えるべきです. 実際に root + アクセスの必要なスタッフメンバのみ wheel グ + ループに置くようにすべきです. 他の認証方法の場合, たとえば + kerberos を使用する場合には, root アカウントの + .k5login ファイルを使って, 誰も + wheel グループに置く必要なく &man.ksu.1; を + 使って root になることを許すようにすることもできます. このやり + 方はよりよい解決策なのかもしれません. なぜなら, + wheel のメカニズムでは, 侵入者がパスワード + ファイルを手に入れ, スタッフアカウントのいずれか 1 つを破るこ + とができると, root を破ることがまだできてしまうからです. + wheel のメカニズムを用いる方が, 何もしない + よりは良いのですが, 必ずしも最も安全な選択肢とは限りません. + + + root アカウントの安全性を高める間接的な方法として, 別のロ + グインアクセスの方法を用いてスタッフのアカウントの安全性を高め, + その上でそのスタッフのアカウントの暗号化パスワードを + * にしておく方法があります. この方法だと, + 侵入者がパスワードファイルを盗むことができた場合でも, スタッフ + アカウントを破ることはできなくなります (また, たとえ root が暗 + 号化パスワードをパスワードファイルに付けていたとしても, 間接的 + に root アカウントを破ることはできません). スタッフメン + バがスタッフアカウントでログインする際には, &man.kerberos.1; + や &man.ssh.1; のような, 公開鍵 / 秘密鍵の鍵の組を使う安全性の + 高いログイン機構を使います. kerberos のようなログイン機構を使う + 場合は一般に, kerberos サーバを実行するマシンと自分のデスクトッ + プワークステーションとの安全性を確保しなければなりません. + また ssh で公開鍵 / 秘密鍵の組を使う場合, + 一般に, ログイン元マシン (通常は自分のワー + クステーション) の安全性を確保しなければなりません. ここで, + <&man.ssh-keygen.1; で公開鍵 / 秘密鍵の組を生成する際, 鍵の組 + をパスワードで防御することにより, 鍵の組への防御層を追加するこ + ともできます. スタッフアカウントのパスワードを + * でつぶすことができると, 管理者自身が設定 + した安全性の高い方法でしかスタッフメンバがログインできないこと + も保証できます. こうして, 多くの侵入者が使う重大なセキュリティ + の穴, すなわち, 安全性の低い無関係なマシンからネットワークを覗 + き見る方法, を塞ぐようなセッションを提供する, 安全性の高い暗号 + 化されたコネクションを使うことを, スタッフメンバ全員に強制する + ことができるのです. + + より間接的なセキュリティの仕組みでは, 制限の強いサーバから + 制限の弱いサーバへログインすることを前提としています. たとえば, + メインマシンで, 様々な種類のサーバを実行させている場合, ワーク + ステーションではそれらのサーバを実行させてはなりません. ワーク + ステーションを十分に安全にしておくためには, 実行するサーバの数 + を, 一つもサーバが実行されていないというくらいにまでできる限り + 減らすべきです. また, パスワードで保護されたスクリーンセーバを + 走らせておくべきです. ワークステーションへの物理的アクセスが与 + えられたとすると, もちろん言うまでもなく, 攻撃者は管理者が設定 + したいかなる種類のセキュリティをもうち破ることができるのです. + このことは, 管理者として必ず考えておかねばならない問題ですが, + システム破りの大多数は, ネットワーク経由でリモートから, ワーク + ステーションやサーバへの物理的アクセス手段を持たない人々によっ + て行われるという事実もまた, 念頭に置いておく必要があります. + + + kerberos のような方法を使うことで, スタッフアカウントのパ + スワードの変更もしくは停止を一箇所で行なうことと, スタッフメン + バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと + が可能となります. スタッフメンバのアカウントが危険に晒されたと + きに, すべてのマシンでスタッフメンバのパスワードを即座に変更す + る能力を過小評価してはいけません. パスワードが分散されている状 + 況では, N 台のマシンでパスワードを変更すると, てんやわんやの事 + 態を招く可能性があります. kerberos を使用すると, パスワードの + 再発行に制限 (re-passwording restriction) を課することもできま + す. この機能を使うことにより, ある kerberos チケットをしばらく + 経つとタイムアウトにすることができるだけでなく, 一定期間 ( 例 + えば, 1 ヶ月に 1 回) 経つと, ユーザに新しいパスワードを選ぶよ + うに要求することもできます. + + + + root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める + + 用心深いシステム管理者は, 自分に必要なサーバプロセスだけを + 過不足なく実行させるものです. サードパーティ製のサーバは, よくバグを持っ + ていがちだということに注意して下さい. たとえば, 古いバージョンの + imapd や popper を実行させておくのは, 全世界に万能の root の切 + 符を与えているようなものです. 自分で注意深くチェックしていない + サーバは, 決して実行してはいけません. root で実行させる必要の + あるサーバはほとんどありません. たとえば, + ntalk, + comsat, + finger デーモンを, 専用ユーザの + 砂場 (sandbox) で実行させることができます. + 管理者が膨大な数の問題に直面していないのなら, この「砂場」は完 + 璧ではありませんが, セキュリティに関するタマネギ的アプローチは + ここでも成り立ちます. 砂場で実行されているサーバプロセスを経由 + して侵入を果たすことができたとしても, 攻撃者はさらに砂場から外 + に脱出しなければなりません. 攻撃者が通過せねばならない層の数が + 増えれば増えるほど, それだけ攻撃者が侵入に成功する確率が減りま + す. root の抜け穴は歴史的に, 基本システムサーバも含め, root 権 + 限で実行されるほとんどすべてのサーバプロセスで発見されています. + ユーザが sshd 経由でのみログインし, + telnetd, + rshd, + rlogind 経由でログインすることが決 + してないマシンを稼働させているのであれば, それらのサービスを停 + 止させて下さい! + + FreeBSD では, 今では ntalkd, + comsat, + finger は砂場で実行させることがデフォ + ルトになっています. 次に砂場で実行させるべきプログラムの候補と + して, &man.named.8; があります. + /etc/defaults/rc.conf ファイルには, + named を砂場で実行するために必要な + 引数がコメントアウトされた形式で含まれています. 新しいシステム + をインストールしているか, それとも既存のシステムをアップグレー + ドして使っているかに依存しますが, 砂場として使用する特別のユー + ザアカウントがインストールされていないかもしれません. 用心深い + システム管理者であれば, できるだけいつでも研究を怠らず, サーバ + に砂場を仕込むものでしょう. + + 通常, 砂場で実行しないサーバが他にいくつかあります. + sendmail, + popper, + imapd, + ftpd などです. これらのうちいくつか + のサーバには代わりとなるものがありますが, 代わりのものをインス + トールするには, あなたが思うより多くの仕事が必要になるかもしれ + ません (便利さという要素がまたも勝利を収めるわけです). これら + のサーバは, root 権限で実行せねばならいかもしれません. また, + これらのサーバ経由で生じる侵入を検出するためには, 他の仕組みに + 頼らなくてはならないかもしれません. + + システムの root 権限の潜在的な穴で他に大きなものとして, シ + ステムにインストールされた suid-root/sgid バイナリがあります. + これらのバイナリは, rlogin のように, + /bin, /sbin, + /usr/bin, /usr/sbin + に存在するものがほとんどです. 100% 安全なものは存在しないとは + いえ, システムデフォルトの siud/sgid バイナリは比較的安全とい + えます. それでもなお, root の穴がこれらのバイナリにときおり発 + 見されています. 1998 年に Xlib で見つかった + root の穴は, xterm (普通, suid 設定 + されています)を脆弱にしてしまいました. 安全である方がよいので, + 用心深いシステム管理者は残念に思いながらも, スタッフのみが実行 + する必要がある suid バイナリは, スタッフのみがアクセス可能な特 + 別なグループに含めるように制限を加え, 誰も使わない suid バイナ + リは (chmod 000 を実行して) 片付けてしまう + でしょう. ディスプレイを持たないサーバは, 一般的に + xterm のバイナリを必要としません. + sgid バイナリもほとんど同様の危険な存在になり得ます. 侵入者が + kmem に sgid されたバイナリを破ることができた場合, その侵入者 + は /dev/kmem を読み出すことができるように + なるでしょう. つまり, 暗号化されたパスワードファイルを読み出す + ことができるようになるので, パスワードを持つどのアカウントをも, + 潜在的な危険に晒すことになります. 他にも, + kmem グループを破った侵入者が pty を通して + 送られたキーストロークを監視できるという危険があります. キース + トロークには, 安全な方法でログインするユーザが使っている pty + も含まれます. tty グループを破った侵入者は, ほぼ任意のユーザの + tty へ書き込みができます. ユーザが端末プログラムやキーボードを + シミュレーションする機能を持ったエミュレータを使っている場合, + 侵入者は潜在的に, 結局そのユーザとして実行されるコマンドをユー + ザの端末にエコーさせるデータストリームを生成できる可能性があり + ます. + + + + ユーザアカウントの安全性を高める + + ユーザアカウントは, 普通, 安全性を高めることが最も困難です. + スタッフに対しては, とても厳格なアクセス制限を強制しパスワード + を * で外すことができるでしょうが, 管理者が + 持ちうる一般ユーザすべてのアカウントに対して同じことはできない + かもしれません. 管理者が十分に統率をとることができるなら, 管理 + 者は勝利し, ユーザのアカウントの安全を適切に確保できるかもしれ + ません. それができないならば, よりいっそう気を配って一般ユーザ + のアカウントを監視するよりほかありません. 一般ユーザアカウント + に対し ssh や kerberos を利用するこ + とには, システム管理がさらに増えたりテクニカルサポートが必要に + なるなどの問題があります. それでも, 暗号化パスワードファイルと + 比較するとはるかに良い解です. + + + + パスワードファイルの安全性を高める + + できるだけ多くのパスワードを * で外し, + それらのアカウントのアクセスには + ssh や kerberos を使うようにするこ + とが, 唯一の確実な方法です. 暗号化パスワードファイル + (/etc/spwd.db) は root でのみ読み出し可能 + だといっても, 侵入者が root の書き込み権限は得られなくとも, 読 + み出しアクセス権限を得ることは可能かもしれません. + + セキュリティスクリプトで常にパスワードファイルの変更をチェッ + クし, 報告するようにすべきです (ファイルの完全性のチェック + 参照). + + + + カーネルのコア, raw デバイス, ファイルシステムの安全性を + 高める + + root の権限を破ると, 攻撃者は何でもできますが, 特に重宝さ + れる特定の事柄もいくつかあります. たとえば, 最近のカーネルは, 組 + み込みのパケット覗き見デバイス (packet sniffing device) ドライ + バを備えているものがほとんどです. FreeBSD では + bpf デバイスと呼ばれています. 侵入者 + は普通, 侵入済みのマシンでパケット覗き見プログラムを実行させよ + うと試みます. 侵入者にわざわざそういう機能を提供する必要はない + ので, ほとんどのシステムで bpf デバイスを組み込むべきではあり + ません. + + bpf デバイスを外しても, /dev/mem と + /dev/kmem という悩みの種がまだ残っていま + す. この問題に関しては, 侵入者は raw ディスクデバイスに書き込 + むこともできます. また, モジュールローダ, &man.kldload.8; とい + う, 別のカーネル機能があります. やる気まんまんの侵入者は, KLD + モジュールを使って自分独自の bpf もしくはその他覗き見デバイス + を動作中のカーネルにインストールすることができます. この問題を + 避けるため, システム管理者はカーネルをより高い安全レベル ( + securelevel) , 少なくとも安全レベル 1 で実行させる必要がありま + す. sysctl を使って + kern.securelevel 変数に安全レベルを設定する + ことができます. ひとたび安全レベルに 1 を設定すると, raw デバ + イスに対する書き込みアクセスは拒否され, たとえば + schg のような特別な chflags フラグの機能が + 強制されます. システム起動に関わる重要なバイナリやディレクトリ, + スクリプトファイルなど, 安全レベルが設定されるまでの間に実行さ + れるすべてのものに対しても schg フラグを on + にしておくことも確実に実行してください. この設定をやり過ぎても + 構いませんが, より高い安全レベルで動作している場合, システムの + アップグレードがはるかに困難になります. システムをより高い安全 + レベルで実行させるようにするが, すべてのシステムファイルとディ + レクトリに schg フラグを設定しないという妥 + 協をする方法もあります. もう一つの可能性としては, 単純に + / および /usr を読み + 込み専用でマウントすることです. ここで特筆すべきことは, システ + ムを守ろうとして厳しくしすぎると, 侵入を検出するという非常に重 + 要なことができなくなってしまうということです. + + + + ファイルの完全性のチェック: バイナリ, 設定ファイルなど + + + ことこの問題に至ると, システム管理者にできることは, 便利さ + という要素がその醜い頭を上げない程度に, コアシステムの設定と制 + 御ファイルを防御することだけです. たとえば, + / および /usr にある + 大部分のファイルに schg ビットを設定するた + めに chflags を使用するのは, おそらく逆効果 + でしょう. なぜなら, そうすることでファイルは保護できますが, 侵 + 入を検出する窓を閉ざしてしまうことにもなるからです. セキュリティ + のタマネギの最後の層はおそらく最も重要なもの – 検出で + す. セキュリティの残りのものは, 突然の侵入を検出できなければ, + まったく有用ではありません (あるいは, もっと悪ければ, 安全性に + 対する間違った感覚を植え付けてしまいます). タマネギの仕事の半 + 分は, もう半分の検出側が攻撃者を攻撃の最中に捕えるようにするた + めに, 攻撃者を食い止めるのではなく侵入を遅らせることなのです. + + + 侵入を検出する最も良い方法は, 変更されていたり, 消えていた + り, 入れた覚えがないのに入っているファイルを探すことです. 変更 + されたファイルを探すのに最も良い方法は, もう一つの (しばしば中 + 央に集められた), アクセスが制限されたシステムから行なうもので + す. さらに安全でアクセス制限されたシステム上でセキュリティ用ス + クリプトを書けば, スクリプトは潜在的なクラッカー達からはほぼ見 + えなくなります. これは重要なことです. この有効性を最大限に活用 + するためには, 一般的に, アクセスの制限されたマシンから実際に使っ + ている他のマシンへのかなりのアクセスを許す必要があります. 普 + 通は, 他のマシンからアクセス制限されたマシンへ読み込み専用の + NFS エクスポートをしたり, アクセス制限されたマシンから他のマシ + ンへ ssh を行なうために, + ssh 鍵のペアを作ったりすることで行 + います. ネットワークのトラフィックを別にして, NFS は最も可視性 + のない方法です – 各クライアント上のファイルシステムを, + 事実上検出されずに監視できるようになります. アクセス制限された + サーバがスイッチを通してクライアントに接続されている場合, たい + てい NFS がより良い選択肢です. アクセス制限されたサーバがハブ + を通したり, いくつかのルーティング層を通したりしてクライアント + に接続する場合, NFS はあまりにも危険な方法かもしれず (ネットワー + クの面で) , ssh の方が認証の道筋は + 跡となって残りますが, それでもより良い方法かもしれません. + + + アクセス制限されたマシンに, 監視しようとするクライアントシ + ステムへの少なくとも読み込みのアクセス権を与えたら, 次に実際に + 監視するためのスクリプトを書かなくてはいけません. NFS マウント + をすれば, &man.find.1; や &man.md5.1; などの単純なシステムユー + ティリティでスクリプトを書くことができます. 少なくとも 1 日 1 + 回, クライアントのファイルを直接 md5 にかけ, さらにもっと頻繁 + に /etc および + /usr/local/etc にあるようなコントロール用 + ファイルを試験するのが一番です. アクセス制限されたマシンが正し + いと知っている, 基となる md5 情報と比べて違いが見つかった場合, + システム管理者に調べて欲しいと悲鳴を上げるようにすべきです. 優 + れたセキュリティ用スクリプトは, / および + /usr などのシステムパーティション上で不適 + 当に suid されたバイナリや, 新たに作成されたファイルや削除され + たファイルもチェックするでしょう. + + NFS ではなく, ssh を使用する場 + 合は, セキュリティ用スクリプトを書くのはずっと難しいことで + す. スクリプトを動かすためには, クライアントに対してスクリプト + を scp しなくてはいけませんし, それは目に見 + えてしまいます. そして, 安全のためには, スクリプトが使うバイナ + リ (find など) を scp する必要もあります. + クライアントの ssh デーモンはすでに + 攻撃されてしまっているかもしれません. 結局のところ, 安全でない + リンク上の場合は ssh は必要かもしれ + ませんが, ssh を扱うのはとても大変 + なことです. + + 優れたセキュリティ用スクリプトは, ユーザやスタッフメンバの + アクセス設定ファイルの変更もチェックするものです. + .rhosts, .shosts, + .ssh/authorized_keys など … + MD5 チェックの範囲外になってしまうであろう + ファイル群です. + + ユーザ用のディスク容量が非常に大きい場合は, パーティション + 上の各ファイルを見て回るのに大変な時間がかかるかもしれません. + この場合は, マウントフラグを設定して, このパーティションに + suid されたバイナリやデバイスを置けないようにするのが良い考え + です.nodev および nosuid + オプション (&man.mount.8; 参照) が知るべきものでしょう. 私なら, + ともかくも週に 1 度はファイルシステムをスキャンするでしょう. + なぜなら, この層の目的は, 侵入が成功したかどうかに関わらず, 侵 + 入があったことの検出をすることだからです. + + プロセスアカウンティング (&man.accton.8; 参照) は, 比較的 + オーバヘッドの低いオペレーティングシステムの機能で, マシンに侵 + 入されてしまった後の評価の仕組みとして使用することをお勧めしま + す. 侵入を受けた後でも当該ファイルが無傷である場合に, 侵入者が + 実際にどのようにしてシステムに侵入したかを追跡するのに特に有益 + です. + + 最後に, セキュリティスクリプトはログファイルを処理するよう + にし, ログファイル自体もできるだけ安全性の高い方法で生成するよ + うにすべきです – リモート syslog は極めて有益になり得ま + す. 侵入者は自分の侵入の痕跡を覆い隠そうとしますし, また, ログ + ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく + ために極めて重要です. ログファイルを永久に残しておくための 1 + つの方法は, システムコンソールをシリアルポートにつないで走らせ, + コンソールを監視している安全なマシンを通して絶えず情報を集める + ことです. + + + + 偏執狂的方法 + + 多少偏執狂的になっても決して悪いことにはなりません. 原則的 + に, システム管理者は, 便利さに影響を与えない範囲でいくつでもセ + キュリティ機能を追加することができます. また, いくらか考慮した + 結果, 便利さに影響を与えるセキュリティ機能を追加することもでき + ます. もっと重要なことには, セキュリティ管理者とは少し喧嘩にな + るはずなのですが – もしあなたが, 本文書に書かれている勧 + 告をそのまま使用した場合は, 予想されるクラッカーはやはり本文書 + を読んでいるわけですから, あなたの防御策を教えてしまうことにな + ります. + + + + サービス妨害攻撃 + + このセクションではサービス妨害攻撃 (DOS 攻撃) を扱います. + サービス妨害攻撃は, 普通は, パケット攻撃です. ネットワークを飽 + 和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシス + テム管理者が打てる手はそれほど多くありませんが, 一般的に, その + 種の攻撃によってサーバがダウンしないことを確実にすることで, 被 + 害をある限度に食い止めることはできます. + + + + サーバの fork の制限. + + + + 踏み台攻撃の制限 (ICMP 応答攻撃, ping broadcast など). + + + + + カーネルの経路情報のキャッシュ. + + + + よくあるサービス妨害攻撃は, fork するサーバプロセスに対す + るものです. これは, サーバにプロセス, ファイル記述子, メモリを + マシンが死ぬまで食い尽くさせようとするものです. inetd + (&man.inetd.8; 参照) には, この種の攻撃を制限するオプションが + いくつかあります. マシンがダウンすることを防止することは可能で + すが, この種の攻撃によりサービスが中断することを防止することは + 一般的に言ってできないことに注意する必要があります. inetd のマ + ニュアルページを注意深く読んで下さい. 特に, + , , + オプションに注意して下さい. IP 偽造攻撃 (spoofed-IP attack) は + inetd の オプションの裏をかけるので, 一般 + にオプションを組み合わせて使用するべきであることに注意して下さ + い. スタンドアロンサーバの中には, 自分自身で fork を制限するパ + ラメータを持っているものがあります. + + Sendmail には, + オプションがあります. シ + ステム負荷の値変化には遅れがあるので, sendmail の負荷限界指定 + オプションを使うよりも, このオプションを使う方がまともに動作す + る可能性ははるかに高いです. + sendmail の実行を開始する際に, + MaxDaemonChildren パラメータを設定するべき + です. その値は, 通常見込まれる負荷を扱える程度に十分高いが, そ + れだけの数の sendmail を操作しよう + とするとマシンが卒倒してしまうほどには高くないような値に設定す + るべきです. sendmail をキュー処理モード + () で実行することや, + sendmail デーモン (sendmail -bd) をキュー処 + 理用プロセス (sendmail -q15m) と別に実行す + ることも, 用心深いことと言えます. それでもなおリアルタイムでの + 配送を望むのであれば, のようにすることで, + キュー処理をはるかに短い時間間隔で行うことができます. いずれに + しても, MaxDaemonChildren オプションに合理 + 的な値を確実に指定して, sendmail がなだれをうって失敗すること + がないようにして下さい. + + syslogd は直接攻撃される可能性 + があるので, 可能ならばいつでも オプション + を用いることを強く推奨します. これができないなら, + オプションを使って下さい. + + tcpwrapper の逆 identd などの接 + 続返し (connect-back) を行うサービスについては十分注意を払うよ + うにするべきです. これらは直接攻撃を受ける可能性があります. こ + ういう事情があるので, tcpwrapper の + 逆 ident 機能を使おうとは思わないのが一般的です. + + 境界ルータのところでファイアウォールを設けて, 外部からのア + クセスに対して内部サービスを防御するという考えは実によいもので + す. この考えは, LAN の外部からの飽和攻撃を防ぐことにあり, 内部 + サービスをネットワークベースの root 権限への攻撃から防御するこ + とにはあまり考慮を払っていません. ファイアウォールは常に排他的 + に設定して下さい. つまり, ポート A, B, C, D と M から Z + まで以外 のすべてに防火壁を設ける + というふうにです. このようにすることで, + named (ゾーンのプライマリである場合), + ntalkd, + sendmail などのインターネットからア + クセスできるサービスとして特に指定するもの以外の, 小さい番号の + ポートすべてをファイアウォールで防御することができます. ファイ + アウォールをこの他のやり方 – つまり包含的もしくは受容的 + なファイアウォールとして設定しようとする場合, + close することを忘れてしまうサービスがいくつか + 出てきたり, 新しい内部サービスを追加したのにファイアウォールの + 更新を忘れたりする可能性がよく出てきます. ファイアウォール上の + 大きい番号のポートを開けておくことにより, 小さい番号のポートを + 危険に晒すことなく受容的な動作を許すことができます. FreeBSD で + は, net.inet.ip.portrange への + sysctl (sysctl -a | fgrep + portrange) をいろいろ使用することで, 動的バインドに使用される + ポート番号の範囲を制御できることを記憶にとどめておいて下さい. + これによりファイアウォールの設定の複雑性を緩和することもできま + す. 私は, ファイアウォールに通常の first/last の範囲として, + 4000 から 5000 を, 高位ポートの範囲として, 49152 から 65535 を + 使用しています. そして, (いくつかのインターネットアクセス可能 + なポートをブロックから除外するのはもちろんですが) 4000 より下 + のすべてをブロックしています. + + また別のよくあるサービス妨害攻撃として, 踏み台攻撃 + (springboard attack) と呼ばれるものがあります – これは, + あるサーバを攻撃し, そこ結果として生成される応答が自分自身, ロー + カルネットワーク, そして他のマシンを過負荷に追い込むようにする + 攻撃です. この種の攻撃の中で最もありふれたものに, + ICMP ping broadcast 攻撃があります. 攻撃 + 者は, 実際に攻撃したいマシンのアドレスを送信元アドレスに設定し + た ping パケットを偽造して, 対象の LAN のブロードキャストアド + レスに向けてパケットを送信します. 境界にあるルータがブロードキャ + ストアドレスに対する ping パケットを握り潰すように設定されてい + ない場合, LAN は, 詐称された送信元アドレスに向けて応答パケット + を生成するはめになり, 犠牲となるマシンが飽和するところまで行っ + てしまいます. 攻撃者が同じトリックを異なるネットワーク上のいく + つものブロードキャストアドレスに対して同時に使用した場合, とく + にひどいことになります. これまでに, 120 メガビット以上のブロー + ドキャスト攻撃が観測されています. 2 番目の踏み台攻撃は, ICMP + エラー報告の仕掛けを狙うものです. 攻撃者は ICMP エラー応答を生 + 成するパケットを生成し, サーバの受信ネットワークを飽和させ, そ + の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし + まうようにすることができます. mbuf を消費し尽くさせることによ + り, この種の攻撃でサーバをクラッシュさせることも可能です. サー + バが生成した ICMP 応答を十分速く送信できない場合, とくにひどい + ことになります. FreeBSD カーネルには, この種の攻撃の効果を抑制 + する ICMP_BANDLIM と呼ばれる新しいカーネルコンパイルオプション + があります. 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は, + udp echo サービスのような, 特定の inetd 内部サービスに関連する + ものです. 攻撃者は, 単に送信元アドレスがサーバ A の echo ポー + トであり, 送信先アドレスがサーバ B の echo ポートであるように + UDP パケットを偽造します. ここでサーバ A, B はともにあなたの + LAN に接続されています. この 2 つのサーバは, この一つのパケッ + トを両者の間で互いに相手に対して打ち返しあいます. このようにし + てパケットをほんのいくつか注入するだけで, 攻撃者は両方のサーバ + と LAN を過負荷状態にすることができます. 同様の問題が内部 + chargen ポートにも存在します. 有能なシステム管理者はこの手の + inetd 内部テストサービスのすべてを無効にしておくものです. + + + 偽造パケット攻撃は, カーネルの経路情報キャッシュに過負荷を + 生じさせるために用いられることもあります. + net.inet.ip.rtexpire, + rtminexpire, rtmaxcache + の sysctl パラメータを参照して下さい. でた + らめな送信元 IP アドレスを用いた偽造パケット攻撃により, カーネ + ルは, 一時的なキャッシュ経路を経路情報テーブルに生成します. こ + れは netstat -rna | fgrep W3 で見ることがで + きます. これらの経路は, 普通は 1600 秒程度でタイムアウトになり + ます. カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを + 検知すると, カーネルは動的に rtexpire を減らしますが, + rtminexpire より小さくなるようには決して減らしません. ここに問 + 題が 2 つあります: + + + + 負荷の軽いサーバが突然攻撃された場合, カーネルが十分素 + 早く反応できないこと. + + + + カーネルが持続的攻撃に耐えられるほど十分 + rtminexpire が低く設定されていないこと. + + + + + 自分のサーバが T3 もしくはそれより高速の回線でインターネッ + トに接続されている場合, &man.sysctl.8; を用いて + rtexpire と rtminexpire + とを手動で上書きしておくことが思慮深いことといえます. どちらか + 一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ + させたくないのであれば :-). 両パラメータを 2 秒 + に設定すれば, 攻撃から経路情報テーブルを守るには十分でしょう. + + + + + Kerberos および SSH を用いたアクセスの問題 + + もしあなたが, kerberos および + ssh を使用したいのだとしたら, 両者 + に関して言っておく必要のある問題がいくつかあります. kerberos V + は大変優れた認証プロトコルですが, kerberos 化された + telnet や + rlogin は, バイナリストリームを扱う + のに不向きになってしまうようなバグがあります. さらに, デフォル + トでは, kerberos は オプションを使わない限 + りセッションを暗号化してくれません. + ssh では, デフォルトですべてを暗号 + 化してくれます. + + ssh はあらゆる場面でとても良く + 働いてくれます. ただし, デフォルトで暗号鍵を転送してしまうこと + を除けばです. これはつまり, 暗号鍵を持った安全なワークステーショ + ンがあって, この暗号鍵で残りのシステムとアクセスできるようになっ + ている場合に, 安全でないマシンへ + ssh を行なう時に暗号鍵が見えてしま + うということです. 実際の鍵そのものが見えてしまうわけではありま + せんが, ssh は, あなたが login して + いる間, 転送用ポートを作ります. クラッカーが安全でないマシンの + root を破ると, クラッカーは, このポートを使って暗号鍵を取得し, + この暗号鍵でロックの外れる他のマシンへのアクセスを得ます. + + + スタッフのログインには, kerberos を組み合せた + ssh を使用することを勧めます. + ssh は, kerberos サポート機能と一緒 + にコンパイルできます. こうすると, 見えてしまうかもしれない + ssh 鍵をあまりあてにしないで良いよ + うになります. また, それと同時に, kerberos 経由でパスワードを + 保護することもできます. ssh 鍵は, + 安全なマシンからの自動化されたタスク (kerberos はこの用途には + 不向きです) のみに使用するべきです. また, + ssh の設定で鍵転送をしないようにす + るか, あるいは, ssh が + authorized_keys ファイル中に書くことを許 + している from=IP/DOMAIN オプションを使用し + て, 特定のマシンからログインしてきたときのみ鍵が有効であるよう + にすることも勧めます. + + + DES, MD5, と Crypt - 原作: &a.wollman; - 24 September 1995. + 改訂: &a.unfurl;, 21 March　 + 2000. - 訳: &a.hanai; + 訳: &a.hanai;, 12 September 1996. + 訳改訂: &a.jp.hino;, + 12 March 2001. + + UNIX システムにおけるすべてのユーザは, そのアカウントに対応し + た一つのパスワードを持っています. それらのパスワードはユーザ本人 + と本当のオペレーティングシステムのみが知っているべきであるという + ことは明らかでしょう. それらのパスワードを秘密に保っておくために, + パスワードは一方向ハッシュとして知られる方式で暗 + 号化されます. 一方向ハッシュとは, 簡単に暗号化はできるが解読は難 + しいという方法です. 言葉を換えると, 先ほど明らかであると書いたの + は実は正しくないのです: オペレーティングシステム自身は + 本当はパスワードを知らないのです. その代わりに + 暗号化された形でのみパスワードを知っていま + す.素のテキストとしてパスワードを得る唯一の方法は, + 可能な限りのパスワード空間を検索するという力任せの方法です. + - UN*X システムにおいてパスワードを保護し, - 簡単に覗かれるのを防 ぐために, - 従来パスワードはある方法によりスクランブルされてきました. - ベル研の Unix 第7版に始まって以来, - パスワードはセキュリティの専門家がい うところの - “一方向ハッシュ関数” - というものを用いることにより暗号化されるようになりました. - つまり, 可能な限りのパスワード空間を検索するという強引な - 方法以外にそのオリジナルを得ることができない, - といった方法でパスワードは変換 されるのです. 不幸なことに, - その当時 AT&T の研究者たちが手に入れることができ - た唯一の暗号化方法は DES(Data Encryption Standard) - に基づいたものでし た. - これは営利企業にとっては大して問題ではありませんが, FreeBSD のよ - うにすべてのソースコードが自由に手に入る - オペレーティングシステムにとっ ては重大な問題となります. - なぜなら, 多くの政府は DES やその他の暗号化ソフ - トウェアが国境を越えることに - 制限をつけようとしているからです. - - ここで, FreeBSD チームは一つのジレンマに直面しました. - つまり, どうす れば法に触れることなく国外にあるそれらの UNIX - システムのすべてに互換性を持 たせることができるか, - ということです. 私たちは ``dual track approach'' を - 取ることに決めました. - 規制されていないパスワードスクランブラのみを含む - 配布用物件を作り, DES - に基づいたパスワードハッシュを付加ライブラリ - として分けて供給するのです. - パスワードをスクランブルさせる関数は, C ライブラリから - libcrypt と呼ばれる(それを実行する C 関数が - crypt と - いう名前だからです)別のライブラリへ移されました. FreeBSD 1.x - 及び 2.0 のリリース前のスナップショットでは, - その規制されていないスクランブラは Nate Williams - によって書かれた安全でない関数を使っていますが, 次の - リリースでは RSA Data Security 社の一方向ハッシュ関数の MD5 - を使う方法 に置き換えられました. - これらの関数はどれも暗号化を含んでいないため, - 合衆国から持ち出し, - 他の多くの国へ持ち込めるものであるとされています. - - 一方, DES - に基づいたパスワードハッシュ関数に関する作業もまた進行中 でした, - まず, 合衆国及び他の国で書かれたコードの同期をとりながら, - 合衆国の外で書かれた crypt - のあるバージョンが持ち込まれました. そしてライブラリは修正され, - 二つにわけられました. すなわち DES libcrypt - は一方向パスワードハッシュをおこなうのに必要なコード のみを含み, - それとは別の libcipher - は実際に暗号化をおこなう - ためのエントリポイントとして生成されました. - コンパイルされたライブラリに対 - して国外に持ち出す許可を得るのを簡単にするために, - コードはこのように分け られたのです. + 不幸なことに, UNIX が生まれようとしているときにパスワードを + 安全な形で暗号化できる方式は DES(Data Encryption Standard) に基 + づいたものだけでした. このことは米国に住んでいるユーザにとって + は大して問題ではありませんでしたが, DES のソースコードを米国外に + 輸出することはできないという問題がありました. そのために, + FreeBSD は, 米国の法律を守ることと, 未だに DES を使っている他の + UNIX 一族との互換性を保つこととを両立する方法を探し出す必要があ + りました. + + その解決方法は, 米国のユーザは DES のライブラリをインストー + ルして DES を使用できるが, 米国外のユーザは国外に輸出可能な他の + ひとつの暗号化方式を使用することができる, というように暗号化ライ + ブラリを分割することでした. これが FreeBSD がデフォルトの暗号化 + 方式として MD5 を使うようになったいきさつです. MD5 は DES よりも + より安全であると考えられているため, DES をインストールする一番の + 理由は互換性を保つためといえます. - <command>crypt</command> メカニズムを理解する - - あるパスワード文字列を作るのに, DES - に基づいたハッシュ関数を使っ たのか, - MD5に基づいたハッシュ関数を使ったのかは非常に簡単にわかります. - MD5 を使ったパスワード文字列は必ず - $1$ という文字 で始まります. - DESを使ったパスワード文字列はどんな特定の文字も持っていま - せんが, MD5を使ったパスワードよりも短く, - $ という文字 - を持たない64文字のアルファベットで構成されています. - したがって, ドル記号で 始まっていない比較的短い文字列は DES - を使ったパスワードである可能性が非常 に高いです. - - あなたのシステムで, - どちらのライブラリが使われているかを決めるの は, - スタティックにリンクされている init - のようなもの(その ようなプログラムに対する唯一の方法は - わかっているパスワードを試してみ - て動くかどうかを確認することです.) - を除いたほとんどのプログラムについ ては非常に簡単なことです. - crypt を使うようなプログラムは - libcrypt にリンクされています. - そしてそれぞれのライブラリに 対する libcrypt - は適切な実装へのシンボリックリンクとなってい ます. 例えば, DES - 版を使っているようなシステムにおいては次のようになって - います: + 暗号化機構を理解する + + FreeBSD がどの暗号化方式を使うようにセットアップされている + かを判断するのは簡単です. + /etc/master.passwd ファイルの中の暗号化さ + れたパスワードを調べてみるのが一つの方法です. MD5 ハッシュで暗 + 号化されたパスワードは, DES ハッシュで暗号化されたパスワードよ + りも長いですし, その上 $1$ と + いう文字で始まるという特徴も持っています. DES のパスワードはこ + れといって識別可能な特徴は持っていませんが, MD5 のパスワードよ + りは短く, そして $ という文字を含ま + ない 64 文字のアルファベットを使って表現されているので, 比較的 + 短い文字列でドル記号で始まっていないものはおそらく DES のパス + ワードでしょう. + + 同様の方法で, ライブラリはパスワードを識別します. 結果とし + て, DES のライブラリは MD5 パスワードを識別でき, そして MD5 を + 使って MD5 で暗号化されたパスワードをチェックし, その他のパス + ワードには DES を使ってチェックします. DES のライブラリは MD5 + も含んでいるのでこのようなことが可能なのです. 残念なことに, 反 + 対は真ではありません. MD5 のライブラリは DES で暗号化されたパ + スワードを認証することができません. + + あなたのシステムでプログラムがどちらのライブラリを使ってい + るかを調べるのは非常に簡単です. crypt を使うプログラムは + libcrypt をリンクしています. そしてそれぞれのライブラリに対す + る適切な実装へのシンボリックリンクとなってい ます. たとえば, DES + 版を使っているようなシステムにおいては次のようになっています: + &prompt.user; ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a - MD5 に基づいたライブラリを使っているシステムにおいては, - 同じようなリンクが 見られるでしょうが, そのターゲットは + MD5 に基づいたライブラリを使っているシステムにおいては, 同 + じようなリンクが 見られるでしょうが, そのターゲットは libdescrypt ではなく libscrypt になっているでしょう. + + もし DES 機能を持った crypt ライブラリ + libdescrypt をインストールしたのなら (つ + まり "crypt" ディストリビューションをインストールした場合), 新 + 規パスワードがどちらのパスワード形式になるかは, + /etc/login.conf の中の + passwd_format ログインケーパビリティによって制 + 御されます. その値としては, des または + md5 を設定することができます. ログインケーパビ + リティに関するより詳細な情報は, login.conf(5) マニュアルページ + をご覧ください. + - S/KEY - - 原作: &a.wollman; - 25 September 1995. - - 訳: &a.jp.hino;. - 24 September 1996. - - S/KEY は一方向ハッシュ関数 (ここで述べているバージョンでは, - 過去と の互換性を保つために MD4 を用いています. S/KEY - の他のバージョンでは MD5 や DES-MAC を用いているものもあります) - を基にしたワンタイムパスワー ド方式です. S/KEY は, バージョン - 1.1.5 以降のすべての FreeBSD に標準的 に含まれています. S/KEY は - FreeBSD 以外の数多くのシステムの上でも利用 可能であり, - その実装の数も増えています. S/KEY ば Bell Communications - Research, Inc. の登録商標です. - - 以下の説明では, 三種類の異なる「パスワード」が使われます. - まず一つ 目は, あなたが普段使っている普通の UNIX スタイルの, - もしくは Kerberos でのパスワードです. ここではこれを - “UNIX パスワード” と呼ぶことにし ます. 二つ目は, - S/KEY の key プログラムによって生成され, - keyinit - プログラムとログインプロンプトが受け付ける, 一回限りの - パスワードです. ここではこれを - “ワンタイムパスワード” と呼ぶことにし ます. - 三つ目のパスワードは, key (と場合により - keyinit) - プログラムに対してユーザが入力する秘密のパスワードで, - ワンタイムパスワー ドを生成するのに使われます. ここではこれを - “秘密のパスフレーズ” もし くは単に - “パスフレーズ” と呼ぶことにします. (訳注: - ユーザが頭の中だ けにしまっておくべきものが, - この秘密のパスフレーズです. なお, 原文では - これをパスワードと表記していますが, - 混乱を避けるために訳文ではすべて “ - 秘密のパスフレーズ” に統一しています.) - - 秘密のパスフレーズは, UNIX - パスワードと同じである必要はありませんし, また UNIX - パスワードと何らかの関連性を持たなければならないということも - ありません (両者を同一に設定することは可能ですが, - お奨めしません). UNIX パスワードは長さが 8 - 文字に制限されています (訳注: FreeBSD で DES - を導入していない場合はもっと長いパスワードも認識されます). - これに対し, S/KEY - では秘密のパスフレーズを好きなだけ長くすることができます (訳注: - 実装上, `key' - コマンドなどのバッファ長で制限されてしまう可能性が あります. - 200文字程度に押えておいた方がよいでしょう :-). 筆者は 7 語か - らなる文を使っています. 通常の設定では, S/KEY システムは UNIX - のパスワー + S/Key + + S/Key は一方向ハッシュ関数を基にしたワンタイムパスワード方式 + です. FreeBSD では, 互換性のために MD4 ハッシュを用いていますが + 他のシステムでは MD5 や DES-MAC を用いてます. S/Key は, バージョ + ン1.1.5 以降のすべての FreeBSD に含まれていますし, FreeBSD 以外 + の数多くのシステムの上でも利用されています. S/Key ば Bell + Communications Research, Inc. の登録商標です. + + 以下の説明では, 三種類の異なる「パスワード」が使われます. + まず一つ目は, あなたが普段使っている普通の UNIX スタイルの, もし + くは Kerberos でのパスワードです. ここではこれを UNIX パ + スワードと呼ぶことにし ます. 二つ目は, S/Key の + key プログラムによって生成され, + keyinit プログラムとログインプロンプトが受け + 付けるパスワードです. ここではこれをワンタイムパスワード + と呼ぶことにします. 三つ目のパスワードは, + key (と場合により keyinit) + プログラムに対してユーザが入力する秘密のパスワードで, ワンタイム + パスワードを生成するのに使われます. ここではこれを秘密の + パスフレーズもしくは単に “パスフレーズ” と呼 + ぶことにします. (訳注: ユーザが頭の中だけにしまっておくべきもの + が, この秘密のパスフレーズです. なお, 原文ではこれをパスワードと + 表記していますが, 混乱を避けるために訳文ではすべて 秘密の + パスフレーズに統一しています.) + + 秘密のパスフレーズは, UNIX パスワードと何の関連性もありませ + ん: 両者を同一に設定することは可能ですが, お奨めしません. UNIX + パスワードは長さが 8 文字に制限されています (訳注: FreeBSD で + DES を導入していない場合はもっと長いパスワードも認識されます). + これに対し, S/Key では秘密のパスフレーズを好きなだけ長くすること + ができます (訳注: 実装上, key コマンドなどの + バッファ長で制限されてしまう可能性があります. 200 文字程度に押 + えておいた方がよいでしょう :-). 6 語から 7 語からなるパスフレー + ズがふつうです. ほとんどの部分で, S/Key システムは UNIX のパスワー ドシステムと完全に独立して動作するようになっています. - S/KEY システムでは他に二種類のデータを使用します. 一つは - “シード (種)” または (混乱を招きますが) - “キー” と呼ばれるもので, (訳注: デ フォルトでは) - 二つの文字と五つの数字で構成されます. もう一つは - “シー ケンス番号 で, 1 以上の整数です. - シーケンス番号は特に指定しなければ 100以下です (訳注: - ``keyinit' プログラムでは 9999 - まで指定できま す). S/KEY - はここまでに述べたデータを利用してワンタイムパスワードを生 - 成します. その方法は, まずシードと秘密のパスフレーズを連結し, - それに対 してシーケンス番号の回数だけ一方向ハッシュ (RSA Data - Security, Inc. に よる MD4 セキュアハッシュ関数) - を繰り返し計算します. そしてその結果を 六つの英単語に変換します - (訳注: ハッシュ計算の後, 64ビットに収まるよう - にデータを処理したものが厳密な意味でのワンタイムパスワードです. - 通常は ユーザの便宜のために, この - 64ビットデータと六つの英単語との間で変換処 理をおこなっています) - . login プログラムと su - プログラム は, - 前回最後に受け付けられたワンタイムパスワードを記録しています. - そし て, その前回のワンタイムパスワードと, - ユーザが入力したワンタイムパスワー - ドを一回ハッシュ関数にかけた結果とが一致した場合に, - このユーザは認証さ れます. 一方向ハッシュ関数を使うことにより, - もし (ログイン等に成功した) - ワンタイムパスワードが一回盗聴されたとしても, - 次回以降に使われる複数の - ワンタイムパスワードを生成することは不可能です. - シーケンス番号はログイ ン (等) - が成功するたびに一つずつ減らされて, ユーザとログインプログラム - の間で同期が取られます. (シーケンス番号が 1 になったら, S/KEY - を再度初 期化する必要があります.) - - 次に, S/KEY 関連の四つのプログラムについて説明します. - key プ ログラムは, シーケンス番号と, - シードと, 秘密のパスフレーズを受け付けて, - ワンタイムパスワードを生成します. keyinit - プログラムは, S/KEY を初期化するのに使用され, - また秘密のパスフレーズやシーケンス番号やシー - ドを変更するためにも使用されます. このプログラムを実行するには, - 秘密の パスフレーズか, または, - シーケンス番号とシードとワンタイムパスワードの 一組かの, - どちらかが必要になります. keyinfo - プログラムは, /etc/skeykeys - というファイルを調べて, このプログラムを起動し - たユーザの現在のシーケンス番号とシードを表示します. 最後に, - login と su - プログラムについてですが, これらは S/KEY の - ワンタイムパスワードを, (訳注:システムが) - ユーザを認証するものとして受 理する処理をおこないます. - login プログラムは, 指定された特定の - アドレスからの接続に対して, UNIX - パスワードの使用を認めなくする機能, 逆に言えば S/KEY - の利用を強制する機能も持っています. - - このドキュメントでは, 四種類の異なる操作について説明します. - 一つ目 は, keyinit - プログラムを信頼できる通信路上で利用する場合で, 一 番始めに - S/KEY を設定する操作や, 使い始めたあとで秘密のパスフレーズや - シードを変更する操作です. 二つ目は, keyinit - プログラムを信頼で きない通信路上で利用する場合で, - 操作の目的は一つ目と同じです. この場合 には - key プログラムを併用する必要があります. - 三つ目は, key プログラムを使い, - 信頼できない通信路を通じてログインする操 作です. 四番目は, - key プログラムを使って, 複数のワンタイムパス - ワードを一気に生成する操作です. - ここで生成した複数のワンタイムパスワー ドは, - メモしたり印刷したりして携帯し, 信頼できる通信路が一切ないところ - (例えば展示会場など) で利用することができます. (訳注: - ワンタイムパスワー ドを記録した紙をなくさないこと! - 電話番号やIPアドレス, ユーザ名を一緒に - メモしていたら最悪です!!) + パスフレーズに加え, S/Key システムにとって重要な二種類のデー + タがあります. 一つはシード (seed: 種)または + キー (key: 鍵)と呼ばれるもので, 二つの文字と五つ + の数字で構成されます. もう一つはシーケンス番号 (iteration + count) で, 1 から 100 までの整数です. S/Key はここまで + に述べたデータを利用してワンタイムパスワードを生成します. その方 + 法は, まずシードと秘密のパスフレーズを連結し, それに対してシーケ + ンス番号の回数だけ MD4 ハッシュを繰り返し計算します. そしてその + 結果を 六つの短い英単語に変換します. login プ + ログラムと su プログラムは, 前回最後に受け付 + けられたワンタイムパスワードを記録しています. そして, その前回 + のワンタイムパスワードと, ユーザが入力したワンタイムパスワードを + 一回ハッシュ関数にかけた結果とが一致した場合に, このユーザは認証 + されます. 一方向ハッシュ関数を使っているので, もし正しく認証され + たワンタイムパスワードが一回盗聴されたとしても, 次回以降に使われ + る複数のワンタイムパスワードを生成することは不可能です. シーケ + ンス番号はログインが成功するたびに一つずつ減らされて, ユーザとロ + グインプログラムの間で同期が取られます. シーケンス番号が 1 まで + 減ったら, S/Key を再度初期化する必要があります. + + 次に, S/Key 関連の四つのプログラムについて説明します. + key プログラムは, シーケンス番号一つと, シー + ド一つと, 秘密のパスフレーズ一つとを受け付けて, ワンタイムパスワー + ドを一つ生成します. keyinit プログラムは, + S/Key を初期化するのに使用され, また秘密のパスフレーズやシーケン + ス番号やシードを変更するためにも使用されます. このプログラムを実 + 行するには, 秘密のパスフレーズか, または, シーケンス番号とシード + とワンタイムパスワードの一組かの, どちらかが必要になります. + keyinfo プログラムは, + /etc/skeykeys というファイルを調べて, この + プログラムを起動したユーザの現在のシーケンス番号とシードを表示し + ます. 最後に, login と su + プログラムについてですが, これらは S/Key のワンタイムパスワード + を, (訳注:システムが) ユーザを認証するものとして受理するのに必要 + な処理をおこないます. login プログラムは, 指 + 定された特定のアドレスからの接続に対して, UNIX パスワードの使用 + を認めなくする機能, 逆に言えば S/Key の利用を強制する機能も持っ + ています. + + この文書では, 四種類の異なる操作について説明します. + 一つ目は, keyinit プログラムを信頼できる通信 + 路上で利用する場合で, 一番始めに S/Key を設定する操作や, 使い始 + めたあとで秘密のパスフレーズやシードを変更する操作です. 二つ目は, + keyinit プログラムを信頼できない通信路上で利 + 用する場合で, 操作の目的は一つ目と同じです. この場合には + key プログラムを併用する必要があります. 三つ + 目は, key プログラムを使い, 信頼できない通信 + 路を通じてログインする操作です. 四番目は, key + プログラムを使って, 複数のワンタイムパスワードを一気に生成する操 + 作です. ここで生成した複数のワンタイムパスワードは, メモしたり + 印刷したりして携帯し, 信頼できる通信路が一切ないところで利用する + ことができます. (訳注: ワンタイムパスワードを記録した紙をなくさ + ないこと! 電話番号やIPアドレス, ユーザ名を一緒にメモしていたら + 最悪です!!) 信頼できる通信路での初期化 - 信頼できる通信路 (例えばあるマシンのコンソール画面など) - を利用して いるときに, S/KEY の初期化, S/KEY - の秘密のパスフレーズの変更, またはシー - ドの変更をおこなうことができます. そのためには, - まずあなた自身がログイ ンし, keyinit - コマンドを以下のようにパラメタなしで実行します: + 信頼できる通信路 (たとえばあるマシンのコンソール画面や, ssh + を使っている時など) を利用しているときに, S/Key を初めて初期化 + すること, S/Key の秘密のパスフレーズを変更すること, またはシー + ドを変更すること, をおこなうことができます. そのためには, まず + あなた自身がログインし, keyinit コマンドを + 以下のようにパラメタなしで実行します: - &prompt.user; keyinit -Updating wollman: ) この部分は始めて S/KEY を使 -Old key: ha73895 ) うときには表示されません. + &prompt.user; keyinit +Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - この動作モードはマシンに直接入力しているときのみ利用 ) すること. もし今 telnet や rlogin を使っているなら, 秘密のパ ) スフレーズを入力せずにこのままコマンドを終了し, かわりに ) keyinit -s を実行すること. -Enter secret password: ) ここで秘密のパスフレーズを入力します. -Again secret password: ) もう一回入力します. - -ID wollman s/key is 99 ha73896 ) あとで説明します. -SAG HAS FONT GOUT FATE BOOM ) - - 上の例で出てきた事柄について説明しましょう. Enter - secret password: - というプロンプトに対してあなたが考えた秘密のパスフレーズを - 入力します (筆者は 7 - 単語以上の文を秘密のパスフレーズにしています). こ - の秘密のパスフレーズは後でログインするために - 必要になるものです. `ID' から始まる行は, S/KEY - における一回分のパラメタであり, あなたのログイ - ン名とシーケンス番号とシードです. (訳注: - `keyinit' コマンドは次回 - にログインするときに使われるパラメタを参考のために - ここで表示しま す. ) S/KEY を使ってログインするときには, - システム側が自動的にこれらの パラメタを表示してくれますから, - これらのパラメタを覚えておく必要は ありません. 最後の行が, - 今述べたパラメタと入力された秘密のパスフレー - ズから計算されたワンタイムパスワードです. この例を実行した後, - 次にログ インするときに打ち込むべきワンタイムパスワードが - これです. +Enter secret password: +Again secret password: + +ID unfurl s/key is 99 to17757 +DEFY CLUB PRO NASH LACE SOFT + + Enter secret password: というプロンプトに + 対してあなたが考えた秘密のパスフレーズを入力します. このパスフ + レーズはログインするときに使うものではなく, ログインするときに + 使うワンタイムパスワードを生成するために使うものであることを覚 + えておいてください. ID から始まる行は, S/Key に + おける一回分のパラメタであり, あなたのログイン名とシーケンス番 + 号とシードです. (訳注: `keyinit' コマンドは + 次回にログインするときに使えるパラメタを参考のためにここで表示 + します.) S/Key を使ってログインするときには, システム側が自動 + 的にこれらのパラメタを表示してくれますから, これらのパラメタを + 覚えておく必要はありません. 最後の行が, 今述べたパラメタと入力 + された秘密のパスフレーズから計算されたワンタイムパスワードです. + この例を実行した後, 次にログインするときに打ち込むべきワンタイ + ムパスワードがこれです. 信頼できない通信路での初期化 - 信頼できない通信路を使って S/KEY を初期化, - または秘密のパスフレーズ やシードを変更するためには, - 信頼できる通信路として, その信頼できない通 - 信路とは別のものを用意する必要があります. - その信頼できる通信路は key - プログラムを実行するために必要となるもので, 例えばそれは, - あなたが信頼できる Macintosh - のデスクアクセサリや信頼できるマシンのシェ - ルプロンプトだったりするでしょう - (そこでの操作に関しては後述します). (訳注: - ここでの通信路とはマシンそのものになります. 信頼できるマシンと - は, 信頼できる人がしっかり管理しているマシンということです.) - 他に準備 しておくものとして, シーケンス番号 - (100は適切な値といえるでしょう) と, - 場合によっては自分で考えた, - またはランダムに生成されたシードがあります. あなたが S/KEY - を初期化しようとしているマシンへの通信路が, 信頼できな - いものである場合には keyinit -s - コマンドを以下のように使用しま す: - - + 信頼できない通信路を使って S/Key を初期化, または秘密のパ + スフレーズを変更するためには, 信頼できる通信路として, その信頼 + できない通信路とは別のものを用意する必要があります. その信頼で + きる通信路は key プログラムを実行するために + 必要となるもので, たとえばそれは, あなたが信頼できる Macintosh + のデスクアクセサリや信頼できるマシンのシェルプロンプトだったり + するでしょう. (訳注: ここでの通信路とはマシンそのものになりま + す. 信頼できるマシンとは, 信頼できる人がしっかり管理しているマ + シンということです.) 他に準備しておくものとして, シーケンス番 + 号 (100 は適切な値といえるでしょう) と, 場合によっては自分で考 + えた, またはランダムに生成されたシードがあります. (あなたが + S/Key を初期化しようとしているマシンへの) 信頼できない通信路を + 使うときには, keyinit -s コマンドを以下のよ + うに使用します: + &prompt.user; keyinit -s -Updating wollman: -Old key: kh94741 -Reminder you need the 6 English words from the skey command. +Updating unfurl: +Old key: to17758 +Reminder you need the 6 English words from the key command. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - skey コマンドの出力する 6 英単語が必要になります. -Enter sequence count from 1 to 9999: 100 ) ここを入力. -Enter new key [default kh94742]: ) リターンのみ入力. -s/key 100 kh94742 - - デフォルトのシード (keyinit - プログラムは困ったことにこれを key と - 読んでいるのですが, 混乱しないよう注意してください) - で構わなければ, リ ターンキーを押してください. 次に, - あらかじめ用意しておいた信頼できる通 信路 - (信頼できるマシンや信頼できる S/KEY デスクアクセサリなど) - へ移っ て, 先ほどと同じパラメタを入力します. - - $prompt.user; key 100 kh94742 +Enter sequence count from 1 to 9999: 100 +Enter new key [default to17759]: +s/key 100 to 17759 +s/key access password: + + デフォルトのシード (keyinit プログラム + は困ったことにこれを key と読んでいるのです + が, 混乱しないよう注意してください) で構わなければ, リターンキー + を押してください. 次に, アクセスパスワードを入れる前に, あらか + じめ用意しておいた信頼できる通信路(信頼できるマシンや信頼でき + る S/Key デスクアクセサリなど) へ移って, 先ほどと同じパラメタ + を入力します: + + &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: ) ここで秘密のパスフレーズを入力します. -HULL NAY YANG TREE TOUT VETO +Enter secret password: <秘密のパスフレーズ> +CURE MIKE BANE HIM RACY GORE ここで信頼できない通信路の方に戻って, - key コマンドが出力したワ - ンタイムパスワードをコピーして keyinit - プログラムに入力します. + key コマンドが出力したワンタイムパスワード + をコピーして keyinit プログラムに入力します. + - s/key access password: HULL NAY YANG TREE TOUT VETO -ID wollman s/key is 100 kh94742 -HULL NAY YANG TREE TOUT VETO + s/key access password:CURE MIKE BANE HIM RACY GORE +ID unfurl s/key is 100 to17759 +CURE MIKE BANE HIM RACY GORE 後は, 前章で説明したことと同様です. - ちょっと寄り道: ログインプロンプトについて + ワンタイムパスワードを一つ生成する - どうやってワンタイムパスワードを生成するかを説明する前に, - S/KEY を 使う場合のログインプロンプトを - 見ておいた方がよいでしょう. + S/Key の初期化ができたら, ログインするときには以下のような + プロンプトが出てくるでしょう: - &prompt.user; telnet himalia -Trying 18.26.0.186... -Connected to himalia.lcs.mit.edu. +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com Escape character is '^]'. -s/key 92 hi52030 -Password: - - パスワードを要求する前に, - ログインプログラムがシーケンス番号とシードを - 表示していることがわかります. - この二つのパラメタを使ってワンタイムパ - スワードを計算することになります. - ここではまだ使っていませんが, 便利な - 機能がログインプログラムに備わっています: - パスワードプロンプトに対して, - 何も入力せずにリターンを押すとエコーモードに切り替わります. - つまりタイ プした文字がそのまま見えるようになるのです. これは - S/KEY のワンタイム パスワードを紙に印刷していた場合など, - ワンタイムパスワードを手で入力し - なければならない場合に特に役立つ機能です. - - このログインしようとしてるマシンが, - あなたが今使っているマシンから UNIX - パスワードを使ってログインすることができないように - 設定されている 場合があります. その場合には, - ログインプロンプトには S/KEY のワンタイ - ムパスワードの利用が必要であることを示す (s/key - required) という注釈が表示されます. - - - ワンタイムパスワードを生成する - - 次に前章のログインプロンプトに対して入力するための - ワンタイムパスワー ドを生成しましょう. そのために, - 信頼できるマシンと key プログラ - ムを使用します. (key プログラムには DOS や - Windows の上で動くも の, - Macintoshのデスクアクセサリとして動くものなどもあります.) - コマンド ラインで key - プログラムを起動するときには, シーケンス番号とシー - ドを引数として指定します. 入力が面倒な人は, - ログインプロンプトに表示さ れたもののうちで - key からその行の最後までを, - そのままカットア ンドペーストすることもできます. - key プログラムの実行は以下のよ - うになります: - - &prompt.user; key 92 hi52030 ) 前章の例からペースト. +FreeBSD/i386 (example.com) (ttypa) + +login: <ユーザ名> +s/key 97 fw13894 +Password: + + ここでは表示していませんが, 便利な機能がログインプログラム + に備わっています: パスワードプロンプトに対して, 何も入力せずに + リターンを押すとエコーモードに切り替わります. つまりタイプし + た文字がそのまま見えるようになるのです. これはS/Key のワンタイ + ムパスワードを紙に印刷していた場合など, ワンタイムパスワードを + 手で入力しなければならない場合に特に役立つ機能です. また, この + ログインしようとしてるマシンが, あなたが今使っているマシンから + UNIX パスワードを使ってログインすることができないように設定さ + れている場合には, ログインプロンプトには S/Key のワンタイムパ + スワードのみが受け付けられることを示す (s/key + required) という注釈が表示されます. + + 次に, このログインプロンプトに対して入力するためのワンタイ + ムパスワードを生成しましょう. そのために, + key プログラムを使える信頼できるマシンを用 + 意します. (key プログラムには DOS や + Windows の上で動くもの, MacOS の上で動くものなどもあります.) + key プログラムを使うときには, シーケンス番 + 号とシードを指定します. ログインしようとしているマシンのログ + インプロンプトの右側をカットアンドペーストすると楽でしょう. + + + 信頼できるシステムで: + + &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: ) 秘密のパスフレーズを入力. -ADEN BED WOLF HAW HOT STUN - - そして別のウィンドウで: - - s/key 92 hi52030 ) 前章の例の続き. -Password: ) ここでリターンキーを押した. - (turning echo on) -Password:ADEN BED WOLF HAW HOT STUN -Last login: Wed Jun 28 15:31:00 from halloran-eldar.l -[以下略.] - - 以上の手順は, 信頼できるマシンが利用できる場合 - のみに 使えるもっ とも簡単な方法です. - Java S/Key の key applet もあり, The Java - OTP Calculator からダウンロードして Java - をサポートするブラウザ上でローカルに - 実行することができます. +Enter secret password: +WELD LIP ACTS ENDS ME HAAG + + ここでワンタイムパスワードが得られました. ログインを続けま + しょう: + + login: <username> +s/key 97 fw13894 +Password: <return to enable echo> +s/key 97 fw13894 +Password [echo on]: WELD LIP ACTS ENDS ME HAAG +Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... + + 以上の手順は, 信頼できるマシンが利用できる場合の + みに使えるもっとも簡単な方法です. Java による + S/Key の key applet もあり, The Java OTP + Calculator からダウンロードして Java をサポートするブ + ラウザ上でローカルに実行することができます. 複数のワンタイムパスワードを生成する - 都合によっては, - 信頼できるマシンや信頼できる通信路が一切確保できな - いようなところで S/KEY を使う必要があるでしょう. - このような場合には, key - コマンドを使って複数のワンタイムパスワードを一気に生成する - ことが可能です. - そして結果を紙に印刷して携帯していくことができます. 例 - えば: + 都合によっては, 信頼できるマシンや信頼できる通信路が一切確 + 保できないようなところで S/Key を使う必要があるでしょう. この + ような場合には, key コマンドを使って複数の + ワンタイムパスワードをあらかじめ一気に生成し, 紙に印刷して携帯 + していくことができます. たとえば: - &prompt.user; key -n 25 57 zz99999 + &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. -Enter secret password: -33: WALT THY MALI DARN NIT HEAD -34: ASK RICE BEAU GINA DOUR STAG -[...] -56: AMOS BOWL LUG FAT CAIN INCH -57: GROW HAYS TUN DISH CAR BALM - - という引数によって 25 - 個のワンタイムパスワードの生成を要 求します. ここで - は, - 最後に表示されている (もっとも大き い) - シーケンス番号です. 残りのパラメタは前出の例と同様です. - 出力は普 通に使う順番とは 逆 - に出力されていることに注意してください (訳注: - 一番最初に使うワンタイムパスワードは - 一番最後に出力されたものです). こ - の結果をカットアンドペーストして lpr - コマンドを使って印刷すると よいでしょう. - もしあなたがセキュリティに偏執するなら, この結果を紙と鉛 - 筆を使って手で書き移した方がよいかもしれません. ここで, - 出力の各行はシー - ケンス番号とそれに対応する一回分のワンタイムパスワードです. - 消費済みの ワンタイムパスワードの行をペンで消していくと - 便利でしょう. +Enter secret password: <秘密のパスフレーズ> +26: SODA RUDE LEA LIND BUDD SILT +27: JILT SPY DUTY GLOW COWL ROT +28: THEM OW COLA RUNT BONG SCOT +29: COT MASH BARR BRIM NAN FLAG +30: CAN KNEE CAST NAME FOLK BILK + + という引数によって 5 個のワンタイム + パスワードを順に生成します. ここで は, 最 + 後のシーケンス番号となるべき数字です. 出力は普通に使う順番とは + 逆に出力されていることに注意してください + (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力され + たものです). この結果をカットアンドペーストして + lpr コマンドを使って印刷すると よいでしょう. + もしあなたがセキュリティに偏執するなら, この結果を紙と鉛筆を使っ + て手で書き移した方がよいかもしれません. ここで, 出力の各行はシー + ケンス番号とそれに対応する一回分のワンタイムパスワードです. + 消費済みの ワンタイムパスワードの行をペンで消していくと便利で + しょう. UNIX パスワードの利用を制限する - 設定ファイル /etc/skey.access - を使って UNIX パスワードの利 - 用を制限することができます. この場合の判断基準として, - ログインを受け付 - ける際のホスト名, ユーザ名, 端末のポート, IP - アドレスなどが利用できま - す. この設定ファイルの詳細に関してはマニュアル - &man.skey.access.5; を - ご覧ください. マニュアルにはこの機能に関わるセキュリティに - ついて, いく - つかの警告が記述してあります. この機能を使って - セキュリティを高めようと + 設定ファイル /etc/skey.access を使っ + て UNIX パスワードの利用を制限することができます. この場合の判 + 断基準として, ログインを受け付ける際のホスト名, ユーザ名, 端末 + のポート, IP アドレスなどが利用できます. この設定ファイルの詳 + 細に関してはマニュアル &man.skey.access.5; をご覧ください. マ + ニュアルにはこの機能に関わるセキュリティについて, いくつかの警 + 告が記述してあります. この機能を使ってセキュリティを高めようと するのならば絶対にこのマニュアルを読んでください. - もし /etc/skey.access - ファイルが存在しないならば (FreeBSD - をインストールした直後の状態では存在しません), - すべてのユーザが UNIX パスワードを利用することができます. - 逆に, もしファイルが存在するならば, - /etc/skey.access - ファイルに明示的に記述されていない限り, すべ てのユーザは - S/KEY の利用を要求されます. どちらの場合においても, その - マシンのコンソールからはいつでも UNIX - パスワードを使ってログインするこ とが可能です. + もし /etc/skey.access ファイルが存在 + しないならば (FreeBSD のデフォルト状態ではそうです), すべての + ユーザが UNIX パスワードを利用することができます. 逆に, もし + ファイルが存在するならば, skey.access ファ + イルに明示的に記述されていない限り, すべてのユーザは S/Key の + 利用を要求されます. どちらの場合においても, そのマシンのコンソー + ルからはいつでも UNIX パスワードを使ってログインすることが可能 + です. - 以下によく使われるであろう - 三種類の設定を含む設定ファイルの例を示し ます: + 以下によく使われるであろう三種類の設定を含む設定ファイルの + 例を示します: -permit internet 18.26.0.0 255.255.0.0 -permit user jrl +permit internet 192.168.0.0 255.255.0.0 +permit user fnord permit port ttyd0 - はじめの行 (permit internet) で, telnet - などで接続するときの IP のソースアドレス (注意: - これは偽造されるおそれがあります) が特定の値と - マスクに一致している場合に, UNIX - パスワードの利用を許可することを指定 しています. - この設定自体はセキュリティを高めるための機能ではありません. - そうではなく, ログインの権利を持つ許可されたユーザに対して, - 現在そのユー - ザが使っているネットワークが信頼できないと考えられるので S/KEY - を使う べきである, - ということを気づかせるための機能であると考えてください. - - 二行目 (permit user) によって, - ある特定のユーザに対して, い つでも UNIX - パスワードの利用を許可するように指定しています. 一般的には - この設定をおこなうべきではありません. key - プログラムがどうして も使えない環境にいる人や, - ダム端末しかない環境にいる人, または何度教え - ても聞く耳を持たないような人を - サポートする必要がある場合にのみ設定をお - こなってください. - - 三行目 (permit port) によって, - ある特定の端末ポートからログ - インしようとするすべてのユーザに対して UNIX - パスワードの利用を許可する ように指定しています. - この設定はダイヤルアップ回線に対する設定として利 - 用できるでしょう. + はじめの行 (permit internet) で, telnet + などで接続するときの IP のソースアドレス (注意: これは偽造され + るおそれがあります) が特定の値とマスクに一致している場合に, + UNIX パスワードの利用を許可することを指定しています. この設定 + 自体はセキュリティを高めるための機能ではありません. そうでは + なく, ログインの権利を持つ許可されたユーザに対して, 現在そのユー + ザが使っているネットワークが信頼できないと考えられるので S/Key + を使うべきである, ということを気づかせるための機能であると考え + てください. + + 二行目 (permit user) によって, ある特定 + のユーザ, この場合は fnord, に対して, いつ + でも UNIX パスワードの利用を許可するように指定しています. 一般 + 的にはこの設定をおこなうべきではありません. + key プログラムがどうしても使えない環境にい + る人や, ダム端末しかない環境にいる人, または何度教えても聞く耳 + を持たないような人をサポートする必要がある場合にのみ設定をおこ + なってください. + + 三行目 (permit port) によって, ある特定 + の端末ポートからログインしようとするすべてのユーザに対して + UNIX パスワードの利用を許可するように指定しています. この設定 + はダイヤルアップ回線に対する設定として利用できるでしょう. + Kerberos 原作: &a.markm; (&a.md; からの寄稿に基づいています). 訳: &a.jp.arimura;. Kerberosは, サーバのサービスによってユーザが安全に認証を受けられる ようにするための, ネットワークの付加システム及びプロトコルです. リモートログイン, リモートコピー, システム間での安全なファイルのコピ ーやその他のリスクの高い仕事がかなり安全に, そしてこれまでより制御 できるようになります. 以下の文章は, FreeBSD用として配布されているKerberosをセットアップ する際のガイドとして読むことができます. しかし, 完全な説明が必要な場合には, マニュアルページを読んだ方がよい でしょう. FreeBSDのKerberosは, - オリジナルの4.4BSD-Liteの配布に含まれている ものではなく, + オリジナルの4.4BSD-Liteの配布に含まれているものではなく, FreeBSD 1.1.5.1のときに移植されたeBonesです. - これはアメリカ/カナダの外で作成されており, - これら以外の国の人々にも 手に入れられるものです. - - このソフトウェアを合法的な配布物として得るために, アメリカも - しくはカナダのサイトから - 持ってこないでください. でないと, - そのサイトが大変な問題に巻き込まれます. - 合法的な配布は, 南アフリカのftp.internat.FreeBSD.orgや, FreeBSD - の公式ミラーサイトから入手することができます. + これはアメリカ/カナダの外で作成されており, そのため, アメリカか + らの暗号技術の輸出制限があった時代でも, + これら以外の国の人々が手に入れられるものでした. 初期データベースの作成 この作業はKerberosサーバだけでおこないます. まず, 古いKerberosの データベースが存在しないことを確認してください. ディレクトリ/etc/kerberosIVに移って, 次のファイルだけが 存在することをチェックします: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms もし他のファイル (principal.* や master_key) が 存在する場合には, kdb_destroyというコマンドで古い Kerberosデータベースを消してください. Kerberosが走っていなければ, 単に余計なファイルを消せばよいです. まず, krb.conf と krb.realmsを編集してKerberosの 管理領域 (realm) を定義してください. ここでは管理領域がGRONDAR.ZA で, サーバ名がgrunt.grondar.zaであるとします. krb.conf というファイルを次のように編集してください: &prompt.root; cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov この例にあるような他の管理領域は, 実際には必要ありません. この例は複数の管理領域を認識する方法を示したものですので, これらの行は含めなくても結構です. 1行目はこのシステムが動いている管理領域の名前です. 他の行は管理領域とホスト名のエントリです. 行の1つめの単語が管理領域で, 2つめがその管理領域の中で - “鍵配布センター”(Key Distribution Center) + 鍵配布センター(Key Distribution Center) として働くホスト名です. ホスト名の次に admin server と書いてある場合には, そのホストが ``管理データベースサーバ''(Administrative Database Server) も提供 することを意味します. これらの単語について詳しく知りたい場合にはKerberosのマニュアル ページをご覧ください. ここで, GRONDAR.ZAという管理領域にgrunt.grondar.za およびその他の.grondar.za ドメインのすべてのホストを追加し なければなりません. krb.realmsは次のようになります: &prompt.root; cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU もう一度注意しますが, 他の管理領域を書く必要はありません. これらは複数の管理領域を認識できるようにマシンを設定する方法を 示した例ですので, これらの行は消して構いません. 1行目は名前をつけた管理領域に 特定の システムを含めるための ものです. 残りの行は名前をつけた管理領域にサブドメインのデフォルトの システムを含めるためのものです. これでデータベースを作成する準備ができました. この操作はKerberos サーバ (鍵配布センター) を起動するだけです. kdb_initコ マンドを次のように実行してください: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: ここで鍵を保存して, ローカルのマシンにあるサーバが取り出せるように します. それにはkstashコマンドを使用します. &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! これで暗号化されたマスタパスワードが /etc/kerberosIV/master_key に保存されました. すべてが動くようにするための設定 Kerberosを導入する それぞれの システムのデータベースに, 2つ のprincipal (主体名) を追加する必要があります. その名前は kpasswdとrcmdです. これら2つのprincipalは, 個々 のシステムにおいて, システム名と同じ名前のインスタンスと組にして作成 されます. これらの kpasswd と rcmd というデーモンによって, 他の システムからKerberosのパスワードを変更したり, rcpや rlogin, rshといったコマンドを実行したりできるよ うになります. それでは実際にこれらのエントリを追加しましょう: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します サーバファイルの作成 次に, 各マシンにおけるサービスを定義している, すべてのインスタンス を展開します. これにはext_srvtabというコマンドを使用しま す. このコマンドで作成されるファイルは, Kerberosの各クライアン トの/etc/kerberosIVディレクトリに 安全な方法でコピーまたは 移動する必要があります. このファイルはそれぞれのサーバとクラ イアントに存在しなければならず, またKerberosの運用において重要なも のです. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... このコマンドは一時的なファイルを作成するだけです. ファイル名をすべ てのサーバが読めるような srvtab という名前に変更しな ければなりません. mvコマンドを用いてシステムの場所に移動 してください. &prompt.root; mv grunt-new-srvtab srvtab そのファイルがクライアントに配るためのもので, ネットワークが安全で はないと思われる場合には, client-new-srvtab を移動 可能なメディアにコピーして物理的に安全な方法で運んでください. クラ イアントの/etc/kerberosIVディレクトリで, 名前を srvtabに変更し, modeを600にするのを忘れないでください: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab データベースへのユーザの追加 ここで, ユーザのエントリをデータベースに追加する必要があります. 始めに, ユーザjaneのエントリを作成してみましょう. kdb_edit を用いて次のように作成してください: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れてください Verifying password New Password: <---- もう一度パスワードを入れてください Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します すべてのテスト まず始めにKerberosデーモンを起動する必要があります. /etc/rc.conf ファイルを正しく編集してあれば, マシンを再 起動することでに自動的にデーモンが起動します. これはKerberosサー バでのみ必要です. Kerberosクライアントは/etc/kerberosIVか ら必要なものを自動的に入手します. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! さあ, これで上で作成した jane というIDのチケットを kinitコマンドで得ることができます: &prompt.user; kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password: klist コマンドを用いてトークンを見て, きちんとチケットを持って いるかどうか確認してください: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA passwd コマンドを用いてパスワードを変更して, kpasswdデーモ ンがKerberos データベースに対して認証されるかどうかチェックして ください: &prompt.user; passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. <command>su</command>特権の追加 root権限が必要なユーザは誰でも, suコマンドのパス ワードをユーザ毎に別のもの として持つことができます. rootにsu できる権利を与えられたidを追加します. これは, principalに付いているroot というインスタンスに よって制御されています. kdb_editを用いて jane.rootというエントリを Kerberosデータベースに作成します: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れます Verifying password New Password: <---- もう一回パスワードを入れます Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ここは短くしてください Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します 実際にトークンをもらって, ちゃんと働いているかどうか確認しましょう: &prompt.root; kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password: ここでrootユーザの .klogin ファイルにユーザを追加する必要が あります. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA suしてみましょう: &prompt.user; su Password: どのトークンを持っているか見てみましょう: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA 他のコマンドの使用 ここまでの例では, jane という principal を root とい うインスタンス付きで作成しました. これはユーザと同じ名前をprincipalと しており, Kerberosのデフォルトの値です; <username>.root という形式の <principal>.<instance>で, 必要なエント リがrootのホームディレクトリの .kloginファイルに あれば, <username>がrootに suすることができま す. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA 同様に, ユーザのホームディレクトリの .kloginファイルに次の ような行がある場合には: &prompt.user; cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA jane または jack という名前で (前述のkinit によって) 認証されている GRONDAR.ZA という管理領域のユーザ なら誰でもrlogin や rsh, rcp等によってこ のシステム (grunt) のjaneのアカウントまたはファ イルにアクセスできます. - 例えば, Janeが他のシステムにKerberos + たとえば, Janeが他のシステムにKerberos を用いてloginします: &prompt.user; kinit MIT Project Athena (grunt.grondar.za) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 次の例では, Jackが同じマシンの Jane のアカウントにloginします. Janeは .klogin ファイルを前述のように設定しており, Kerberosではjackというprincipal をインスタンスなしで設定してあ ります. &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.grondar.za) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 ファイアウォール - 原作: &a.gpalmer;, &a.alex;. + 原作: &a.gpalmer;, Alex Nash;. 訳: &a.jp.saeki;. 11 November 1996. ファイアウォールは, インターネットに参加している人はもちろんのこと, プライベートネットワークのセキュリティ向上のための アプリケーションを 探している人にとっても, ますます興味深くなりつつある分野です. このセクションではファイアウォールとは何か, ファイアウォールの使用法, そしてファイアウォールを構築するために FreeBSD のカーネルで 提供されているファシリティ (機能) の使用法について説明したいと思います. - 社内のネットワークと “巨大かつ信頼のおけない - インターネット” との間にファイアウォールを構築することで + 社内のネットワークと 巨大かつ信頼のおけない + インターネットとの間にファイアウォールを構築することで セキュリティ上のすべての問題が解決できると考える人がいます. ファイアウォールはセキュリティ上の問題を 解決する助けになる場合もありますが, 充分な設定がなされていないファイアウォールは, まったくファイアウォールを 持たない場合よりもセキュリティ上の危険を増大させてしまいます. ファイアウォールにできることは, あなたのシステムにもう一つのセキュリティ層を 追加することだけで, 本気でアタックをしかけてくるクラッカーが内部ネットワークに 侵入するのを妨げることはできません. ファイアウォールを侵入不可能と過信して 内部のセキュリティをおろそかにすることは, 単にクラッカーの仕事を少し簡単にするだけでしか ありません. ファイアウォールとは何か ? 現在インターネットで普通に使用されている ファイアウォールには 二つの異なるタイプがあります. 一つは, 厳密には パケットフィルタリングルータ と 呼ばれるタイプのものです. これはマルチホームのホストマシン (複数の ネットワークに接続されているマシン) のカーネルが, ある規則にしたがって パケットを転送したりブロックしたりするものです. もう一つは, proxy (代理) サーバ として知られているタイプのものです. これは, おそらくはマルチホームのホストマシン上で, カーネルによるパケット転送を 禁止して, デーモンにより認証の提供とパケットの転送とを おこなうものです. 二つのタイプのファイアウォールを組み合わせて使用して, 特定のマシン ( 要塞ホスト と呼ばれる) だけが パケットフィルタリングルータを通して内部ネットワークへ パケットを送ることができるよう設定している サイトがしばしば存在します. proxy (代理) - サービスは通常の認証メカニズムよりもセキュリティを + サービスは通常の認証機構よりもセキュリティを 強化してある 要塞ホストで動作させます. FreeBSD は (IPFW として知られる) カーネルパケットフィルタ込みで 提供されています. このセクションの後の方では, このフィルタについての 説明を集中しておこないます. サードパーティから提供されるソフトウェアを使用することにより, Proxy サーバを FreeBSD 上に構築することができます. しかし, 現在入手可能な proxy サーバは たいへんバラエティに富んでいるので, このドキュメントでそれらすべてを カバーすることは不可能です. パケットフィルタリングルータ ルータとは, 二つまたはそれ以上のネットワークの間で パケットの転送をおこなう マシンのことです. パケットフィルタリングルータは, そのカーネルの内部に, 一つ一つのパケットをルールリストと比較して 転送するかしないかを決める 特別なコードを持っています. 最近の IP ルーティングソフトウェアのほとんどは, 内部に パケットのフィルタリングをおこなうためのコードを持っていて, デフォルトでは すべてのパケットを転送するようになっています. このフィルタを有効にするためには, パケットの通過を許すべきかどうかを決める ルールを自分で定義する必要があります. パケットを通すべきか通すべきでないかを決めるために, パケットヘッダの内容にマッチするものが ルールリストから探されます. マッチするルールが見つかると, ルールアクションが実行されます. ルールアクションには, パケットを捨てる, パケットを転送する, またはパケットの発信元に ICMP メッセージを送り返すというものがあります. ルールの検索は先頭から順番におこなわれ, 通常は最初にマッチしたものだけが 適用されます. そのため, - このルールリストは “ルールチェーン” + このルールリストはルールチェーン と呼ばれることもあります. パケットマッチングの基準は使用するソフトウェアに よって異なりますが, 通常はパケットの発信元 IP アドレス, 宛先 IP アドレス, 発信元ポート番号, 宛先ポート番号 (ポート番号はポートをサポートするプロトコルの場合のみ), パケットタイプ (UDP, TCP, ICMP など) に基づくルールを指定することができます. Proxy サーバ Proxy サーバとは通常のシステムデーモン (telnetd, ftpd など) を 特別なサーバで置き換えたマシンのことです. これらのサーバは, 通常は中継をおこなって特定方向への接続だけを許すため, - proxy サーバ と呼ばれます. (例えば) + proxy サーバ と呼ばれます. (たとえば) proxy telnet サーバをファイアウォールホストで走らせておきます. 外部からユーザがファイアウォールに対して telnet を実行すると, proxy telnet サーバが応答して, - 何らかの認証メカニズムを実行します. これを通過した後で, + 何らかの認証機構を実行します. これを通過した後で, 内部ネットワークへのアクセスがおこなえるように なるのです. (内部ネットワークからの信号は proxy サーバがかわりに受け取り, 外へ向けて送り出します.) Proxy サーバは通常, 普通のサーバより堅固に構築されていて, しばしば - “使い捨て” パスワードシステムなどを含む, - 多様な認証メカニズムを持っています. - “使い捨て”パスワードシステムとは, + 使い捨てパスワードシステムなどを含む, + 多様な認証機構を持っています. + 使い捨てパスワードシステムとは, どういうものなのでしょうか. 仮に誰かが何らかの方法で, あなたが使用したパスワードを手に入れたとします. しかし, 一度使用したことで, そのパスワードは既に無効になっているのです. ですから, そのパスワードをもう一度使用したとしても, あなたのシステムへ アクセスすることはできないというわけです. これらのサーバは中継をおこなうだけで, 実際のところサーバホスト自身への アクセスをユーザに許してはいません. そのため, 何者かがセキュリティシステムに 侵入用の裏口を取り付けることは, より困難になっています. proxy サーバはアクセス制限の方法をいくつも持っていて, 特定のホスト だけがサーバへのアクセス権を得ることができるように なっていることがあり ます. そして目的のマシンと通信できるユーザを制限するように 設定することもできます. もう一度言いますが, どんなファシリティ (機能) が使えるかは, どんな proxy サービスをおこなうソフトウェアを選ぶかに大きく 依存します. IPFW で何ができるか FreeBSD とともに配布されている IPFW は, カーネル内部にあって パケットのフィルタリングとアカウンティングを おこなうシステムであり, ユーザ側のコントロールユーティリティである &man.ipfw.8; を 含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して, カーネルで使用されるルールを定義したり, 現在使用されているルールを 問い合わせたりすることができます. IPFW は互いに関連する二つの部分からなっています. ファイアウォールセクションは パケットフィルタリングをおこないます. また, IP アカウンティングセクションはファイアウォールセクションのものと 似たルールに基づいてルータの使用を追跡します. これにより, - (例えば) 特定のマシンからルータへのトラフィックがどのくらい + (たとえば) 特定のマシンからルータへのトラフィックがどのくらい 発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが フォワードされているかを知ることができます. IPFW は, ルータではないマシンにおいても入出力コネクションの パケットフィルタリングのために 使用することができるように設計されています. これは一般的な IPFW の使用法とは異なる特別な使い方ですが, こういった状況でも同じコマンドと テクニックが使用されます. FreeBSD で IPFW を有効にする IPFW システムの中心となる部分はカーネル内部にあります. そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは それ以上のオプションをカーネルコンフィグレーション ファイルに追加し, カーネルを再コンパイルする必要があるでしょう. カーネルの再コンパイル方法の詳細については, カーネルコンフィグレーション を参照してください. 現在, IPFW に関係するカーネルコンフィグレーションオプションは 三つあります: options IPFIREWALL パケットフィルタリングのためのコードを カーネルに組み込みます. options IPFIREWALL_VERBOSE &man.syslogd.8; を通じて パケットのログを取るためのコードを有効にします. フィルタルールでパケットのログを取るように指定しても, このオプションが指定されていなければ, ログを取ることはできません. options IPFIREWALL_VERBOSE_LIMIT=10 &man.syslogd.8; を通じて ログを取るパケットの数をエントリ毎に制限します. 敵対的な環境においてファイアウォールの 動作のログを取りたいけれど, syslog の洪水によるサービス拒絶攻撃に対し 無防備でありたくないという場合に, このオプションを使用したいと思うことが あるかもしれません. チェーンエントリのログが指定された制限数に達すると, そのエントリに関するログ取りは停止されます. ログ取りを再開するには, &man.ipfw.8; ユーティリティを使用して 関連するカウンタをリセットする必要があります: &prompt.root; ipfw zero 4500 4500 とは, ログ取りを続行したいチェーンエントリの番号です. 以前のバージョンの FreeBSD は IPFIREWALL_ACCT というオプションを 持っていました. しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を 自動的に含むようになったため, 現在では使用されることはなくなっています. IPFW の設定 IPFW ソフトウェアの設定は &man.ipfw.8; ユーティリティを 通じておこないます. このコマンドの構文は非常に 複雑に見えますが, 一旦その構造を理解すれば比較的単純です. このユーティリティでは今のところ四つの異なる コマンドカテゴリが 使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです. 追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか というルールを構築するのに使用します. 表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの 内容を調べるのに使用します. フラッシュはチェーンからすべてのエントリを 取り除くのに使用します. クリアは一つまたはそれ以上のアカウンティングエントリを ゼロにするのに 使用します. IPFW ルールの変更 この形式での使用法は: ipfw -N コマンド index アクション log プロトコル アドレス オプション この形式で使用する際に有効なフラグは一つだけです: -N アドレスやサービス名を 文字列に変換して表示します. コマンド は一意である限り短縮可能です. 有効な コマンド は: add ファイアウォール / アカウンティングルールリストに エントリを追加します. delete ファイアウォール / アカウンティングルールリストから エントリを削除します. 以前のバージョンの IPFW では, ファイアウォールエントリと パケットアカウンティングエントリが別々に利用されていました. 現在のバージョンでは, それぞれのファイアウォールエントリ毎に パケットアカウンティングエントリが備えられています. index が指定されていると, エントリはチェーン中の index で示される位置に置かれます. index が指定されて いなければ, エントリは (65535 番のデフォルトルールである パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した 位置 (チェーンの最後) に置かれます. カーネルが IPFIREWALL_VERBOSE つきでコンパイルされている場合, log オプションはマッチしたルールを システムコンソールに出力させます. 有効な アクション は: reject パケットを捨てます, ICMP ホスト / ポート到達不能パケットを (適切な方を) 発信元へ送ります. allow 通常通りパケットを通過させます. (別名: pass および accept) deny パケットを捨てます. 発信元は ICMP メッセージによる 通知を受けません (そのためパケットが 宛先に到達しなかったように見えます). count このルールはパケットカウンタを更新するだけで, パケットを 通過させたり拒絶したりしません. 検索は次のチェーンエントリから続けられます. それぞれの アクション は一意な先頭部分だけでも認識されます. 指定可能な プロトコル は以下の通り: all 任意の IP パケットにマッチします. icmp ICMP パケットにマッチします. tcp TCP パケットにマッチします. udp UDP パケットにマッチします. アドレス の指定は: from address/mask port to address/mask port via interface port はポートをサポートする プロトコル (UDP と TCP) の 場合にだけ指定可能です. は必須ではなく, 特定のインターフェースを通ってきたパケット だけにマッチするように, IP アドレスまたはローカル IP インターフェースの ドメイン名, またはインターフェース名 - (例えば ed0) を + (たとえば ed0) を 指定することができます. インターフェースユニット番号はオプションで, - ワイルドカードで指定することが できます. 例えば, + ワイルドカードで指定することが できます. たとえば, ppp* はすべてのカーネル PPP インターフェースに マッチします. address/mask の指定は: address または address/mask-bits または address:mask-pattern IP アドレスのかわりに有効なホスト名を指定することも可能です. はアドレスマスクで上位何ビットを１にするべきかを - 示す十進数値です. 例えば次の指定, + 示す十進数値です. たとえば次の指定, 192.216.222.1/24 はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする マスクを作成します. は与えられたアドレスと 論理 AND される IP アドレスです. - キーワード any は“任意の IP - アドレス”を指定するために + キーワード any は任意の IP + アドレスを指定するために 使用することができます. ブロックするポート番号は以下のように指定します: port, port, port… のように単独のポートまたはポートのリストを指定します. または port- port のようにポートの範囲を指定します. 単独のポートとポートのリストを 組み合わせて指定することも可能ですが, その場合は常に範囲の方を 最初に指定しなければなりません. 使用可能な オプション は: frag データグラムの最初の フラグメントでなければマッチします. in 入力途中のパケットであればマッチします. out 出力途中のパケットであればマッチします. ipoptions spec IP ヘッダが spec に指定された カンマで区切られた オプションのリストを含んでいればマッチします. サポートされている IP オプションのリストは: ssrr (ストリクトソースルート), lsrr (ルーズソースルート), rr (レコードパケットルート), そして ts (タイムスタンプ) です. 特定のオプションを含まないことを指定するには ! を先頭につけます. established パケットが既に確立されている TCP コネクションの一部であれば (つまり RST または ACK ビットがセットされていれば) マッチします. established ルールをチェーンの最初の方に置くことで, ファイアウォールのパフォーマンスを向上させることが できます. setup パケットが TCP コネクションを確立しようとするものであれば (SYN ビットがセットされ ACK ビットはセットされていなければ) マッチします. tcpflags flags TCP ヘッダが flags に指定された カンマで区切られたフラグの リストを含んでいればマッチします. サポートされているフラグは, fin, syn, rst, psh, ack と urg です. 特定のフラグを含まないことを指定するには ! を先頭につけます. icmptypes types ICMP タイプが types リストに 存在していればマッチします. リストはタイプの範囲または個々のタイプを カンマで区切った任意の組合せで指定できます. 一般的に使用されている ICMP タイプは: 0 エコーリプライ (ping リプライ), 3 相手先到達不可能, 5 リダイレクト, 8 エコーリクエスト (ping リクエスト), そして 11 時間超過 (&man.traceroute.8; で使用されているように, TTL 満了を示すのに使用されます) です. IPFW ルールリストの表示 この形式での使用法は: ipfw -a -t -N l この形式で使用する際に有効なフラグは三つあります: -a リスト表示の際にカウンタの値も表示します. このオプションは アカウンティングカウンタの 内容を見る唯一の手段です. -t 各チェーンエントリが最後に マッチした時刻を表示します. この時刻表示は &man.ipfw.8; ユーティリティで使用される入力形式と 互換性がありません. -N (可能であれば) アドレスやサービス名を文字列に変換して表示します. IPFW ルールのフラッシュ チェーンをフラッシュするには: ipfw flush カーネルに固定されているデフォルトルール (インデックス 65535 番) 以外の, ファイアウォールチェーンの中のすべてのエントリを削除します. デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると, パケットを許可するエントリがチェーンに追加されるまで, あなたのシステムがネットワークから切り放されてしまいます. そのため, ルールのフラッシュをおこなうときは注意が必要です. IPFW パケットカウンタのクリア 一つまたはそれ以上のパケットカウンタをクリアするためには: ipfw zero index index が指定されていなければ, すべてのパケットカウンタが クリアされます. index が指定されていれば, 特定のチェーンエントリだけが クリアされます. ipfw に対するコマンドの例 - このコマンドはルータを介して転送される, ホスト このコマンドは, ホスト evil.crackers.org から ホスト nice.people.org の telnet ポートへの すべてのパケットを拒絶します: &prompt.root; ipfw add deny tcp from evil.crackers.org to nice.people.org 23 次の例は, ネットワーク crackers.org (クラス C) 全体から マシン nice.people.org (の任意のポート) への 任意の TCP トラフィックを拒絶し, ログを取ります. &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを 張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます: &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup アカウンティングレコードを見るには: &prompt.root; ipfw -a list または短縮形式で &prompt.root; ipfw -a l 最後にチェーンエントリがマッチした - 時刻を見ることもできます. + 時刻を見ることもできます. &prompt.root; ipfw -at l パケットフィルタリングファイアウォールの構築 以下の提案は, ただの提案にすぎません: 必要な処理はそれぞれのファイアウォールで異なるため, あなた独自の要求にあったファイアウォールを構築する方法を ここで述べることはできないのです. 最初にファイアウォールをセットアップするとき, コントロールされた環境でファイアウォールホストの 設定がおこなえるような テストベンチセットアップが用意できない場合には, カーネルのログ取りを 有効にしてログ取り版のコマンドを使用することを 強くおすすめします. そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を 素早くおこなうことができます. 初期セットアップフェーズが完了してからであっても, アタックの可能性のあるアクセスをトレースしたり, 要求の変化に応じてファイアウォールルールを 変更したりできるので, `deny' に対するログ取りをおこなうことをおすすめします. accept コマンドのログ取りをおこなっていると, ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため 大量の ログデータが発生します. そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に 遅くなってしまいます. また, パケットが通過するまでにカーネルにより 多くの仕事を要求するため, パケットのレイテンシ (latency) を増加させてしまいます. syslogd もログをディスクに記録するなど, より多くの CPU タイムを 使用し始め, 実に容易に /var/log が置かれているパーティションを パンクさせてしまう可能性があります. ファイアウォールは, /etc/rc.conf.local か, もしくは /etc/rc.conf によって有効化されるべきです. 関連マニュアルページには, どのドアノブ(訳注: ポートや IP アドレスなど, ネットワークからの入口を示すもののこと)に手をつければ良いのかに ついての説明と, ファイアウォール設定の既定値のリストがあります. もし, 設定の既定値を使わない場合には, ipfw list とすることで, 現在のルールセットを rc.conf から読み込める形で ファイルに出力することができます. また, /etc/rc.conf.local や /etc/rc.conf によってファイアウォールを - 有効化しない場合には, ファイアウォールの有効化が全ての + 有効化しない場合には, ファイアウォールの有効化がすべての IP インターフェイス設定より先に行なわれるように確認することが重要です. 次の問題は, ファイアウォールが実際には何を する べきかです ! これは外部からそのネットワークへのどんなアクセスを許したいか, また内部から外界へのアクセスを どのくらい許したいかに大きく依存します. いくつか一般的なルールを挙げると: 1024 番以下のポートへのすべての TCP 入力アクセスをブロックします. ここは finger, SMTP (mail) そして telnet など, 最もセキュリティに敏感な サービスが存在する場所だからです. すべての 入力 UDP トラフィックをブロックします. これは UDP を使用しているサービスで有用なものは極めて少ないうえ, - 有用なトラフィック (例えば Sun の RPC と NFS プロトコル) + 有用なトラフィック (たとえば Sun の RPC と NFS プロトコル) は, 通常セキュリティに対する脅威となるためです. UDP はコネクションレスプロトコルであるため, 入力 UDP トラフィックを拒絶することは すなわち出力 UDP トラフィックに対する返答をも ブロックすることになるので, このことはそれなりの不利益をもたらします. たとえば外部の archie (prospero) サーバを使用している (内部の) ユーザに とって問題となる可能性があります. もし archie へのアクセスを許したければ, 191 番と 1525 番のポートから 任意の UDP ポートへ来るパケットがファイアウォールを通過することを 許可しなければなりません. 123 番のポートから来るパケットは ntp パケットで, これも通過の許可を考慮する必要がある もう一つのサービスです. 外部から 6000 番のポートへのトラフィックをブロックします. 6000 番のポートは X11 サーバへのアクセスに使用されるポートで, セキュリティに対する脅威となりえます. (特に自分のワークステーションで xhost + をおこなう癖を持っている人がいればなおさらです). X11 は実際に 6000 番以降のポートを使用する可能性があるため, 通過許可に 上限を定めると, そのマシンで走らせることのできる X ディスプレイの 個数が制限されます. RFC 1700 (Assigned Numbers) で定義されているように, 上限は 6063 です. - 内部のサーバ (例えば SQL サーバなど) + 内部のサーバ (たとえば SQL サーバなど) がどのポートを使用するかを チェックします. それらのポートは通常, 上で指定した 1-1024 番の範囲から外れていますので, これらも同様にブロックしておくことは おそらく良い考えです. これとは別のファイアウォール設定に 関するチェックリストが CERT から 入手可能です. - ftp://ftp.cert.org/pub/tech_tips/packet_filtering + url="http://www.cert.org/tech_tips/packet_filtering.html">http://www.cert.org/tech_tips/packet_filtering.html 前にも述べたように, これはただの ガイドライン にすぎません. ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が 決めなければなりません. これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに 侵入してきたとしても, 私は「いかなる」責任もとることはできません. OpenSSL FreeBSD 4.0 では, OpenSSL ツールキットが基本構成の一部に 含まれています. OpenSSL は, Secure Sockets Layer v2/v3 (SSLv2/SSLv3) や Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルと同様の 多目的な暗号化ライブラリを提供します. - しかしながら, OpenSSL に含まれるアルゴリズムのいくつか - (特に RSA や IDEA) は, 合衆国内, その他の地域において, + しかしながら, OpenSSL に含まれるアルゴリズムのひとつ + (特に IDEA) は, 合衆国内, その他の地域において, 特許により保護されています. そのため, - 無制約な利用は許されません(特に IDEA は - FreeBSD の OpenSSL 配布すべてにおいて利用不可能です). - このような理由から - FreeBSD では利用される地域(合衆国/非合衆国)に対応した異なる - 2 種類のバージョンの OpenSSL RSA - ライブラリが利用できるようになっています. + 無制約な利用は許されません. IDEA は + FreeBSD の OpenSSL 配布に含まれていますが, デフォルトではコンパ + イルされません. もし IDEA を使いたいなら, そしてあなたがそのライ + センス条項に合致するなら, /etc/make.conf の中の MAKE_IDEA スイッ + チを有効にして, 'make world' でソースをリビルドしてください. + + + 現在は RSA アルゴリズムはアメリカとその他の国で自由に利用で + きます. 以前は特許により保護されていました. ソースコードのインストール OpenSSL は src-crypto と src-secure cvsup コレクションの一部です. FreeBSD のソースコードの取得と更新の詳細は, FreeBSD の入手の項を参照して下さい. - - - 合衆国外に在住のユーザ - - 合衆国外に住んでいて, 暗号コードを - internat.FreeBSD.org - (合衆国外向けの国際版 Crypto リポジトリ)か, - もしくはそのミラーサイトから取得した場合には, - “本来の RSA を含んだ” OpenSSL を構築することになります. - これは, IDEA の利用が一部地域を除き, 世界中で制限されているためです. - よりフレキシブルな地域識別システムを利用することにより, - 将来的には利用の制限を受けない国での IDEA の構築が - 可能になるかも知れません. - - あなたの国にあると思われる, - 暗号の輸入, 使用, 再配布を制限する国内法に注意して下さい. + + + + IPsec + 原作: &a.shin;, 5 March + 2000. + 訳: &a.jp.hino;, 14 March + 2001. + + + IPsec 機構は, IP 層とソケット層の両方に対して安全な通 + 信を提供します. 本章ではその使い方について説明します. IPsec の内 + 部実現法に関しては 23.5.4 + 章を参照してください. + + 現在の IPsec の実装は, トランスポートモードとトンネルモード + の両方をサポートしています. しかし, トンネルモードにはいくつかの + 制限事項があります. http://www.kame.net/newsletter/ + にはより総合的な例が載っています. + + ここで述べる機能を利用するには, 以下のオプションをカーネルコ + ンパイル時に指定する必要があることにご注意ください. + + +options IPSEC #IP security +options IPSEC_ESP #IP security (crypto; define w/IPSEC) + + + IPv4 におけるトランスポートモードの例 + + + ホスト A (10.2.3.4) とホスト B (10.6.7.8) との間に安全なチャ + ネルを配置するために, セキュリティアソシエーションを設定しましょ + う. ここでは, 少し込み入った例を示します. ホスト A からホストB + へは old AH のみを使います. ホスト B からホスト A へは new AH + と new ESP を組み合わせます. + + ここで "AH"/"new AH"/"ESP"/"new ESP" に対応するアルゴリズ + ムを決めないといけません. アルゴリズムの名前を知るには, + &man.setkey.8; マニュアルページをご覧ください. ここでは, AH に + MD5 を, new AH には new-HMAC-SHA1 を, new ESP には 8 バイト IV + の new-DES-expIV を選びました. + + 鍵長はそれぞれのアルゴリズムに大きく依存します. たとえば, + MD5 では鍵長は 16 バイトでなければなりませんし, new-HMAC-SHA1 + では 20 バイトでなければなりませんし, new-DES-expIV では 8 バ + イトでなければなりません. ここではそれぞれ "MYSECRETMYSECRET", + "KAMEKAMEKAMEKAMEKAME", "PASSWORD", とします. + + 次に, それぞれのプロトコルに対して SPI (セキュリティパラメー + タインデックス: Security Parameter Index) を割り当てます. 三種 + 類のセキュリティヘッダ (ホスト A からホスト B に一つ, ホスト B + から ホスト A に二つ) を生成するので, この安全なチャネルには三 + つの SPI が必要になることに注意してください. さらに, SPI は + 256 以上である必要があることにも注意してください. ここではそれ + ぞれ 1000, 2000, 3000 を割り当てます. + + + + (1) + ホスト A ------> ホスト B + + (1)PROTO=AH + ALG=MD5(RFC1826) + KEY=MYSECRETMYSECRET + SPI=1000 + + (2.1) + ホスト A <------ ホスト B + <------ + (2.2) + + (2.1) + PROTO=AH + ALG=new-HMAC-SHA1(new AH) + KEY=KAMEKAMEKAMEKAMEKAME + SPI=2000 + + (2.2) + PROTO=ESP + ALG=new-DES-expIV(new ESP) + IV length = 8 + KEY=PASSWORD + SPI=3000 + + + + 次に, セキュリティアソシエーションを設定しましょう. ホスト + A とホスト B の両方で, &man.setkey.8; を実行します: + + + +&prompt.root; setkey -c +add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; +add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; +add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; +^D + + + + 実際には, セキュリティポリシのエントリが定義されるまでは + IPsec による通信は行われません. この例の場合, 両方のホストを設 + 定する必要があります. + + + +A で: + +&prompt.root; setkey -c +spdadd 10.2.3.4 10.6.7.8 any -P out ipsec + ah/transport/10.2.3.4-10.6.7.8/require ; +^D + +B で: + +&prompt.root; setkey -c +spdadd 10.6.7.8 10.2.3.4 any -P out ipsec + esp/transport/10.6.7.8-10.2.3.4/require ; +spdadd 10.6.7.8 10.2.3.4 any -P out ipsec + ah/transport/10.6.7.8-10.2.3.4/require ; +^D + + + ホスト A -------------------------------------> ホスト B + 10.2.3.4 10.6.7.8 + | | + ========== old AH keyed-md5 ==========> + + <========= new AH hmac-sha1 =========== + <========= new ESP des-cbc ============ + + - 合衆国内に在住のユーザ - - 今までに述べられたように, 合衆国内では RSA が特許登録されているため, - その使用許諾ライセンスがない限り, 一般的な利用は制限されています. - したがって標準的な OpenSSL の RSA コードの合衆国内における使用は許されておらず, - RSA コードを含む OpenSSL は, 合衆国内のミラーサイトに移されている - OpenSSL から除かれています. - RSA の特許は 2000 年 9 月 20 日に期限切れとなりますので, - そのとき, 合衆国内向け OpenSSL に - “完全な” RSA のコードを戻すことが予定されています. - - しかしながら(幸運にも), RSA - の特許所持者(RSA Security)は, - “RSA リファレンス実装”ツールキット(RSAREF) - を提供しています. - これは非商用利用を含むいくつかの形態での - 利用が可能となっています(非商用利用の定義については RSAREF の - ライセンスを参照して下さい). - - もしあなたが RSAREF ライセンスの条件に合意し, - OpenSSL に RSA をサポートを追加するためにそれを利用したいと考えるなら, - /usr/ports/security/rsaref にある rsaref の port か, - rsaref-2.0 という package - をインストールすることができます. - もし, あなたがライセンス条件の承諾について確信が持てないなら, - 専門家から法的な助言を得てください. - - - RSAREF 実装は, OpenSSL - にある“本来の&rdquo実装よりもの低機能(速度が遅く, - 1024-bit を超える暗号鍵を扱うことができない)です. - 合衆国に在住していないなら, RSAREF は利用しない方が良いでしょう. - + IPv6 におけるトランスポートモードの例 + + IPv6 を使ったもう一つの例. + + ホスト-A とホスト-B 間の TCP ポート番号 110 番の通信には, + ESP トランスポートモードが推奨されます. + + + + ============ ESP ============ + | | + ホスト-A ホスト-B + fec0::10 -------------------- fec0::11 + + + + 暗号化アルゴリズムは blowfish-cbc で, その鍵は "kamekame", + 認証アルゴリズムは hmac-sha1 で, その鍵は "this is the test + key" とします. ホスト-A の設定: + + + + &prompt.root; setkey -c <<EOF + spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec + esp/transport/fec0::10-fec0::11/use ; + spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec + esp/transport/fec0::11-fec0::10/use ; + add fec0::10 fec0::11 esp 0x10001 + -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + add fec0::11 fec0::10 esp 0x10002 + -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + EOF + + + + そしてホスト-B の設定: + + + &prompt.root; setkey -c <<EOF + spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec + esp/transport/fec0::11-fec0::10/use ; + spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec + esp/transport/fec0::10-fec0::11/use ; + add fec0::10 fec0::11 esp 0x10001 -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + add fec0::11 fec0::10 esp 0x10002 -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + EOF + + + + SP の方向に注意してください. + + + + IPv4 におけるトンネルモードの例 + + 二台のセキュリティゲートウェイ間のトンネルモード + + セキュリティプロトコルは old AH トンネルモード, すなわち + RFC1826 で指定されるものです. 認証アルゴリズムは "this is the + test" を鍵とする keyed-md5 です. + + + + ======= AH ======= + | | + ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B + 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 + + + + ゲートウェイ-A における設定: + + + + &prompt.root; setkey -c <<EOF + spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec + ah/tunnel/172.16.0.1-172.16.0.2/require ; + spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec + ah/tunnel/172.16.0.2-172.16.0.1/require ; + add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any + -A keyed-md5 "this is the test" ; + add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any + -A keyed-md5 "this is the test" ; + + EOF + + - RSA security から RSA - のソースコードの適正なライセンスを購入しているユーザは, - RSA のネイティブサポートを得るために - 先に述べた合衆国外向けの国際版 OpenSSL を使用できます. + 上記の例のように, もしポート番号フィールドを書かないと, + "[any]" と同じ意味になります. `-m' は使用される SA のモードを + 指定します. "-m any" はセキュリティプロトコルのモードのワイル + ドカードを意味します. この SA をトンネルモードとトランスポート + モードの両方で使用できます. - また, IDEA のコードも特許による制限のため, - 合衆国内向けの OpenSSL には含まれていません. + そしてゲートウェイ-B では: + + + &prompt.root; setkey -c <<EOF + spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec + ah/tunnel/172.16.0.2-172.16.0.1/require ; + spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec + ah/tunnel/172.16.0.1-172.16.0.2/require ; + add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any + -A keyed-md5 "this is the test" ; + add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any + -A keyed-md5 "this is the test" ; + + EOF + + + + 二台のセキュリティゲートウェイ間の SA の束を作ります + + ゲートウェイ-A とゲートウェイ-B の間では, AH トランスポー + トモードと ESP トンネルモードが要求されます. この例では, ESP ト + ンネルモードが先に適用され, 次に AH トランスポートモードが適用さ + れます. + + + + ========== AH ========= + | ======= ESP ===== | + | | | | + ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B + fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 + + - バイナリインストール - - FreeBSD を(Walnut Creek CDROM 社から購入した - CD-ROM や, それでインストールされたマシンからのコピー, - あるいは - ftp.FreeBSD.org から - ダウンロードしたスナップショットなどから)バイナリインストールで - インストールしていたとすると, - crypto(暗号) コレクションのインストールを選択したとき, - sysinstall - ユーティリティは自動的に適切なバージョンのインストールを行ないます. - 国際版が選択されていたにも関わらず, - インストールがきちんと完了できない(たとえばネットワークの設定をしていなかったり, - FTP サイトからファイルを持ってこなければならなかった)場合には, - インストールの後に package の形で国際版 RSA - ライブラリを追加することができます. - - - - librsaintl という package には, - 国際版(合衆国外向け)の RSA コードが含まれています. - 合衆国内でこれを利用することは違法ですが, - この RSA 実装は高速で柔軟性のありますので, - 合衆国外のユーザはこのバージョンを使うべきです. - この package は ftp.internat.FreeBSD.org - から入手可能です. - 利用の際に RSAREF は必要ありません. - + IPv6 におけるトンネルモードの例 + + 暗号化アルゴリズムは 3des-cbc, ESP の認証アルゴリズムは + hmac-sha1 とします. AH の認証アルゴリズムは hmac-md5 とします. + ゲートウェイ-A での設定は: + + + + &prompt.root; setkey -c <<EOF + spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec + esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require + ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; + spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec + esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require + ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; + add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel + -E 3des-cbc "kamekame12341234kame1234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport + -A hmac-md5 "this is the test" ; + add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel + -E 3des-cbc "kamekame12341234kame1234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport + -A hmac-md5 "this is the test" ; + + EOF + + + + 異なる通信端での SA を作る + + ホスト-A とゲートウェイ-A の間では ESP トンネルモードが要 + 求されています. 暗号化アルゴリズムは cast128-cbc で, ESP の認 + 証アルゴリズムは hmac-sha1 です. ホスト-A とホスト-B との間で + は ESP トランスポートモードが推奨されています. 暗号化アルゴリ + ズムは rc5-cbc で, ESP の認証アルゴリズムは hmac-md5 です. + + + + + ================== ESP ================= + | ======= ESP ======= | + | | | | + ホスト-A ゲートウェイ-A ホスト-B + fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 + + + + ホスト-A での設定: + + + + &prompt.root; setkey -c <<EOF + spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec + esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use + esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; + spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec + esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use + esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; + add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 + -m transport + -E cast128-cbc "12341234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 + -E rc5-cbc "kamekame" + -A hmac-md5 "this is the test" ; + add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 + -m transport + -E cast128-cbc "12341234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 + -E rc5-cbc "kamekame" + -A hmac-md5 "this is the test" ; + + EOF +