第20章 高度なネットワーク

以下に示す netstat の例を使って、ルーティングのさまざまな状態を説明します。

最初の 2 行はデフォルトルート ( 次節 で扱います) と、 localhost への経路を示しています。

localhost に割り当てるインタフェース ( Netif 欄) としてこのルーティングテーブルが指定しているのは lo0 で、これはループバックデバイスともいいます。 これは結局のところ出たところに戻るだけなので、 この送信先あてのトラフィックは、LAN に送られずに、すべて内部的に処理されます。

次の行では 0:e0: から始まるアドレスに注目しましょう。 これはイーサネットハードウェアアドレスで、MAC アドレスともいいます。 FreeBSD はローカルなイーサネット上の任意のホスト (この例では test0 ) を自動的に認識し、 イーサネットインタフェース ed0 にそのホストへの直接の経路をつけ加えます。 この種の経路には、タイムアウト時間 ( Expire 欄) も結びつけられており、 指定された時間内にホストからの応答がないことを判断するのに用いられます。 その場合、そのホストへの経路情報は自動的に削除されます。 これらのホストは RIP (Routing Information Protocol) という、 最短パス判定に基づいてローカルなホストへの経路を決定する仕組みを利用して認識されます。

さらに FreeBSD ではローカルサブネットへの経路情報も加えることができます ( 10.20.30.255 は 10.20.30 というサブネットに対するブロードキャストアドレスで、 example.com はこのサブネットに結びつけられているドメイン名)。 link#1 という名称は、 このマシンの一つ目のイーサネットカードのことをさします。 これらについては、 何も追加インタフェースが指定されていないことがわかります。

これら 2 つのグループ (ローカルネットワークホストとローカルサブネット) は、両方とも routed というデーモンによって自動的に経路が設定されます。 routed を動かさなければ、静的に定義した (つまり明示的に設定した) 経路のみが存在することになります。

host1 の行は私たちのホストのことで、 イーサネットアドレスで示されています。送信側のホストの場合、 FreeBSDはイーサネットインタフェースへ送るのではなく、 ループバックインタフェース ( lo0 ) を使います。

2 つある host2 の行は、 ifconfig(8) のエイリアスを使ったときにどのようになるかを示す例です (このようなことをする理由については Ethernet の節を参照してください)。 lo0 の後にある ⇒ は、 インタフェースが (このアドレスがローカルなホストを参照しているので) ループバックを使っているというだけでなく、 エイリアスになっていることも示しています。 このような経路はエイリアスに対応しているホストにのみ現れます。 ローカルネットワーク上の他のすべてのホストでは、 それぞれの経路に対して単に link#1 となります。

最後の行 (送信先サブネット 224 ) はマルチキャストで扱うものですが、これは他の節で説明します。

最後に Flags (フラグ) 欄にそれぞれの経路のさまざまな属性が表示されます。 以下にフラグの一部と、それが何を意味しているかを示します。

ローカルシステムからリモートホストにコネクションを張る必要がある場合、 既知の経路が存在するかどうかを確認するためにルーティングテーブルをチェックします。 到達するための経路を知っているサブネットの内部にリモートホストがある場合 (Cloned routes)、 システムはそのインタフェースから接続できるかどうか確認します。

知っているパスがすべて駄目だった場合でも、 システムには最後の手段として "デフォルト" ルートがあります。このルートはゲートウェイルート (普通はシステムに 1 つしかありません) の特別なものです。そして、 フラグ欄には必ず c が表示されています。このゲートウェイは、LAN 内のホストにとって、どのマシンでも外部へ (PPP リンク、DSL、ケーブルモデム、T1、 またはその他のネットワークインタフェースのいずれかを経由して) 直接接続するために設定されるものです。

外部に対するゲートウェイとして機能するマシンでデフォルトルートを設定する場合、 デフォルトルートはインターネットサービスプロバイダ (ISP) のサイトのゲートウェイマシンになるでしょう。

それではデフォルトルートの一例を見てみましょう。 一般的な構成を示します。

ホスト Local1 とホスト Local2 はあなたのサイト内にあります。 Local1 はダイアルアップ PPP 接続経由で ISP に接続されています。 この PPP サーバコンピュータは、その ISP のインターネットへの接続点に向けた外部インタフェースを備えた他のゲートウェイコンピュータへ LAN を通じて接続しています。

あなたのマシンのデフォルトルートはそれぞれ次のようになります。

"なぜ (あるいは、どうやって) デフォルトゲートウェイを、 Local1 が接続されている ISP のサーバではなく、 T1-GW に設定するのか" という質問がよくあります。

PPP 接続で、あなたのサイト側の PPP インタフェースは、 ISP のローカルネットワーク上のアドレスを用いているため、 ISP のローカルネットワーク上のすべてのマシンへの経路は 自動的に生成されています。 つまりあなたのマシンは、どのようにして T1-GW に到達するかという経路を既に知っていることになりますから、 ISP サーバにトラフィックを送るのに、 中間的な段階を踏む必要はありません。

一般的にローカルネットワークでは X.X.X.1 というアドレスをゲートウェイアドレスとして使います。ですから (同じ例を用います)、あなたの class-C のアドレス空間が 10.20.30 で ISP が 10.9.9 を用いている場合、 デフォルトルートは次のようになります。

デフォルトルートは /etc/rc.conf ファイルで簡単に定義できます。この例では、 Local2 マシンで /etc/rc.conf に次の行を追加しています。

route(8) コマンドを使ってコマンドラインから直接実行することもできます。

経路情報を手動で操作する方法について詳しいことは route(8) のマニュアルページをご覧ください。

ここで扱うべき種類の設定がもう一つあります。 それは 2 つの異なるネットワークにまたがるホストです。 技術的にはゲートウェイとして機能するマシン (上の例では PPP コネクションを用いています) はすべてデュアルホームホストです。 しかし実際にはこの言葉は、2 つの LAN 上のサイトであるマシンを指す言葉としてのみ使われます。

2 枚のイーサネットカードを持つマシンが、 別のサブネット上にそれぞれアドレスを持っている場合があります。 あるいは、イーサネットカードが 1 枚しかないマシンで、 ifconfig(8) のエイリアスを使っているかもしれません。 物理的に分かれている 2 つのイーサネットのネットワークが使われているならば前者が用いられます。 後者は、物理的には 1 つのネットワークセグメントで、 論理的には 2 つのサブネットに分かれている場合に用いられます。

どちらにしても、 このマシンがお互いのサブネットへのゲートウェイ (inbound route) として定義されていることが分かるように、 おのおののサブネットでルーティングテーブルを設定します。このマシンが 2 つのサブネットの間のルータとして動作するという構成は、 パケットのフィルタリングを実装する必要がある場合や、 一方向または双方向のファイアウォールを利用したセキュリティを構築する場合によく用いられます。

このマシンが二つのインタフェース間で実際にパケットを受け渡すようにしたい場合は、 FreeBSD でこの機能を有効にしないといけません。 くわしい手順については次の節をご覧ください。

ネットワークルータは単にあるインタフェースから別のインタフェースへパケットを転送するシステムです。 インターネット標準およびすぐれた技術的な慣習から、 FreeBSD プロジェクトは FreeBSD においてこの機能をデフォルトでは有効にしていません。 rc.conf(5) 内で次の変数を YES に変更することでこの機能を有効にできます。

このオプションは sysctl(8) 変数の net.inet.ip.forwarding を 1 に設定します。 一時的にルーティングを停止する必要があるときには、 この変数を一時的に 0 に設定しなおせます。

次に、トラフィックの宛先を決めるために、 そのルータには経路情報が必要になります。 ネットワークが十分簡素なら、静的経路が利用できます。 また、FreeBSD は BSD の標準ルーティングデーモンである routed(8) を備えています。これは RIP (バージョン 1 および 2) および IRDP を扱えます。 BGP バージョン 4、OSPF バージョン2、 その他洗練されたルーティングプロトコルは net/zebra package を用いれば対応できます。 また、より複雑なネットワークルーティングソリューションには、 GateD® のような商用製品も利用可能です。

このように FreeBSD を設定したとしても、 ルータに対するインターネット標準要求を完全に満たすわけではありません。 しかし、通常利用に関しては十分といえます。

外部との経路をどのように定義したらよいかはすでに説明しました。 しかし外部から私たちのマシンをどのようにして見つけるのかについては説明していません。

ある特定のアドレス空間 (この例では class-C のサブネット) におけるすべてのトラフィックが、 到着したパケットを内部で転送するネットワーク上の特定のホストに送られるようにルーティングテーブルを設定することができるのは分かっています。

あなたのサイトにアドレス空間を割り当てる場合、 あなたのサブネットへのすべてのトラフィックがすべて PPP リンクを通じてサイトに送ってくるようにサービスプロバイダはルーティングテーブルを設定します。 しかし、国境の向こう側のサイトはどのようにしてあなたの ISP へ送ることを知るのでしょうか?

割り当てられているすべてのアドレス空間の経路を維持する (分散している DNS 情報とよく似た) システムがあり、 そのインターネットバックボーンへの接続点を定義しています。 "バックボーン" とは国を越え、 世界中のインターネットのトラフィックを運ぶ主要な信用できる幹線のことです。 どのバックボーンマシンも、 あるネットワークから特定のバックボーンのマシンへ向かうトラフィックと、 そのバックボーンのマシンからあなたのネットワークに届くサービスプロバイダまでのチェーンのマスタテーブルのコピーを持っています。

あなたのサイトが接続 (プロバイダからみて内側にあることになります) したということを、 プロバイダからバックボーンサイトへ通知することはプロバイダの仕事です。 これが経路の伝搬です。

経路の伝搬に問題が生じて、 いくつかのサイトが接続をおこなうことができなくなることがあります。 ルーティングがどこでおかしくなっているかを明らかにするのに最も有効なコマンドはおそらく traceroute(8) コマンドでしょう。 このコマンドは、あなたがリモートマシンに対して接続をおこなうことができない (たとえば ping(8) に失敗するような) 場合も、同じように有効です。

traceroute(8) コマンドは、 接続を試みているリモートホストを引数にして実行します。 試みている経路が経由するゲートウェイホストを表示し、 最終的には目的のホストにたどり着くか、 コネクションの欠如によって終ってしまうかのどちらかになります。

より詳しい情報は、 traceroute(8) のマニュアルページをみてください。

FreeBSD はマルチキャストアプリケーションとマルチキャストルーティングの両方にネイティブ対応しています。 マルチキャストアプリケーションを動かすのに FreeBSD で特別な設定をする必要は一切ありません。 アプリケーションは普通はそのままで動くでしょう。 マルチキャストルーティングに対応するには、 下のオプションを追加してカーネルをコンパイルする必要があります。

さらに、 /etc/mrouted.conf を編集してルーティングデーモン mrouted(8) を設定し、トンネルと DVMRP を設置する必要があります。 マルチキャスト設定についての詳細は mrouted(8) のマニュアルページを参照してください。

常にネットワークケーブルをつないでいるという面倒なことをせずに、 コンピュータを使用できることは、とても有用でしょう。 FreeBSD は無線のクライアントとして、 さらに "アクセスポイント" としても使えます。

802.11 無線デバイスの設定には、BSS と IBSS の二つの方法があります。

Bluetooth は免許のいらない 2.4 GHz の帯域を利用して、 10 m 程度のパーソナルネットワークを作る無線技術です。 ネットワークはたいていの場合、その場その場で、携帯電話や PDA やノートパソコンなどの携帯デバイスから形成されます。 Wi-Fi などの他の有名な無線技術とは違い、 Bluetooth はより高いレベルのサービスを提供します。 たとえば、FTP のようなファイルサーバ、ファイルのプッシュ、 音声伝送、シリアル線のエミュレーションなどのサービスです。

FreeBSD 内での Bluetooth スタックは Netgraph フレームワーク ( netgraph(4) 参照) を使って実現されています。 ng_ubt(4) ドライバは、 多種多様な Bluetooth USB ドングルに対応しています。 Broadcom BCM2033 チップを搭載した Bluetooth デバイスは ubtbcmfw(4) および ng_ubt(4) ドライバによって対応されています。 3Com Bluetooth PC カード 3CRWB60-A は ng_bt3c(4) ドライバによって対応されています。 シリアルおよび UART を搭載した Bluetooth デバイスは sio(4) , ng_h4(4) および hcseriald(8) ドライバによって対応されています。 この節では USB Bluetooth ドングルの使用法について説明します。 Bluetooth に対応しているのは FreeBSD 5.0 以降のシステムです。

デフォルトでは Bluetooth デバイスドライバはカーネルモジュールとして利用できます。 デバイスを接続する前に、 カーネルにドライバを読み込む必要があります。

Bluetooth デバイスがシステム起動時に存在している場合、 /boot/loader.conf からモジュールを読み込んでください。

USB ドングルを挿してください。コンソールに (または syslog に) 下記のような表示が現れるでしょう。

/usr/shared/examples/netgraph/bluetooth/rc.bluetooth を /etc/rc.bluetooth のようなどこか便利な場所にコピーしてください。 このスクリプトは Bluetooth スタックを開始および終了させるのに使われます。 デバイスを抜く前にスタックを終了するのはよい考えですが、 (たいていの場合) しなくても致命的ではありません。 スタックを開始するときに、下記のような出力がされます。

ホストコントローラインタフェース (HCI) は、 ベースバンドコントローラおよびリンクマネージャへのコマンドインタフェースを提供し、 ハードウェアステータスおよびコントロールレジスタへアクセスします。 このインタフェースは Bluetooth ベースバンド機能へアクセスする画一的な方法を提供します。 ホストの HCI 層は Bluetooth ハードウェア上の HCI ファームウェアと、 データとコマンドをやり取りします。 ホストコントローラトランスポート層 (つまり物理的なバス) のドライバは、 両方の HCI 層に相互に情報を交換する能力を与えます。

一つの Bluetooth デバイスにつき、 hci タイプの Netgraph ノードが一つ作成されます。 HCI ノードは通常 Bluetooth デバイスドライバノード (下流) と L2CAP ノード (上流) に接続されます。 すべての HCI 動作はデバイスドライバノード上ではなく、 HCI ノード上で行われなくてはいけません。 HCI ノードのデフォルト名は "devicehci" です。 詳細については ng_hci(4) マニュアルを参照してください。

最も一般的なタスクの一つに、無線通信的に近傍にある Bluetooth デバイスの発見があります。 この動作は inquiry (問い合わせ) と呼ばれています。 Inquiry や他の HCI に関連した動作は hccontrol(8) ユーティリティによってなされます。 下記の例は、どの Bluetooth デバイスが通信圏内にあるかを知る方法を示しています。 デバイスのリストが表示されるには数秒かかります。 リモートデバイスは discoverable (発見可能な) モードにある場合にのみ inquiry に返答するということに注意してください。

BD_ADDR は Bluetooth デバイスに固有のアドレスです。 これはネットワークカードの MAC アドレスに似ています。 このアドレスはデバイスとの通信を続けるのに必要となります。 BD_ADDR に人間が判読しやすい名前を割り当てることもできます。 /etc/bluetooth/hosts ファイルには、 既知の Bluetooth ホストに関する情報が含まれています。 次の例はリモートデバイスに割り当てられている、 人間が判読しやすい名前を得る方法を示しています。

リモートの Bluetooth デバイス上で inquiry を実行すると、 あなたのコンピュータは "your.host.name (ubt0)" と認識されます。 ローカルデバイスに割り当てられた名前はいつでも変更できます。

Bluetooth システムは一対一接続 (二つの Bluetooth ユニットだけが関係します) または一対多接続を提供します。 一対多接続では、接続はいくつかの Bluetooth デバイス間で共有されます。 次の例は、ローカルデバイスに対するアクティブなベースバンド接続のリストを得る方法を示しています。

connection handle はベースバンド接続の終了が必要とされるときに便利です。 もっとも、通常はこれを手動で行う必要はありません。 Bluetooth スタックはアクティブでないベースバンド接続を自動的に終了します。

利用可能な HCI コマンドの完全な一覧を得るには、 hccontrol help を参照してください。 HCI コマンドのほとんどはスーパユーザ権限を必要としません。

ロジカルリンクコントロールおよびアダプテーションプロトコル (L2CAP) は、プロトコル多重化ケーパビリティおよび分割・再編成動作を備えた、 上位層プロトコルへのコネクション指向およびコネクションレスデータサービスを提供します。 L2CAP は上位層プロトコルおよびアプリケーションが 64 KB までの長さの L2CAP データパケットを送受信することを可能にします。

L2CAP は チャネル の概念に基づいています。 チャネルはベースバンド接続の上位に位置する論理的な接続です。 それぞれのチャネルは多対一の方法で一つのプロトコルに結びつけられます。 複数のチャネルを同じプロトコルに結びつけることは可能ですが、 一つのチャネルを複数のプロトコルに結びつけることはできません。 チャネル上で受け取られたそれぞれの L2CAP パケットは、 適切なより上位のプロトコルに渡されます。 複数のチャネルは同じベースバンド接続を共有できます。

一つの Bluetooth デバイスに対して、 l2cap タイプの Netgraph ノードが一つ作成されます。 L2CAP ノードは通常 Bluetooth HCI ノード (下流) と Bluetooth ソケットノード (上流) に接続されます。 L2CAP ノードのデフォルト名は "devicel2cap" です。 詳細については ng_l2cap(4) マニュアルを参照してください。

便利なコマンドに、他のデバイスに ping を送ることができる l2ping(8) があります。Bluetooth 実装によっては、 送られたデータすべては返さないことがあります。 したがって次の例で 0 バイト は正常です。

l2control(8) ユーティリティは L2CAP ノード上でさまざまな操作を行うのに使われます。 この例は、ローカルデバイスに対する論理的な接続 (チャネル) およびベースバンド接続の一覧を得る方法を示しています。

別の診断ツールが btsockstat(1) です。 これは netstat(1) と同様の作業を、Bluetooth ネットワークに関するデータ構造についての行います。 下記の例は上の l2control(8) と同じ論理的な接続を示します。

RFCOMM プロトコルは L2CAP プロトコルを介してシリアルポートのエミュレーションを提供します。 このプロトコルは ETSI (訳注: 欧州電気通信標準化機構) 標準 TS 07.10 に基づいています。 RFCOMM プロトコルは、単純な伝送プロトコルに RS-232 (EIATIA-232-E) シリアルポートの 9 本の結線をエミュレートする項目を加えたものです。 RFCOMM プロトコルは、二つの Bluetooth デバイス間で、最大 60 までの同時接続 (RFCOMM チャネル) に対応しています。

RFCOMM の目的から、完全な通信経路は、異なるデバイス上 (通信の端点) で動作している二つのアプリケーションと、 その間の通信セグメントを含んでいます。RFCOMM は、それが動いているデバイスのシリアルポートを利用するアプリケーションをカバーするためのものです。 通信セグメントはあるデバイスから他のデバイスへの Bluetooth リンクです (直接接続)。

RFCOMM は直接接続している場合のデバイス間の接続、 またはネットワークの場合のデバイスとモデムの間の接続にだけ関係があります。 RFCOMM は、一方が Bluetooth 無線技術で通信し、 もう一方で有線インタフェースを提供するモジュールのような、 他の構成にも対応できます。

FreeBSD では RFCOMM プロトコルは Bluetooth ソケット層に実装されています。

デフォルトでは Bluetooth 通信は認証されておらず、 すべてのデバイスが他のすべてのデバイスと通信できます。 Bluetooth デバイス (たとえば携帯電話) は特定のサービス (たとえばダイアルアップサービス) を提供するために、 認証を要求することも選択できます。 Bluetooth 認証は通常 PIN コード で行われます。 PIN コードは最長 16 文字のアスキー文字列です。 ユーザは両デバイスで同じ PIN コードを入力することを要求されます。 一度 PIN コードを入力すると、 両デバイスは リンクキー を作成します。 その後、リンクキーはそのデバイス自身または、 不揮発性記憶デバイス内に格納できます。 次の機会には、両デバイスは前に作成されたリンクキーを使用するでしょう。 このような手続きを ペアリング (pairing) と呼びます。いずれかのデバイス上でリンクキーが失われたときには、 ペアリングをやり直さなければならないことに注意してください。

hcsecd(8) デーモンが Bluetooth 認証要求のすべてを扱う責任を負っています。 デフォルトの設定ファイルは /etc/bluetooth/hcsecd.conf です。 PIN コードが "1234" に設定された携帯電話に関する例は以下の通りです。

PIN コードには (長さを除いて) 制限はありません。 いくつかのデバイス (たとえば Bluetooth ヘッドフォン) には固定的な PIN コードが組み込まれているかもしれません。 -d オプションは hcsecd(8) デーモンがフォアグラウンドで動作するように強制するため、 何が起きているのか確認しやすくなります。 リモートデバイスがペアリングを受け取るように設定して、 リモートデバイスへの Bluetooth 接続を開始してください。 リモートデバイスはペアリングが受け入れらた、と応答して PIN コードを要求するでしょう。 hcsecd.conf 内にあるのと同じ PIN コードを入力してください。 これであなたの PC とリモートデバイスがペアとなりました。 また、リモートデバイスからペアリングを開始することもできます。 以下は hcsecd の出力例です。

サービスディスカバリプロトコル (SDP) は、 クライアントアプリケーションが、 サーバアプリケーションが提供するサービスの存在とその属性を発見する手段を提供します。 サービスの属性には提示されているサービスのタイプまたはクラス、 および、サービスを利用するのに必要な仕組みまたはプロトコルの情報が含まれます。

SDP には SDP サーバと SDP クライアント間の通信が含まれます。 SDP サーバは、サーバに関連づけられたサービスの特性について記述しているサービスレコードの一覧を維持しています。 各サービスレコードにはそれぞれ 1 つのサービスの情報が書かれています。 クライアントは SDP リクエストを出すことによって、 SDP サーバが維持しているサービスレコードから情報を検索できます。 クライアントまたはクライアントに関連づけられたアプリケーションがサービスを利用することにしたら、 サービスを利用するためには、 サービスプロバイダへの接続を別途開かなければなりません。 SDP はサービスとそれらの属性を発見するための仕組みを提供しますが、 そのサービスを利用するための仕組みは提供しません。

通常 SDP クライアントは希望するサービスの特性に基づいてサービスを検索します。 しかしながら、サービスに関する事前の情報なしに、 どのタイプのサービスが SDP サーバのサービスレコードに記述されているか知ることが望ましいことがあります。 この、提供されている任意のサービスを閲覧する手順を、 ブラウジング (browsing) と呼びます。

現在のところ Bluetooth SDP サーバおよびクライアントは、 ここ からダウンロードできる第三者パッケージ sdp-1.5 で実装されています。 sdptool はコマンドラインの SDP クライアントです。 次の例は SDP ブラウズの問い合わせ方法を示しています。

FreeBSD 上における Bluetooth クライアントへのサービス提供は sdpd サーバが行います。

sdptool は、ローカル SDP サーバにサービスを登録するのにも用いられます。 下記の例は PPP (LAN) サービスを備えたネットワークアクセスを登録する方法を示しています。 一部のサービスでは属性 (たとえば RFCOMM チャネル) を要求することに注意してください。

ローカル SDP サーバに登録されたサービスの一覧は SDP ブラウザの問い合わせを "特別な" BD_ADDR に送ることで得られます。

ダイアルアップネットワーク (DUN) プロファイルはほとんどの場合、 モデムや携帯電話とともに使用されます。 このプロファイルが対象とする場面は以下のものです。

PPP (LAN) によるネットワークアクセスプロファイルは、 次の状況で利用できます。

FreeBSD ではどちらのプロファイルも ppp(8) と rfcomm_pppd(8) (RFCOMM Bluetooth 接続を PPP が制御可能なように変換するラッパ) で実装されています。 いずれかのプロファイルが使用可能となる前に、 /etc/ppp/ppp.conf 内に新しい PPP ラベルが作成されていなければなりません。 例については、 rfcomm_pppd(8) のマニュアルページを参照してください。

次の例では、DUN RFCOMM チャネル上で BD_ADDR が 00:80:37:29:19:a4 のリモートデバイスへの RFCOMM 接続を開くのに rfcomm_pppd(8) が使われます。実際の RFCOMM チャネル番号は SDP を介してリモートデバイスから得ます。 手動で RFCOMM チャネルを指定することもでき、その場合 rfcomm_pppd(8) は SDP 問い合わせを実行しません。 リモートデバイス上の RFCOMM チャネルを見つけるには、 sdptool を使ってください。

PPP (LAN) サービスでネットワークアクセスを提供するためには、 sdpd サーバが動いていなければなりません。 これはローカル SDP サーバに LAN サービスを登録するのにも必要です。 LAN サービスは RFCOMM チャネル属性を必要とすることに注意してください。 /etc/ppp/ppp.conf ファイル内に LAN クライアントの新しいエントリを作成しなければなりません。 例については rfcomm_pppd(8) のマニュアルページを参照してください。 最後に、RFCOMM PPP サーバが実行され、 ローカル SDP サーバに登録されているのと同じ RFCOMM チャネルで待ち受けていなければなりません。 次の例は RFCOMM PPP サーバを起動する方法を示しています。

OBEX はモバイルデバイス間で広く使われている単純なファイル転送プロトコルです。 これは主に赤外線通信で利用されており、ノートパソコンや PDA 間の汎用的なファイル転送、および PIM アプリケーションを搭載した携帯電話その他のデバイス間で名刺やカレンダーエントリを転送するのに用いられます。

OBEX サーバおよびクライアントは、 ここ からダウンロードできる obexapp-1.0 という第三者のパッケージとして実装されています。 このパッケージは openobex ライブラリ (上記の obexapp に含まれます) および devel/glib12 port を必要とします。 なお、obexapp はルート権限を必要としません。

OBEX クライアントは OBEX サーバとの間でオブジェクトを渡したり (プッシュ) および受け取ったり (プル) するのに使用されます。 オブジェクトは、たとえば名刺や予定などになります。 OBEX クライアントは RFCOMM チャネル番号を SDP によってリモートデバイスから得ることができます。 これは RFCOMM チャネル番号の代わりにサービス名を指定することによって行うことができます。 対応しているサービス名は IrMC, FTRN および OPUSH です。 RFCOMM チャネルを番号で指定することもできます。 下記は、デバイス情報オブジェクトを携帯電話から受け取り、 新しいオブジェクト (名刺) が携帯電話に渡される場合の OBEX セッションの例です。

OBEX プッシュサービスを提供するためには、 sdpd サーバが実行されていなければなりません。 また OPUSH サービスをローカル SDP サーバに登録することも必要です。 なお、OPUSH サービスには RFCOMM チャネル属性が必要です。 渡されるオブジェクトをすべて格納するルートフォルダを作成しなければいけません。 ルートフォルダのデフォルトパスは /var/spool/obex です。 最後に OBEX サーバが実行され、 ローカル SDP サーバに登録されているのと同じ RFCOMM チャネルで待ち受けていなければなりません。 下記の例は OBEX サーバの起動方法を示します。

シリアルポート (SP) プロファイルは Bluetooth デバイスが RS232 (または同様の) シリアルケーブルエミュレーションを行えるようにします。 このプロファイルが対象とする場面は、 レガシーアプリケーションが、仮想シリアルポート抽象を介して Bluetooth をケーブルの代替品として使うところです。

rfcomm_sppd(1) ユーティリティはシリアルポートプロファイルを実装します。 Pseudo tty が仮想シリアルポート抽象概念として用いられます。 下記の例はリモートデバイスのシリアルポートサービスへ接続する方法を示します。 なお、RFCOMM チャネルを指定する必要はありません。- rfcomm_sppd(1) は SDP を介してリモートデバイスからその情報を得ることができます。 これを上書きしたい場合にはコマンドラインで RFCOMM チャネルを指定してください。

接続された pseudo tty はシリアルポートとして利用することができます。

IP サブネットを作成して、 それらのセグメントをルータを使って接続することなしに、 (Ethernet セグメントのような) 一つの物理ネットワークを二つのネットワークセグメントに分割することはとても有効な場合があります。 この方法で二つのネットワークを繋ぐデバイスは "ブリッジ" と呼ばれます。 二つのネットワークインタフェースカードを持つ FreeBSD システムは、ブリッジとして動作することができます。

ブリッジは、各ネットワークインタフェイスに繋がるデバイスの MAC 層のアドレス (Ethernet アドレス) を記憶することにより動作します。 ブリッジはトラフィックの送信元と受信先が異なったネットワーク上にある場合にのみトラフィックを転送します。

多くの点で、ブリッジはポート数の少ない Ethernet スイッチのようなものといえます。

今日ブリッジが活躍する場面は大きく分けて二つあります。

ブリッジを有効にするには、 /etc/sysctl.conf に以下の行を加えてください。

指定したインタフェースでブリッジを可能にするには以下を加えてください。

( if1 および if2 は二つのネットワークインタフェースの名前に置き換えてください)。 ブリッジを経由したパケットを ipfw(8) でフィルタしたい場合には、 以下の行も付け加える必要があります

FreeBSD 5.2-RELEASE 以降では、かわりに以下の行を使用してください。

ネットワークからブリッジに telnet(1) したい場合、 ネットワークカードの一つに IP アドレスを割り当てるのが正しいです。 一般的に、両方のカードに IP アドレスを割り当てるのはよい考えではないとされています。

ネットワーク内に複数のブリッジを設置する場合、 任意のワークステーション間で一つ以上の経路を持つことはできません。 技術的には、 これはスパニングツリーのリンク制御はサポートされていない、 ということを意味します。

ブリッジは、 ping(8) にかかる時間を遅らせることがあります。特に、 一方のセグメントからもう一方へのトラフィックでそうなります。

NFS は最低二つの主要な部分、 サーバと一つ以上のクライアントからなります。 クライアントはサーバマシン上に格納されたデータにリモートからアクセスします。 これが適切に機能するには、 いくつかのプロセスが設定されて実行されていなければなりません。

サーバは以下のデーモンを動作させなければなりません。

クライアント側では nfsiod というデーモンも実行できます。 nfsiod デーモンは NFS サーバからのリクエストを処理します。 これは任意であり、性能を改善しますが、 通常の正しい動作には必要としません。詳細については nfsiod(8) マニュアルページを参照してください。

NFS の設定は比較的素直な工程です。 動かさなければならないプロセスは /etc/rc.conf ファイルを少し変更すれば起動時に実行させられます。

NFS サーバでは /etc/rc.conf ファイルの中で、 以下のオプションが設定されていることを確かめてください。

mountd は NFS サーバが有効になっていれば、 自動的に実行されます。

クライアント側では /etc/rc.conf 内に以下の設定があることを確認してください。

/etc/exports ファイルは NFS サーバがどのファイルシステムをエクスポート (ときどき "共有" と呼ばれます) するのかを指定します。 /etc/exports ファイル中の各行は、 エクスポートするファイルシステム、 およびそのファイルシステムにアクセスできるマシンを指定します。 ファイルシステムにアクセスできるマシンとともに、 アクセスオプションも指定できます。 このファイルで指定できるオプションはたくさんありますが、 ここではほんの少しだけ言及します。 exports(5) マニュアルページを読めば、 他のオプションは簡単にみつけられるでしょう。

いくつか /etc/exports の設定例を示します。

以下の例はファイルシステムのエクスポートの考え方を示しますが、 あなたの環境とネットワーク設定に応じて設定は少し変わるでしょう。 たとえば次の行は /cdrom ディレクトリを、サーバと同じドメイン名か (そのため、いずれもドメイン名がありません)、 /etc/hosts に記述されている三つの例となるマシンに対してエクスポートします。 -ro フラグは共有されるファイルシステムを読み込み専用にします。 このフラグにより、 リモートシステムは共有されたファイルシステムに対して何の変更も行えなくなります。

以下の設定は IP アドレスで指定した 3 つのホストに対して /home をエクスポートします。 この設定はプライベートネットワークで DNS が設定されていない場合に便利でしょう。 内部のホスト名に対して /etc/hosts を設定するという手段もあります。 詳細については hosts(5) を参照してください。 -alldirs フラグはサブディレクトリがマウントポイントとなることを認めます。 言い替えると、これはサブディレクトリをマウントしませんが、 クライアントが要求するか、 または必要とするディレクトリだけをマウントできるようにします。

以下の設定は、サーバとは異なるドメイン名の 2 台のクライアントがアクセスできるように /a をエクスポートします。 -maproot=root フラグは、リモートシステムの root ユーザが、 エクスポートされたファイルシステムに root として書き込むことを許可します。 -maproot=root フラグが無ければ、 リモートマシンの root 権限を持っていても、 共有されたファイルシステム上のファイルを変更することはできないでしょう。

クライアントがエクスポートされたファイルシステムにアクセスするためには、 そうする権限が与えられていなければなりません。 /etc/exports ファイルに クライアントが含まれているかどうか確認してください。

/etc/exports ファイルでは、 それぞれの行が一つのファイルシステムを一つのホストにエクスポートすることを表します。 リモートホストはファイルシステム毎に一度だけ指定することができ、 それに加えて一つのデフォルトエントリを置けます。たとえば /usr が単一のファイルシステムであると仮定します。 次の /etc/exports は無効です。

単一のファイルシステムである /usr は、2 行に渡って、同じホスト client へエクスポートされています。 この場合、正しい書式は次のとおりです。

あるホストにエクスポートされるある 1 つのファイルシステムのプロパティは、 1 行ですべて指定しなければなりません。 クライアントの指定のない行は、単一のホストとして扱われます。 これはファイルシステムをエクスポートできる方法を制限しますが、 多くの場合これは問題になりません。

下記は、 /usr および /exports がローカルファイルシステムである場合の、 有効なエクスポートリストの例です。

変更が有効となるように、 /etc/exports が変更されたら mountd を再起動しなければなりません。 これは mountd プロセスに HUP シグナルを送ることで実行できます。

他には、再起動すれば、FreeBSD はすべてを適切に設定します。 しかしながら、再起動は必須ではありません。 root 権限で以下のコマンドを実行すれば、すべてが起動するでしょう。

NFS サーバでは

NFS クライアントでは

これでリモートのファイルシステムを実際にマウントする準備がすべてできました。 この例では、サーバの名前は server で、 クライアントの名前は client とします。 リモートファイルシステムを一時的にマウントするだけ、 もしくは設定をテストするだけなら、クライアント上で root 権限で以下のコマンドを実行するだけです。

これで、サーバの /home ディレクトリが、クライアントの /mnt にマウントされます。もしすべてが正しく設定されていれば、 クライアントの /mnt に入り、 サーバにあるファイルすべてを見れるはずです。

リモートファイルシステムを起動のたびに自動的にマウントしたいなら、 ファイルシステムを /etc/fstab ファイルに追加してください。 例としてはこのようになります。

fstab(5) マニュアルページに利用可能なオプションがすべて掲載されています。

NFS には実用的な使用法がいくつもあります。 ここで典型的な使用法をいくつか紹介しましょう。

amd(8) (自動マウントデーモン) は、 ファイルシステム内のファイルまたはディレクトリがアクセスされると、 自動的にリモートファイルシステムをマウントします。 また、一定の間アクセスされないファイルシステムは amd によって自動的にアンマウントされます。 amd を使用することは、通常 /etc/fstab 内に記述する恒久的なマウントに対する、 単純な代替案となります。

amd はそれ自身を NFS サーバとして /host および /net ディレクトリに結びつけることによって動作します。 このディレクトリ内のどこかでファイルがアクセスされると、 amd は対応するリモートマウントを調べて、 自動的にそれをマウントします。 /net が、エクスポートされたファイルシステムを IP アドレスで指定してマウントするのに利用される一方で、 /host は、エクスポートされたファイルシステムをリモートホスト名で指定してマウントするのに利用されます。

/host/foobar/usr 内のファイルにアクセスすると、 amd はホスト foobar からエクスポートされた /usr をマウントします。

例のように showmount はエクスポートとして /usr を表示します。 /host/foobar/usr にディレクトリを変更すると、 amd はホスト名 foobar を解決し、お望みのエクスポートをマウントしようと試みます。

amd は /etc/rc.conf 内に次の行を記述すれば、 起動スクリプトによって起動されます。

さらに amd_flags オプションによって amd にフラグをカスタマイズして渡せます。デフォルトでは amd_flags は次のように設定されています。

/etc/amd.map ファイルは、 エクスポートがマウントされるデフォルトオプションを決定します。 /etc/amd.conf ファイルは、 amd のより高度な機能の一部を設定します。

詳細については amd(8) および amd.conf(8) マニュアルページを参照してください。

ISA バス用のイーサネットアダプタの中には性能が悪いため、 ネットワーク、特に NFS で深刻な問題がおきるものがあります。 これは FreeBSD に限ったことではありませんが FreeBSD でも起こり得ます。

この問題は (FreeBSD を使用した) PC がシリコングラフィックス社やサン・マイクロシステムズ社などの高性能なワークステーションにネットワーク接続されている場合に頻繁に起こります。 NFS マウントはうまく動作するでしょう。 また、いくつかの操作もうまく動作するかもしれませんが、 他のシステムに対する要求や応答は続いていても、 突然サーバがクライアントの要求に対して応答しなくなります。これは、 クライアントが FreeBSD か上記のワークステーションであるときにクライアント側に起きる現象です。 多くのシステムでは、いったんこの問題が現われると、 行儀良くクライアントを終了する手段はありません。 NFS がこの状態に陥ってしまうと正常に戻すことはできないため、 多くの場合クライアントをリセットすることが唯一の解決法となります。

"正しい" 解決法は、より高性能のイーサネットアダプタを FreeBSD システムにインストールすることですが、 満足に動作させる簡単な方法があります。 FreeBSD システムが サーバ になるのなら、 クライアントからのマウント時に -w=1024 オプションをつけて下さい。FreeBSD システムが クライアント になるのなら、 NFS ファイルシステムを -r=1024 オプションつきでマウントして下さい。 これらのオプションは自動的にマウントをおこなう場合には クライアントの fstab エントリの 4 番目のフィールドに指定してもよいですし、 手動マウントの場合は mount コマンドの -o パラメータで指定してもよいでしょう。

NFS サーバとクライアントが別々のネットワーク上にあるような場合、 これと間違えやすい他の問題が起きることに注意して下さい。 そのような場合は、ルータが必要な UDP 情報をきちんとルーティングしているかを確かめて下さい。 していなければ、たとえあなたが何をしようと解決できないでしょう。

次の例では fastws は高性能ワークステーションのホスト (インタフェース) 名で、 freebox は低性能のイーサネットアダプタを備えた FreeBSD システムのホスト (インタフェース) 名です。 また /sharedfs はエクスポートされる NFS ファイルシステムであり ( exports(5) を参照) 、 /project はエクスポートされたファイルシステムの、 クライアント上のマウントポイントとなります。 すべての場合において、アプリケーションによっては hard や soft , bg といった追加オプションがふさわしいかもしれないことに注意して下さい。

クライアント側 FreeBSD システム ( freebox ) の /etc/fstab の例は以下のとおりです。

freebox 上で手動で mount コマンドを実行する場合は次のようにして下さい。

サーバ側 FreeBSD システム ( fastws ) の /etc/fstab の例は以下のとおりです。

fastws 上で手動で mount コマンドで実行する場合は次のようにして下さい。

近いうちにどのような 16 ビットのイーサネットアダプタでも、上記の読み出し、 書き込みサイズの制限なしで操作できるようになるでしょう。

失敗が発生したとき何が起きているか関心のある人に、 なぜ回復不可能なのかも含めて説明します。NFS は通常 (より小さいサイズへ分割されるかもしれませんが) 8 K の "ブロック" サイズで動作します。 イーサネットのパケットサイズは最大 1500 バイト程度なので、 上位階層のコードにとっては 1 つのユニットであって、 NFS "ブロック" は複数のイーサネットパケットに分割されるものの、 上位階層のコードにとっては 1 つのユニットであって、 ユニットとして受信され、組み立て直され、 肯定応答 (ACK) されなければなりません。 高性能のワークステーションは次々に NFS ユニットを構成するパケットを、 標準の許す限り間隔を詰めて次々に送り出すことができます。 小さく、容量の低いカードでは、 同じユニットの前のパケットがホストに転送される前に、 後のパケットがそれを踏みつぶしてしまいます。 このため全体としてのユニットは、再構成も肯定応答もできません。 その結果、 ワークステーションはタイムアウトして再送を試みますが、 8 K のユニット全体を再送しようとするので、 このプロセスは際限無く繰り返されてしまいます。

ユニットサイズをイーサネットのパケットサイズの 制限以下に抑えることにより、 受信した完全なイーサネットパケットについて個々に肯定応答を返せることが保証されるので、 デッドロック状態を避けられるようになります。

それでも、高性能なワークステーションが力任せに次々と PC システムにデータを送ったときには踏みつぶしが起きるかもしれません。 しかし、高性能のカードを使っていれば、NFS "ユニット" で必ずそのような踏みつぶしが起きるとは限りません。 踏みつぶしが起きたら、影響を受けたユニットは再送されて、 受信され、組み立てられ、肯定応答される十分な見込みがあります。

FreeBSD の ISDN 実装は、パッシブカードを使用した DSS1/Q.931 (または Euro-ISDN) 標準だけに対応しています。FreeBSD 4.4 からは、ファームウェアが他の信号プロトコルにも対応している 一部のアクティブカードにも対応しました。 その中には、はじめて対応された一次群速度インタフェース (PRI) ISDN カードもあります。

isdn4bsd は IP over raw HDLC または同期 PPP を利用して他の ISDN ルータに接続できるようにします。 PPP では、カーネル PPP を sppp(4) ドライバを修正した isppp ドライバとともに利用するか、または ユーザプロセス ppp(8) を利用するかのどちらかになります。ユーザ ppp(8) を利用すると、二つ以上の ISDN B チャネルを併せて利用できます。 ソフトウェア 300 ボーモデムのような多くのユーティリティとともに、 留守番電話アプリケーションも利用可能です。

FreeBSD が対応している PC ISDN カードの数は増加しており、 ヨーロッパ全域や世界のその他多くの地域でうまく使えることが報告されています。

対応しているパッシブ ISDN カードのほとんどは Infineon (前身は Siemens) の ISAC/HSCX/IPAC ISDN チップセットを備えたカードですが、 Cologne Chip から供給されたチップを備えた ISDN カード (ISA バスのみ)、Winbond W6692 チップを備えた PCI カード、 Tiger300/320/ISAC チップセットを組み合わたカードの一部、 および AVM Fritz!Card PCI V.1.0 や AVM Fritz!Card PnP のようなベンダ独自のチップセットに基づいたカードもあります。

現在のところ、対応しているアクティブカードは AVM B1 (ISA および PCI) BRI カードと AVM T1 PCI PRI カードです。

isdn4bsd についての文書は FreeBSD システム内の /usr/shared/examples/isdn/ ディレクトリまたは isdn4bsd のウェブサイト を参照してください。 そこにはヒントや正誤表や isdn4bsd ハンドブック のような、 さらに多くの文書に対するポインタがあります。

異なる ISDN プロトコルや、現在対応されていない ISDN PC カードに対応することや、その他 isdn4bsd を拡張することに興味があるなら、Hellmuth Michaelis < hm@FreeBSD.org > に連絡してください。

isdn4bsd のインストール、設定、 そしてトラブルシューティングに関して質問があれば freebsd-isdn メーリングリストが利用可能です。

ターミナルアダプタ (TA) は ISDN で、 通常の電話線におけるモデムに相当するものです。

ほとんどの TA は、標準のヘイズ AT コマンドセットを使用しているので、 単にモデムと置き換えて使うことができます。

TA は、基本的にはモデムと同じように動作しますが、 接続方法は異なり、通信速度も古いモデムよりはるかに速くなります。 PPP の設定を、 モデムの場合と同じように行ってください。 特にシリアル速度を使用できる最高速度に設定するのを忘れないでください。

プロバイダへの接続に TA を使用する最大のメリットは、動的 PPP を行えることです。 最近 IP アドレス空間がますます不足してきているため、 ほとんどのプロバイダは、 固定 IP アドレスを割り当てないようになっています。 ほとんどのスタンドアローンルータは、動的 IP アドレス割り当てに対応していません。

TA を使用した場合の機能や接続の安定性は、使用している PPP デーモンに完全に依存します。そのため、FreeBSD で PPP の設定が完了していれば、使用している既存のモデムを ISDN の TA に簡単にアップグレードすることができます。ただし、それまでの PPP のプログラムに問題があった場合、その問題は TA に置き換えてもそのまま残ります。

最高の安定性を求めるのであれば、 ユーザランド PPP ではなく、カーネル PPP を使用してください。

以下の TA は、FreeBSD で動作確認ずみです。

他の TA もほとんどの場合うまく動作するでしょう。TA のメーカーでは、TA がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう努力しているようです。

外部 TA を使う際の最大の問題点は、 モデムの場合と同じく良いシリアルカードが必要であるということです。

シリアルデバイスの詳細と、 非同期シリアルポートと同期シリアルポートの差を理解するには、 FreeBSD シリアルハードウェア チュートリアルを参照してください。

標準の PC シリアルポート (非同期) に接続された TA は 128 Kbs の接続を行っていても、最大通信速度が 115.2 Kbs に制限されてしまいます。128 Kbs の ISDN の性能を最大限に生かすためには TA を同期シリアルカードに接続しなければなりません。

内蔵 TA を購入すれば、 同期/非同期問題を回避できるとは思わないでください。内蔵 TA には、 単に標準 PC シリアルポートのチップが内蔵されているだけです。 内蔵 TA の利点といえば、 シリアルケーブルを買わなくていいということと、 電源コンセントが一つ少なくて済むということくらいでしょう。

同期カードと TA の組合せでも、スタンドアロンのルータと同程度の速度は確保できます。 さらに、386 の FreeBSD マシンと組合せると、 より柔軟な設定が可能です。

同期カード/TA を選ぶか、スタンドアロンルータを選ぶかは、 多分に宗教的な問題です。 メーリングリストでもいくつか議論がありました。議論の全容については、 アーカイブ を検索してください。

ISDN ブリッジあるいはルータは、 FreeBSD あるいは他の OS に特有のものでは皆目ありません。 ルーティングやブリッジング技術に関する詳細は、 ネットワークの参考書をご覧ください。

この節では、 ルータとブリッジのどちらでもあてはまるように記述します。

ローエンド ISDN ルータ/ブリッジ製品は、 価格が下がってきていることもあり、 より広く選択されるようになるでしょう。ISDN ルータは、 ローカルイーサネットネットワークに直接接続し、 自身で他のブリッジ/ルータとの接続を制御する小さな箱です。PPP や他の広く使用されているプロトコルをつかって通信するためのソフトウェアが組み込まれています。

ルータは、完全な同期 ISDN 接続を使用するため、通常の TA と比較してスループットが大幅に向上します。

ISDN ルータ/ブリッジを使用する場合の最大の問題点は、 各メーカーの製品間に相性の問題がまだ存在することです。 インターネットプロバイダとの接続を考えている場合には、 プロバイダと相談することをお勧めします。

事務所の LAN と家庭の LAN の間など、二つの LAN セグメントの間を接続しようとしている場合は、 これはもっともメンテナンスが簡単で、安くあがる解決方法です。 接続の両側の機材を購入するので、 リンクがうまくいくであろうことを保証できます。

たとえば、 家庭のコンピュータや支店のネットワークを本社のネットワークに接続するためには、 以下のような設定が使用できます。

ほとんどのルータ/ブリッジの大きな利点は、 別々の二つのサイトに対して、 同時 にそれぞれ 独立した 二つの PPP 接続が可能であることです。 これは、シリアルポートを 2 つもった特定の (通常は高価な) モデルを除いて、通常の TA では対応していません。 チャネルボンディングや MPP などと混同しないでください。

たとえば、事務所で専用線 ISDN 接続を使用していて、 別の ISDN 回線を購入したくないときには大変便利な機能です。この場合、 事務所のルータは、インターネットに接続するための一つの専用線 B チャネル接続 (64 Kbs) を管理し、 別の B チャネルを他のデータ接続に使用できます。 2 つ目の B チャネルは他の場所とのダイアルイン、 ダイアルアウトに使用したり、バンド幅を増やすために、 1 つ目の B チャネルと動的に結合すること (MPPなど) ができます。

またイーサネットブリッジは、IP パケット以外も中継できます。 IPX/SPX など、使用するすべてのプロトコルを送ることが可能です。

NIS とは Network Information Services の略で Sun Microsystems によって UNIX® の (もともとは SunOS™ の) 集中管理のために開発されました。現在では事実上の業界標準になっており、 主要な UNIX® ライクシステム (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD、等々) はすべてこれをサポートしています。

NIS は元々、イエローページといっていましたが、 商標問題から Sun はその名前を変えました。 古い用語 (および yp) はまだよく見られ、使用されています。

NIS は RPC を使ったクライアント/サーバシステムです。 これを使うと NIS ドメイン内のマシン間で、 共通の設定ファイルを共有することができます。 また NIS を使うことでシステム管理者は最小限の設定データで NIS クライアントを立ち上げることができ、 1 ヶ所から設定データの追加、削除、変更が可能です。

NIS は Windows NT® のドメインシステムに似ています。 内部の実装は似ても似つかないものですが、 基本的な機能を対比することはできます。

NIS サーバの立ち上げや NIS クライアントの設定など、 NIS を FreeBSD に導入するにあたって、 目にするであろう用語や重要なユーザプロセスがいくつかあります。

NIS 環境にあるホストは、 マスターサーバ、スレーブサーバ、クライアントの 3 種類に分類されます。 サーバは、ホストの設定情報の中心的な情報格納庫の役割をします。 マスターサーバは元となる信頼できる情報を保持し、 スレーブサーバは冗長性を確保するためこの情報をミラーします。 そしてクライアントは、サーバから情報の提供を受けて動作します。

この方法を用いることで、数多くのファイルにある情報が共有できます。 よく NIS で共有されるのは、 master.passwd や group , hosts といったファイルです。 クライアント上のプロセスが、 通常ならローカルのファイルにある情報を必要とするときは、 クライアントは代わりに接続している NIS サーバに問い合わせを行います。

この節では NIS 環境の立ち上げ例を取り上げます。

一般にドメイン名さえ知っていれば、 どこにいるリモートユーザでも ypserv(8) に RPC を発行して NIS マップの内容を引き出すことができます。 こういった不正なやりとりを防ぐため、 ypserv(8) には securenets と呼ばれる機能があります。これは、 アクセスを決められたホストだけに制限するのに使える機能です。 ypserv(8) は起動時に /var/yp/securenets ファイルから securenets に関する情報を読み込みます。

ypserv(8) が上記のルールの一つと合致するアドレスからの要求を受け取った場合、 処理は正常に行なわれます。 もしアドレスがルールに合致しなければ、 その要求は無視されて警告メッセージがログに記録されます。 また /var/yp/securenets が存在しない場合、 ypserv はすべてのホストからの接続を受け入れます。

ypserv は Wietse Venema 氏による tcpwrapper パッケージもサポートしています。 そのため /var/yp/securenets の代わりに tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です。

わたしたちの研究室には basie という、 教員専用のマシンがあります。わたしたちはこのマシンを NIS ドメインの外に出したくないのですが、 マスタ NIS サーバの passwd ファイルには教員と学生の両方が載っています。 どうしたらいいでしょう?

当該人物が NIS のデータベースに載っていても、 そのユーザがマシンにログオンできないようにする方法があります。 そうするには -username をクライアントマシンの /etc/master.passwd ファイルの末尾に付け足します。 username はあなたがログインさせたくないと思っているユーザのユーザ名です。 これは vipw で行うべきです。 vipw は /etc/master.passwd への変更をチェックし、編集終了後パスワードデータベースを再構築します。 たとえば、ユーザ bill が basie にログオンするのを防ぎたいなら、以下のようにします。

前節までに見てきた手法は、 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 しかし大きなネットワークでは、 ユーザに触られたくないマシンへログオンを防ぐのを 忘れるでしょう し、 そうでなくとも各マシンを個別に設定して回らなければならず、 集中 管理という NIS の恩恵を失ってしまいます。

NIS の開発者はこの問題を ネットグループ と呼ばれる方法で解決しました。 その目的と意味合いは UNIX® のファイルシステムで使われている一般的なグループと比較できます。 主たる相違は数値 ID が存在しないことと、 ユーザアカウントと別のネットグループを含めたネットグループを定義できることです。

ネットグループは百人/台以上のユーザとマシンを含む、 大きく複雑なネットワークを扱うために開発されました。 あなたがこのような状況を扱わなければならないなら便利なものなのですが、 一方で、この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 この節の残りで使われている例は、この問題を実演しています。

あなたの行なった、 研究室への NIS の導入の成功が上司の目に止ったとしましょう。 あなたの次の仕事は、あなたの NIS ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。

もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら、 あなたはそのシステムにログオンすることが許されていない各ユーザについて - user という 1 行を、各システムの passwd に追加しなければならなくなるでしょう。 もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。 最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが、 遂には連日の業務の間に例の行を追加し 忘れてしまうでしょう 。 結局マーフィーは楽観主義者だったのです。

この状況をネットグループで扱うといくつかの有利な点があります。 各ユーザを別個に扱う必要はなく、 ユーザを一つ以上のネットグループに割り当て、 ネットグループの全メンバのログインを許可したり禁止したりすることができます。 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、 新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで、 それぞれ行なうことができます。 これらの変更は互いに独立なので、 "ユーザとマシンの組合わせをどうするか" は存在しなくなります。 あなたの NIS のセットアップが注意深く計画されていれば、 マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。

最初のステップは NIS マップネットグループの初期化です。 FreeBSD の ypinit(8) はこのマップをデフォルトで作りませんが、 その NIS の実装はそれが作られさえすればそれをサポートするものです。 空のマップを作るには、単に

とタイプして内容を追加していきます。 わたしたちの例では、すくなくとも IT 職員、IT 見習い、一般職員、 インターンの 4 つのネットグループが必要です。

IT_EMP , IT_APP 等はネットグループの名前です。 それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています。 グループの 3 つのフィールドは

各フィールドには、ワイルドカードが使えます。 詳細は netgroup(5) をご覧ください。

新しい NIS マップの有効化と配布は簡単です。

これで新しい 3 つの NIS マップ netgroup , netgroup.byhost , netgroup.byuser ができるはずです。 新しい NIS マップが利用できるか確かめるには ypcat(1) を使います。

最初のコマンドの出力は /var/yp/netgroup の内容に似ているはずです。 2 番目のコマンドはホスト別のネットグループを作っていなければ出力されません。 3 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます。

クライアント側の設定は非常に簡単です。 サーバ war を設定するには、 vipw(8) を実行して以下の行

を

に入れ替えるだけです。

今、ネットグループ IT_EMP で定義されたユーザのデータだけが war のパスワードデータベースに読み込まれ、 そのユーザだけがログインを許されています。

残念ながらこの制限はシェルの ~ の機能や、 ユーザ名や数値の ユーザ ID の変換ルーチンにも影響します。 つまり、 cd ~user はうまく動かず、 ls -l はユーザ名のかわりに数値の ID を表示し find . -user joe -print は "No such user" で失敗します。 これを避けるためには、すべてのユーザのエントリを サーバにログインすることを許さずに 読み込まなければなりません。

これはもう一行を /etc/master.passwd に追加することで実現できます。その行は以下の

+:::::::::/sbin/nologin を含んでおり、 これは "すべてのエントリを読み込むが、読み込まれたエントリのシェルは /sbin/nologin で置き換えられる" ということを意味します。passwd エントリの他のフィールドを /etc/master.passwd の既定値から置き換えることも可能です。

この変更の後では、新しい職員が IT 学科に参加しても NIS マップを一つ書き換えるだけで済みます。 同様にして、あまり重要でないサーバのローカルの /etc/master.passwd のかつての +::::::::: 行を以下のように置き換えます。

この行は、一般のワークステーションでは以下のようになります。

これでしばらく順調に運用していましたが、 数週間後、ポリシに変更がありました。 IT 学科はインターンを雇い始め、IT インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され、 IT 見習いはメインサーバへのログインが許されました。 あなたは新たなネットグループ IT_INTERN を追加して新しい IT インターンたちをそのグループに登録し、 すべてのマシンの設定を変えて回ることにしました。 古い諺にこうあります。 "集中管理における過ちは、大規模な混乱を導く"。

いくつかのネットグループから新たなネットグループを作るという NIS の機能は、このような状況に対処するために利用できます。 その方法の一つは、役割別のネットグループを作ることです。 たとえば、重要なサーバへのログイン制限を定義するために BIGSRV というネットグループを作り あまり重要ではないサーバへは SMALLSRV というネットグループを、そして一般のワークステーション用に USERBOX という第 3 のネットグループを 作ることができます。これらのネットグループの各々は、 各マシンにログインすることを許されたネットグループを含みます。 あなたの NIS マップネットグループの新しいエントリは、 以下のようになるはずです。

このログイン制限の定義法は、 同一の制限を持つマシンのグループを定義できるときには便利なものです。 残念ながらこのようなケースは例外的なものです。 ほとんどの場合、 各マシンに基づくログイン制限の定義機能が必要となるでしょう。

マシンごとのネットグループの定義は、 上述したようなポリシの変更を扱うことができるもうひとつの方法です。 このシナリオでは、各マシンの /etc/master.passwd は "+" で始まる 2 つの行からなります。 最初のものはそのマシンへのログインを許されたアカウントを追加するもので、 2 番目はその他のアカウントを /sbin/nologin をシェルとして追加するものです。 マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良い考えです。 言い換えれば、件の行は次のようになるはずです。

一度、各マシンに対してこの作業を済ませてしまえば、 二度とローカルの /etc/master.passwd を編集する必要がなくなります。 以降のすべての変更は NIS マップの編集で扱うことができます。 以下はこのシナリオに対応するネットグループマップに、 いくつかの便利な定義を追加した例です。

もしユーザアカウントを管理するのにデータベースの類を使っているなら、 データベースのレポートツールからマップの最初の部分を作れるようにするべきです。 そうすれば、新しいユーザは自動的にマシンにアクセスできるでしょう。

最後に使用上の注意を: マシン別のネットグループを使うことが常に賢明というわけではありません。 あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば、 NIS マップのサイズを手頃な範囲に押さえるために、 マシン別のネットグループのかわりに役割別のネットグループを使うべきです。

NIS 環境にある今、 今までとは違ったやり方が必要なことがいくつかあります。

FreeBSD の ypserv は、 NIS v1 クライアントを部分的にサポートしています。 FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、 ほかの実装では、古いシステムとの下位互換性を持たせるため v1 プロトコルをサポートしているものもあります。 そのようなシステムに付いている ypbind デーモンは、 必要がないにもかかわらず NIS v1 のサーバとの結合を成立させようとします (しかも v2 サーバからの応答を受信した後でも、 ブロードキャストをし続けるかも知れません)。 FreeBSD の ypserv は、 クライアントからの通常のリクエストはサポートしていますが、 v1 のマップ転送リクエストはサポートしていないことに注意してください。 つまり FreeBSD の ypserv を、 v1 だけをサポートするような古い NIS サーバと組み合わせて マスターやスレーブサーバとして使うことはできません。 幸いなことに、現在、そのようなサーバが使われていることは ほとんどないでしょう。

複数のサーバが存在し、サーバ自身が NIS クライアントでもあるようなドメインで ypserv が実行される場合には注意が必要です。 一般的に良いとされているのは、 他のサーバと結合をつくるようにブロードキャストさせるのではなく、 サーバをそれ自身に結合させることです。 もし、サーバ同士が依存関係を持っていて、一つのサーバが停止すると、 奇妙なサービス不能状態に陥ることがあります。 その結果、すべてのクライアントはタイムアウトを起こして 他のサーバに結合しようと試みますが、 これにかかる時間はかなり大きく、 サーバ同士がまた互いに結合してしまったりすると、 サービス不能状態はさらに継続することになります。

ypbind に -S オプションフラグを指定して実行することで、 ホストを特定のサーバに結合することが可能です。 NIS サーバを再起動するたびに、これを手動で行いたくないなら、 次の行を /etc/rc.conf に追加すればよいでしょう。

詳細については ypbind(8) を参照してください。

NIS を実装しようする人の誰もがぶつかる問題の一つに、 パスワード形式の互換性があります。 NIS サーバが DES 暗号化パスワード使っている場合には、 同様に DES を使用しているクライアントしか対応できません。 たとえば Solaris™； の NIS クライアントがネットワーク内にある場合、 ほぼ確実に DES 暗号化パスワードを使用しなければならないでしょう。

サーバとクライアントがどのライブラリを使用しているかは、 /etc/login.conf を確認してください。 ホストが DES 暗号パスワードを使用するように設定されている場合、 default クラスには以下のようなエントリが含まれます。

passwd_format 特性について他に利用可能な値は blf および md5 (それぞれ Blowfish および MD5 暗号化パスワード) です。

/etc/login.conf を変更したときは、 ログイン特性データベースも再構築しなければなりません。 これは root 権限で下記のようにコマンドを実行すればできます。

次に、 パスワードが選択した形式で暗号化されることを確実にするために、 さらに /etc/auth.conf 内の crypt_default において、 選択したパスワード形式に高い優先順位がついていることも確認してください。 そうするためには、選択した形式をリストの先頭に置いてください。 たとえば DES 暗号化されたパスワードを使用するときは、 エントリは次のようになります。

FreeBSD 上の各 NIS サーバおよびクライアントにおいて上記の手順に従えば、 ネットワーク内でどのパスワード形式が使用されるかが それらのマシン間で整合されているということを確信できます。 NIS クライアント上で問題があれば、 ここから問題となりそうな部分を探すと良いでしょう。 覚えておいてください: 異種混在ネットワークに NIS サーバを配置したいときには、 DES が最大公約数的な標準となるでしょうから、 すべてのシステムで DES を使用しなければならないかもしれません。

DHCP (Dynamic Host Configuration Protocol) は、 システムをネットワークに接続するだけで、 ネットワークでの通信に必要な情報を入手することができる仕組みです。 FreeBSD では ISC (Internet Software Consortium) による DHCP の実装を使用しています。したがって、 ここでの説明のうち実装によって異なる部分は ISC のもの用になっています。

この節は ISC DHCP システムのクライアント側およびサーバ側の構成要素の両方について説明します。 クライアント側のプログラムである dhclient は FreeBSD のベースシステム内に含まれています。そして、サーバ側の要素は net/isc-dhcp3-server port から利用可能です。下記の説明の他に、 dhclient(8) , dhcp-options(5) および dhclient.conf(5) マニュアルページが役にたつ情報源です。

クライアントとなるマシン上で、 DHCP のクライアントである dhclient を実行すると、 まず設定情報の要求をブロードキャストします。デフォルトでは、 このリクエストには UDP のポート 68 を使用します。 サーバは UDP のポート 67 で応答し、クライアントの IP アドレスと、 ネットマスクやルータ、DNS サーバなどの関連する情報を提供します。 これらの情報のすべては DHCP の "リース" の形で送られ、DHCP サーバ管理者によって決められたある一定の時間内でのみ有効になります。 これによって、ネットワークに存在しなくなったホストの IP アドレスは自動的に回収されることになります。

DHCP クライアントはサーバから非常に多くの情報を取得することができます。 dhcp-options(5) に非常に大きなリストが載っています。

FreeBSD は ISC の DHCP クライアントである dhclient を完全に組み込んでいます。 DHCP クライアントはインストーラと基本システムの両方で提供されています。 ですから DHCP サーバを走らせているネットワーク上ではネットワーク関係の設定についての詳細な知識は必要になりません。 dhclient は、3.2 以降のすべての FreeBSD の配布物に含まれています。

DHCP は sysinstall で対応されており、sysinstall でのネットワークインタフェイス設定の際は、 "このインタフェイスの設定として DHCP を試してみますか? (Do you want to try DHCP configuration of this interface?)" という質問が最初になされます。 これに同意することで dhclient が実行され、 それが成功すればネットワークの設定情報は自動的に取得されます。

システム起動時に DHCP を使ってネットワーク情報を取得するように するには、次の二つを行なう必要があります。

DHCP サーバ dhcpd は、Ports Collection に net/isc-dhcp3-server の一部として収録されています。 この port には ISC DHCP サーバと文書が含まれています。

DHCP のプロトコルは RFC 2131 に完全に記述されています。また dhcp.org にも有用な情報源が用意されています。

FreeBSD はデフォルトでは DNS プロトコルの最も一般的な実装である BIND (Berkeley Internet Name Domain) を使用します。DNS はホスト名を IP アドレスに、そして IP アドレスをホスト名に関連づけるプロトコルです。 たとえば www.FreeBSD.org に対する問い合わせは The FreeBSD Project の ウェブサーバの IP アドレスを受け取るでしょう。 その一方で ftp.FreeBSD.org に対する問い合わせは、 対応する FTP マシンの IP アドレスを返すでしょう。 同様に、その逆のことも可能です。 IP アドレスに対する問い合わせを行うことで、 そのホスト名を解決することができます。 DNS 検索を実行するために、 システム上でネームサーバを動作させる必要はありません。

DNS は、 個々のドメイン情報を格納およびキャッシュした、 権威のあるルートサーバおよび他の小規模なネームサーバによる多少複雑なシステムによって、 インターネット全体にわたって協調して動作します。

この文書は FreeBSD で安定版として利用されている BIND 8.x について説明します。 FreeBSD では BIND 9.x を net/bind9 port からインストールできます。

RFC1034 および RFC1035 は DNS プロトコルを定義しています。

現在のところ BIND は Internet Software Consortium (www.isc.org) によって保守されています。

この文書を理解するには DNS 関連の用語をいくつか理解しなければいけません。

ゾーンの例:

見て分かるように、ホスト名のより詳細な部分はその左側に現れます。 たとえば example.org. は org. より限定的です。同様に org. はルートゾーンより限定的です。 ホスト名の各部分のレイアウトはファイルシステムに非常に似ています。 たとえば /dev はルートの下であることなどです。

ネームサーバは通常二つの形式があります: 権威のあるネームサーバとキャッシュネームサーバです。

権威のあるネームサーバは以下の場合に必要です。

キャッシュネームサーバは以下の場合に必要です。

www.FreeBSD.org に対する問い合わせを発したとき、 リゾルバは大体の場合上流の ISP のネームサーバに問い合わせをして返答を得ます。 ローカルのキャッシュ DNS サーバがあれば、 問い合わせはキャッシュ DNS サーバによって外部に対して一度だけ発せられます。 情報がローカルに蓄えられるので、 追加の問い合わせはいずれもローカルネットワークの外側にまで確認しなくてもよくなります。

FreeBSD では BIND デーモンは自明な理由から named と呼ばれます。

ゾーンファイルは通常 /etc/namedb ディレクトリ内に含まれており、ネームサーバによって処理される DNS ゾーン情報を含んでいます。

BIND はデフォルトでインストールされているので、 すべてを設定することは比較的単純です。

named デーモンが起動時に開始されることを保証するには、 /etc/rc.conf に以下の変更をいれてください。

デーモンを手動で起動するためには (設定をした後で)

キャッシュネームサーバはどのゾーンに対しても権威をもたないネームサーバです。 キャッシュネームサーバは単に自分で問い合わせをし、 後で使えるように問い合わせの結果を覚えておきます。 これを設定するには、ゾーンを何も含まずに、 通常通りネームサーバを設定してください。

セキュリティを強めるために named(8) を非特権ユーザで実行し、 砂場のディレクトリ内に chroot(8) して実行したいと思うかもしれません。 こうすると named デーモンは砂場の外にはまったく手を出すことができません。 named が乗っ取られたとしても、 これによって起こりうる損害が小さくなるでしょう。 FreeBSD にはデフォルトで、そのための bind というユーザとグループがあります。

named は砂場の外 (共有ライブラリ、ログソケットなど) にアクセスできないので、 named を正しく動作させるためにいくつもの段階を経る必要があります。 下記のチェックリストにおいては、砂場のパスは /etc/namedb で、 このディレクトリの内容には何も手を加えていないと仮定します。 root 権限で次のステップを実行してください。

次のステップは named がどのゾーンを読み込むか、 そしてディスク上のどこにゾーンファイルがあるのかを知るために /etc/namedb/etc/named.conf を編集することです。 下記に例をコメントを加えて示します (ここで特にコメントされていない内容については、 砂場の中で動作させない DNS サーバの設定と同じです)。

上記のステップを完了したら、サーバを再起動するか syslogd(8) を再起動し、 named(8) を起動してください。その際、 syslogd_flags および named_flags に新たに指定したオプションが有効になっていることを確かめてください。 これで named を砂場のなかで動作させることができているはずです!

BIND は DNS の最も一般的な実装ではありますが、 常にセキュリティ問題を抱えています。 問題になり得る、また悪用可能なセキュリティホールが時々みつかります。

現在のインターネットおよび FreeBSD のセキュリティ問題について常に最新の情報を得るために CERT および freebsd-security-notifications を購読するとよいでしょう。

BIND/named のマニュアルページ: ndc(8) named(8) named.conf(8)

時間の経過とともに、コンピュータの時計はずれてしまいがちです。 時間が経つと、コンピュータの時計は正確でなくなってゆきます。 NTP (Network Time Protocol) は時計が正確であることを保証する方法の一つです。

インターネットサービスの多くは、 コンピュータの時計が正確であることに依存しているか、 あるいは多くを負っています。 たとえば web サーバ は、 あるファイルがある時刻以降に修正されていたらそのファイルを送ってほしいという要求を受け取るかもしれません。 cron(8) のようなサービスは所定の時間にコマンドを実行します。 時計が正確でない場合、 これらのコマンドは期待したとおりには実行されないかもしれません。

FreeBSD は ntpd(8) NTP サーバを搭載しています。これは、 マシンの時計を合わせるために他の NTP サーバに問い合わせをしたり、 他のマシンに対して時刻を報じるために使用できます。

時刻を同期するために利用する NTP サーバを、 一つ以上見つける必要があります。 ネットワーク管理者、または ISP はこの目的のために NTP サーバを設定しているかもしれません - 本当にそうなのか確かめるためにドキュメントを確認してください。 あなたの近くの NTP サーバを探せる 公にアクセス可能な NTP サーバのリスト があります。 どのサーバを選択するとしても、そのサーバの運営ポリシを理解し、 要求されているなら利用許可を求めることを忘れないでください。

使用しているサーバのうちのどれかが到達不能になるか、 その時計の信頼性が低い場合、無関係の NTP サーバをいくつか選択するとよいでしょう。 ntpd(8) は他のサーバから受け取った応答を賢く利用します - 信頼できないサーバより信頼できるサーバを重視します。

NTP サーバが起動時に実行されることを保証するために、 xntpd_enable="YES" を /etc/rc.conf に加えてください。 ntpd(8) にフラグを追加したい場合は /etc/rc.conf 内の xntpd_flags パラメータを編集してください。

マシンを再起動することなくサーバを実行したいときは、 /etc/rc.conf 内の xntpd_flags で追加されたパラメータをすべて指定して ntpd を実行してください。以下に例を示します。

ntpd(8) プログラムは正しく機能するために、 インターネットへの常時接続を必要としません。しかしながら、 オンデマンドでダイアルアップされるように設定された一時的な接続の場合、 NTP トラフィックがダイアルを引き起こしたり、 接続を維持し続けるようなことを避けるようにした方がよいでしょう。 ユーザ PPP を使用している場合、以下の例のように /etc/ppp/ppp.conf 内で filter ディレクティブが使用できます。

詳細については ppp(8) 内の PACKET FILTERING セクション、および /usr/shared/examples/ppp/ 内の例を参照してください。

NTP サーバに関する文書は HTML 形式で /usr/shared/doc/ntp/ にあります。

一般に natd(8) として知られている FreeBSD ネットワークアドレス変換デーモンは、 raw IP パケットを受信して、 ソースアドレスをローカルマシンに変更し、 そのパケットを外向きの IP パケットの流れに再注入するデーモンです。 natd(8) は、 データが戻ってきたときに、データの本来の場所を判別し、 もともと要求した相手へデータを返すことができるようにソース IP アドレスとポートを変更します。

NAT の最も一般的な使用法は、 一般的にはインターネット接続共有として知られているものを実行することです。

IPv4 の IP 空間が足りなくなりつつあること、および、 ケーブルや DSL のような高速の加入者回線利用者の増加によって、 人々はますますインターネット接続を共有する手段を必要としています。 一つの接続および IP アドレスを通していくつものコンピュータを回線に接続する能力がある natd(8) が合理的な選択になります。

もっともよくあるのは、ユーザが 1 つの IP アドレスでケーブルまたは DSL 回線に接続されたマシンを持っており、 インターネットへのアクセスを LAN 経由でいくつかのコンピュータに提供するのに、 この接続されたコンピュータを使用したいという場合です。

そのためには、インターネットに接続されている FreeBSD マシンはゲートウェイとして動作しなければなりません。 このゲートウェイマシンは 2 つの NIC が必要です (1 つはインターネットルータへ接続するためで、もう 1 つは LAN に接続するためです)。 LAN 上のすべてのマシンはハブまたはスイッチを通して接続されます。

インターネット接続を共有するために、 このような設定がよく使用されています。 LAN 内のマシンの 1 台がインターネットに接続しています。 残りのマシンはその "ゲートウェイ" マシンを通してインターネットにアクセスします。

次のオプションがカーネルコンフィギュレーションファイルに必要です。

さらに、次のオプションを入れてもよいでしょう。

下記の設定を /etc/rc.conf で行わなければなりません。

/etc/rc.conf に前述したオプションを定義すると、起動時に natd -interface fxp0 が実行されます。 これは手動でも実行できます。

LAN にぶら下がっているマシンおよびインタフェースのそれぞれには RFC 1918 で定義されているプライベートネットワーク空間の IP アドレス番号を割り当て、デフォルトゲートウェイアドレスを natd マシンの内側の IP アドレスにすべきです。

たとえば LAN 側のクライアント A および B は IP アドレス 192.168.0.2 および 192.168.0.3 を割り当てられており、 natd マシンの LAN インタフェースは IP アドレス 192.168.0.1 を割り当てられています。 クライアント A および B のデフォルトゲートウェイは natd マシンの 192.168.0.1 に設定されなければなりません。 natd マシンの外部、 またはインターネットインタフェースは natd(8) の動作に際して特別の修正を必要としません。

natd(8) の短所は、インターネットから LAN 内のクライアントにアクセスできないということです。 LAN 内のクライアントは外部に向けて接続を行うことはできますが、 入って来るものを受け取ることができません。これは、LAN クライアントのどれかでインターネットサービスを動かそうとした場合に、 問題になります。これを何とかする単純な方法は natd マシンから LAN クライアントへ、 選択したインターネットポートを転送することです。

たとえばクライアント A で実行されている IRC サーバがあり、 クライアント B 上で実行されている web サーバがあるとします。 これが正しく動作するには、ポート 6667 (IRC) および 80 (web) への接続を対応するマシンに転送しなければなりません。

-redirect_port に適切なオプションを加えて natd(8) に渡さなければなりません。 書式は以下のとおりです。

上記の例では、引数は以下のようにします。

これで適切な tcp ポートが LAN クライアントマシンに転送されます。

-redirect_port 引数は個々のポートを対応させるポート範囲を示すのに使えます。 たとえば tcp 192.168.0.2:2000-3000 2000-3000 は 2000 番から 3000番ポートに受け取られたすべての接続を、 クライアント A 上の 2000 番から 3000 番に転送します。

これらのオプションは natd(8) を直接実行するか、 /etc/rc.conf 内の natd_flags="" オプションで設定するか、 もしくはコンフィグレーションファイルから渡してください。

設定オプションの詳細については natd(8) をご覧ください。

複数の IP アドレスが利用可能ですが、 それらが 1 台のマシン上になければならないときには、 アドレス転送が便利です。 これを用いれば natd(8) は LAN クライアントのそれぞれに外部 IP アドレスを割り当てることができます。 natd(8) は LAN クライアントから外部へ出て行くパケットを適切な外部の IP アドレスで書き直し、 そして特定の IP アドレスに対してやって来るトラフィックのすべてを、 指定された LAN クライアントに転送します。 これは静的 NAT としても知られています。 たとえば 128.1.1.1 , 128.1.1.2 および 128.1.1.3 の IP アドレスが、 natd ゲートウェイマシンに属しているとします。 128.1.1.2 および 128.1.1.3 は LAN クライアントの A および B に転送される一方で、 128.1.1.1 は natd ゲートウェイマシンの外部 IP アドレスとして使用することができます。

-redirect_address の書式は以下のとおりです。

上記の例では引数は以下のようになります。

-redirect_port と同様に、これらの引数は /etc/rc.conf 内の natd_flags="" オプションで設定するか、 コンフィグレーションファイルから渡すことで指定できます。 アドレス転送では、 特定の IP アドレスで受け取られたデータはすべて転送されるので、 port 転送は必要ありません。

natd マシン上の外部 IP アドレスは、 アクティブで外部インタフェースにエイリアスされていなければなりません。 やりかたは rc.conf(5) を参照してください。

inetd(8) は複数のデーモンに対する接続を制御するので、 "インターネットスーパサーバ" と呼ばれます。 ネットワークサービスを提供するプログラムは、 一般的にデーモン呼ばれます。inetd は他のデーモンを管理するサーバを努めます。 接続が inetd によって受け付けられると、 inetd は接続がどのデーモンに対するものか判断して、 そのデーモンを起動し、ソケットを渡します。 inetd を 1 つ実行することにより、 それぞれのデーモンをスタンドアロンモードで実行することに比べ、 全体としてのシステム負荷を減らします。

基本的に、inetd は他のデーモンを起動するために使用されます。しかし、 chargen, auth および daytime のようなささいなプロトコルは直接扱われます。

この節ではコマンドラインオプションおよび設定ファイル /etc/inetd.conf による inetd の設定の基本を説明します。

inetd は /etc/rc.conf の仕組によって初期化されます。 デフォルトでは inetd_enable オプションは "NO" に設定されています。 しかし多くの場合、sysinstall でセキュリティプロファイルを medium に設定することにより、有効化されます。

または

を /etc/rc.conf に置くことで、起動時に inetd を有効または無効にできます。

さらに inetd_flags オプションによって、 いろいろなコマンドラインオプションを inetd に渡すことができます。

inetd 書式

inetd [-d] [-l] [-w] [-W] [-c maximum] [-C rate] [-a address | hostname] [-p filename] [-R rate] [configuration file]

/etc/rc.conf 内の inetd_flags オプションを用いて、これらのオプションを inetd に渡すことができます。デフォルトでは inetd_flags は "-wW" に設定されており、 これは inetd の内部および外部サービスに対して TCP wrapper を有効にします。 初心者ユーザはこれらのパラメータを変更する必要は通常ありませんし、 /etc/rc.conf に入力する必要もありません。

inetd の設定は /etc/inetd.conf ファイルによって制御されます。

/etc/inetd.conf が変更されたときは、 以下のように inetd プロセスに HangUP シグナルを送ることにより、inetd に設定ファイルを再読み込みさせられます。

設定ファイルのそれぞれの行は、 個々のデーモンについての指示になります。 ファイル内のコメントは "#" が先頭につきます。 /etc/inetd.conf の書式は以下のとおりです。

IPv4 を利用する ftpd デーモンのエントリの例です。

インストールの時に選択したセキュリティプロファイルによっては、 多くの inetd のデーモンがデフォルトで有効になっているかもしれません。 あるデーモンが特に必要でない場合には、それを無効にしてください! 問題となっているデーモンが記述されている行の先頭に "#" をおいて inetd にハングアップシグナル を送ってください。 fingerd のようないくつかのデーモンは、 動かそうとすべきではないかもしれません。なぜなら、 それらは攻撃者に対してあまりにも多くの情報を与えるからです。

セキュリティをあまり考慮せず、 接続試行に対してタイムアウトまでの時間が長いか、 タイムアウトしないデーモンもあります。 これは、特定のデーモンに攻撃者がゆっくり接続要求を送ることによって、 利用可能なリソースを飽和させることを可能にします。ある種のデーモンに ip-per-minute および max-child 制限を設けることはよい考えかもしれません。

TCP wrapper はデフォルトで有効です。 inetd から起動されるさまざまなデーモンに対して TCP 制限を設けることの詳細については hosts_access(5) マニュアルページを参照してください。

daytime, time, echo, discard, chargen および auth はすべて inetd が内部的に提供するサービスです。

auth サービスは identity (ident, identd) ネットワークサービスを提供し、 ある程度設定可能です。

詳細については inetd(8) マニュアルを参照してください。

コンピュータ用品店のほとんどでパラレル (クロス) ケーブルを購入することができます。 購入することができないか、 単にケーブルがどのような構造であるか知りたい場合は、 次の表に通常のパラレルプリンタケーブルをもとに作成する方法が示されています。

はじめに、ラップリンクケーブルを入手しなければなりません。 次に、両方のコンピュータのカーネルが lpt(4) ドライバ対応であることを確認してください。

パラレルポートは割り込み駆動ポートでなければなりません。 FreeBSD 4.X では、 以下のような行がカーネルコンフィギュレーションファイル内になければならないでしょう。

FreeBSD 5.X では /boot/device.hints ファイルに以下の行がなければならないでしょう。

それからカーネルコンフィギュレーションファイルに device plip という行があるか、または plip.ko カーネルモジュールが読み込まれていることを確認してください。 どちらの場合でも ifconfig(8) コマンドを直接実行したときに、 パラレルネットワークインタフェースが現れるはずです。 FreeBSD 4.X ではこのようになります。

FreeBSD 5.X ではこのようになります。

両方のコンピュータのパラレルインタフェースにラップリンクケーブルを接続します。

両方のネットワークインタフェースパラメータを root で設定します。 たとえば、FreeBSD 4.X を動作させている host1 と FreeBSD 5.X を動作させている host2 の両ホストを接続したい場合は次のようにします。

次のコマンドで host1 上のインタフェースを設定します。

次のコマンドで host2 上のインタフェースを設定します。

さて、これで接続が確立したはずです。詳細については lp(4) および lpt(4) マニュアルページをご覧ください。

さらに /etc/hosts に両ホストを加えるとよいでしょう。

接続がうまくいっているか確かめるために、 両方のホスト上で互いを ping してください。 たとえば host1 で以下を実行します。

いくつか違うタイプの IPv6 アドレスがあります。 ユニキャスト (Unicast)、エニーキャスト (Anycast) およびマルチキャスト (Multicast) です。

ユニキャストアドレスは周知のアドレスです。 ユニキャストアドレスへ送られたパケットは、 まさにそのアドレスに属するインターフェースに到着します。

エニーキャストアドレスはユニキャストアドレスと構文上判別不可能ですが、 インタフェース群に宛てられています。 エニーキャストアドレスに送られたパケットは (ルータメトリック的に) 最も近いインタフェースに到着します。 エニーキャストアドレスはルータでしか使ってはいけません。

マルチキャストアドレスはインタフェース群を識別します。 マルチキャストアドレスに送られたパケットは、 マルチキャスト群に属するすべてのインタフェースに到着します。

正規の書式では x:x:x:x:x:x:x:x と表されます。それぞれの "x" は 16 ビットの 16 進数です。たとえば FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 となります。

すべてゼロの長い部分文字列がアドレス内によく現れます。 そのため、そのような部分文字列は "::" に短縮することができます。 たとえば、 fe80::1 は正規形の fe80:0000:0000:0000:0000:0000:0000:0001 に対応します。

3 番目の形式は、最後の 32 ビットの部分を "." を分割文字として使う、 なじみ深い IPv4 (10 進) 形式で書くことです。 たとえば 2002::10.0.0.1 は (16 進) 正規形の 2002:0000:0000:0000:0000:0000:0a00:0001 に対応し、同時に 2002::a00:1 と書くこととも等価です。

ここまで来れば、下記を理解することができるでしょう。

fe80::200:21ff:fe03:8e1%rl0 は自動的に設定されたリンクローカルアドレスです。 これは自動設定の一環として、 イーサネット MAC アドレスを変換したものを含んでいます。

IPv6 アドレス構造についての詳細は RFC3513 をご覧ください。

現在、他の IPv6 ホストおよびネットワークに接続するためには 4 つの方法があります。

ここでは、現在もっともよく使われている方法と思われる 6bone へ接続する方法を説明します。

はじめに 6bone サイトをみて、 あなたに最も近い 6bone 接続先を見つけてください。 責任者に連絡すると、少しばかり運がよければ、 接続を設定する方法についての指示を受けられるでしょう。 多くのばあい、これには GRE (gif) トンネルの設定が含まれます。

ここに gif(4) トンネルを設定する典型的な例を示します。

大文字になっている単語を、 上流の 6bone ノードから受け取った情報に置き換えてください。

これでトンネルが確立されます。 ping6(8) を ff02::1%gif0 に送ることによって、トンネルが動作しているか確かめてください。 ping の応答を 2 つ受け取るはずです。

ここまで来ると 6bone アップリンクに経路設定することは比較的簡単でしょう。

この出力はマシンによって異なります。 これで、あなたが www/mozilla のような IPv6 が利用可能なブラウザを持っていれば、 IPv6 サイト www.kame.net にいって踊るカメを見ることができるでしょう。

IPv6 のための新しい DNS レコードが 2 種類あります。

AAAA レコードは簡単に使えます。

上記をプライマリゾーン DNS ファイルに加えて、 もらったばかりの IPv6 アドレスにホスト名を割り当ててください。 あなた自身で DNS ゾーンを管理していない場合は、 DNS プロバイダに頼んでください。 bind の最新バージョン (バージョン 8.3 および 9) は AAAA レコードに対応しています。