訳:
有村 光晴 <arimura@jp.FreeBSD.org>
、
広瀬 昌一 <shou@kt.rim.or.jp>
、
にしか <nishika@cheerful.com>
、
はらだ きろう <kiroh@jp.FreeBSD.org>
、
1998 年 10 月 4 日
9.1. | 「ディスクレスブート (diskless boot)」 に関する情報はどこで得られますか? |
「ディスクレスブート (diskless boot)」 というのは、FreeBSD がネットワーク上で起動し、 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです。 詳細については FreeBSD ハンドブックの「ディスクレスブート」を読んでください。 | |
9.2. | FreeBSD をネットワークのルータ (router) として使用することはできますか? |
インターネット標準やこれまでのよい経験によって指摘されている通り、
FreeBSD は標準ではパケットを転送 (forward) するように設定されていません。
しかし、
rc.conf(5)
の中で次の変数の値を
gateway_enable=YES # Set to YES if this host will be a gateway
このオプションによって
sysctl(8)
の変数
ほとんどの場合、 ルータについての情報を同じネットワークの他の計算機等に知らせるために、 経路制御のためのプロセスを走らせる必要があるでしょう。 FreeBSD には BSD の標準経路制御デーモンである routed(8) が付属していますが、より複雑な状況に対処するためには GaTeD(http://www.gated.org/ から入手可能) を使用することもできます。 3_5Alpha7 において FreeBSD がサポートされています。 注意してほしいのは、FreeBSD をこのようにして使用している場合でも、 ルータに関するインターネット標準の必要条件を完全には満たしていない ということです。しかし、普通に使用する場合にはほとんど問題ありません。 | |
9.3. | Win95 の走っているマシンを、FreeBSD 経由でインターネットに接続できますか? |
通常、この質問が出てくる状況は自宅に二台の PC があり、一台では FreeBSD が、もう一台では Win95 が走っているような場合です。 ここでやろうとしていう事は FreeBSD の走っている計算機をインターネット に接続し、Win95 の走っているマシンからは FreeBSD の走っているマシンを経由して接続を行なう事です。 これは二つ前の質問の特別な場合に相当します。 …で、答えは「はい」です。
FreeBSD 3.x のユーザモード ppp には 設定に関するさらに詳しい情報は、 Steve Sims 氏による Pedantic PPP Primer にあります。 カーネルモード ppp を利用する場合や、
インターネットとのイーサネット接続が利用できる場合は、
| |
9.4. | ISC からリリースされている BIND の最新版はコンパイルできないんでしょうか? |
BIND の配布物と FreeBSD とでは
| |
9.5. | FreeBSD で SLIP と PPP は使えますか? |
使えます。FreeBSD を用いて他のサイトに接続する場合には、 slattach(8)、sliplogin(8)、ppp(8) そして pppd(8) のマニュアルページをご覧ください。 ppp(8) と pppd(8) は、 PPP のサーバ、クライアント両方の機能を持っています。 その一方で、sliplogin(8) は SLIP のサーバ専用で、 slattach(8) は SLIP のクライアント専用です。 これらを使うためのさらなる情報については、ハンドブックの PPP と SLIP の章をご覧ください。 「シェルアカウント」を通じてのみインターネットへアクセス可能な場合、 slirp package みたいなものが欲しくなるかもしれませんね。 これを使えば、ローカルマシンから直接 ftp や http のようなサービスに (限定的ではありますが) アクセスすることができます。 | |
9.6. | FreeBSD は NAT か IP マスカレードをサポートしていますか? |
ローカルなサブネット (一台以上のローカルマシン) を持っているが、
インターネットプロバイダから 1 つしか IP
アドレスの割り当てを受けていない場合 (または IP
アドレスを動的に割り当てられている場合でも)、
natd(8)
プログラムを使いたくなるかもしれませんね。
ppp(8)
も同様の機能を持っており、 | |
9.7. |
|
Berkeley UNIX におけるネットワークの構成において、
ネットワークのインタフェースはカーネルコードからのみ、
直接あつかうことができます。
より詳しく知りたい場合は、
| |
9.8. | Ethernet アドレスのエイリアス (alias) はどのようにして設定できますか? |
ifconfig(8)
のコマンドラインに
# ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff | |
9.9. | 3C503 で他のネットワークポートを使用するにはどのようにすればよいですか? |
他のポートを使用したい場合には、
ifconfig(8)
のコマンドラインにパラメータを追加しなければなりません。
デフォルトでは
| |
9.10. | FreeBSD との間で NFS がうまくできません。 |
PC 用のネットワークカードによっては、 NFS のような、 ネットワークを酷使するアプリケーションにおいて問題を起こすものがあります。 この点に関しては FreeBSD ハンドブックの「NFS」を参照してください。 | |
9.11. | 何故 Linux のディスクを NFS マウントできないのでしょうか? |
Linux の NFS のコードには、 許可されたポートからのリクエストしか受けつけないものがあります。 以下を試してみてください。 # mount -o -P linuxbox:/blah /mnt | |
9.12. | 何故 Sun のディスクを NFS マウントできないのでしょうか? |
SunOS 4.X が走っている Sun Workstation は、 許可されたポートからのマウント要求しか受けつけません。 以下を試してみてください。 # mount -o -P sunbox:/blah /mnt | |
9.13. |
|
最も良くある問題は、exports(5) のマニュアルページの以下の部分を正しく理解していないことです。
さて、ありがちな間違いをご覧になればはっきりするでしょう。
もし /usr/src client
/usr/ports client 一つのファイルシステムに対して属性の指定が二行になっています。
/usr/src /usr/ports client もう一度マニュアルページの文章を確認すると、 あるホストにエクスポートされる各ファイルシステムの属性は すべて一行に書かれていなければならない、となっています (ここでは、「アクセス可能なすべてのホスト」 も一つの独立したホストとして扱われることに注意してください)。 このことは、ファイルシステムをエクスポートするために 奇妙な書式を使わなければならない原因にもなっているのですが、 ほとんどの人にとって、これは問題にはならないでしょう。 次に示すのは、有効な exports リストの例です。
ここでは、 # Export src and ports to client01 and client02, but only
# client01 has root privileges on it
/usr/src /usr/ports -maproot=0 client01
/usr/src /usr/ports client02
# The "client" machines have root and can mount anywhere
# up /exports. The world can mount /exports/obj read-only
/exports -alldirs -maproot=0 client01 client02
/exports/obj -ro | |
9.14. | PPP で NeXTStep に接続する際に問題があるのですが。 |
tcp_extensions=NO Xylogic の Annex も同様の問題がありますので、 Annex 経由で PPP を行なう場合にもこの変更を行ってください。 | |
9.15. | IP マルチキャスト (multicast) を有効にするには? |
FreeBSD 2.0 かそれ以降では、
標準の状態で完全にマルチキャストに対応しています。
現在使用している計算機をマルチキャストのルータ (router) として使用するには、
MBONE
用のツールは ports 内の専用のカテゴリー mbone
にあります。
詳しい情報は Mbone Information Web にあります。 | |
9.16. | DEC の PCI チップセットを用いているネットワークカードには、 どのような物がありますか? |
Glen Foster 氏による一覧に、 最近の製品を追加したものを以下に示します。 Vendor Model
----------------------------------------------
ASUS PCI-L101-TB
Accton ENI1203
Cogent EM960PCI
Compex ENET32-PCI
D-Link DE-530
Dayna DP1203, DP2100
DEC DE435, DE450
Danpex EN-9400P3
JCIS Condor JC1260
Linksys EtherPCI
Mylex LNP101
SMC EtherPower 10/100 (Model 9332)
SMC EtherPower (Model 8432)
TopWare TE-3500P
Znyx (2.2.X) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
(3.X) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442,
ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) | |
9.17. | 何故自分のサイトのホストに対して FQDN を使用する必要があるのですか? |
実際にはそのホストは別のドメインにあるのではないですか。
たとえば、foo.bar.edu
というドメインの中から、
伝統的に、BSD の
BIND のリゾルバ (resolver) ではこのような事は可能でしたが、
FreeBSD に入っている
bind (named(8) 参照)
の現在のバージョンでは、
自分以外のドメインに対して FQDN
でない別名を自動的につけてくれるような事はありません。
したがって
これは、
domain foo.bar.edu
と書いてある行を、
| |
9.18. | すべてのネットワークの操作に対して
|
もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる
ようにするには、 # ipfw add 65534 allow all from any to any
FreeBSD のファイアウォールの設定についての情報は FreeBSD ハンドブックの「ファイアウォール」にあります。 | |
9.19. | IPFW のオーバヘッドはどのくらいでしょうか? |
この答えは、 使っているルールセットとプロセッサのスピードによってほとんど決まります。 イーサネットに対して少しのルールセットだけを使っている場合には、 ほとんどその影響は無視できる程度です。 実際の測定値を見ないと満足できない方々のために、 実際の測定結果をお見せしましょう。
次の測定は 486-66 (訳注: Intel 社製 CPU i486、66MHz のこと) 上で
2.2.5-STABLE を使用して行なわれました。
IPFW は変更が加えられて、 それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが行なわれました。 ひとつ目のルールセットは最悪のケースを見るために ipfw add deny tcp from any to any 55555 というルールを繰り返したものです。 IPFW のパケットチェックルーチンは、 パケットが (ポート番号のせいで) このルールにマッチしないことがわかるまでに、 何度も実行されます。そのため、これは最悪のケースを示します。 このルールを 999 個繰り返し並べた後に allow ip from any to any が書かれています。 2つ目のルールセットは、なるべく早くチェックが終了するように書かれたものです。 ipfw add deny ip from 1.2.3.4 to 1.2.3.4 このルールでは、発信元の IP アドレスがマッチしないので、 チェックはすぐに終了します。上のルールセットとおなじように、 1000 個目のルールは allow ip from any to any です。 1 つ目のルールセットの場合、 パケットあたりのオーバヘッドはおよそ 2.703ms/packet、 これはだいたい 1 つのルールあたり 2.7 マイクロ秒かかっていることになります。 したがって、 このルールにおけるパケット処理時間の理論的な限界は、 毎秒約 370 パケットです。 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると、 バンド幅の利用効率は 55.5% が限界となることになります。 2 つ目のルールセットでは、それぞれのパケットがおよそ 1.172msで処理されていますので、 だいたい 1 つのルールあたり 1.2 マイクロ秒かかっていることになります。 パケット処理時間の理論的な限界は、 毎秒約 853 パケットとなりますので、 10Mbps Ethernet のバンド幅を使い切ることができます。 このテストでのルール数は多過ぎるため、 実際に使用する際の結果を反映している訳ではありません。 これらは上に示した数値を出すためだけに用いられたものです。 効率の良いルールセットを作るためには、 次のような事を考えておけばよいでしょう。
| |
9.20. | ipfw(8) 「fwd」 ルールを使って他のマシンにサービスをリダイレクトしたのですが、 うまく動いてくれないようです。どうしてなんでしょう? |
おそらく、あなたが期待している動作とは、 単なるパケット転送ではなくネットワークアドレス変換 (NAT) と呼ばれるものだからでしょう。 「fwd」 ルールは文字どおり、本当に転送しか行ないません。 パケットの中身については一切手を加えないのです。 そのため、次のようなルールを設定したとすると、 01000 fwd 10.0.0.1 from any to foo 21 宛先アドレスに サービスの転送をきちんと動作させる方法については、 サービスのリダイレクトに関する FAQ や natd(8) のマニュアルページ、 Ports Collection にいくつか含まれているポート転送ユーティリティなどをご覧になると良いでしょう。 | |
9.21. | サービス要求を他のマシンにリダイレクトするには? |
FTP などのサービスのリクエストは、「socket」
パッケージを利用してリダイレクトできます。
「socket」
パッケージは ports の
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
ここで
| |
9.22. | バンド幅の管理を行なえるツールはどこで手に入れられますか? |
FreeBSD 用のバンド幅管理ツールには、無料で手に入れられる ALTQ と、 Emerging Technologies から入手できる Bandwidth Manager という市販のものの 2 種類があります。 | |
9.23. | BIND ( |
おそらく違います。FreeBSD 3.0 以降では、外向けの問合せに
ランダムな大きな番号のポートを用いるバージョンの BIND を
用いています。ファイアウォールを通すため、またはあなたの
気分で、外向きの問合せを 53 番ポートから行いたいならば、
options {
query-source address * port 53;
}; 更に限定したければ、 それはともかく、おめでとうごさいます。
| |
9.24. | なぜ 「 |
バークレーパケットフィルタ (bpf(4)) ドライバは、それを利用するプログラムを実行する前に有効にしておく必要があります。 カーネルコンフィグファイルに、次のように追加してカーネルの再構築をしてください。 pseudo-device bpfilter # Berkeley Packet Filter
そして再起動してから、次にデバイスノードを作成する必要があります。
これは、次のように入力し、 # sh MAKEDEV bpf0 デバイスノードの作成の詳細は、 FreeBSD ハンドブックの「デバイスノード」を参照してください。 | |
9.25. | Linux の smbmount のように、 ネットワーク上の Windows マシンのディスクをマウントするにはどうしたら良いのでしょう? |
Ports Collection に含まれる sharity light パッケージを使ってください、 | |
9.26. | 「icmp-response bandwidth limit 300/200 pps」 というメッセージがログファイルに現れるのですが、 どういうことでしょう? |
これは、カーネル自身から「ICMP や TCP のリセット (RST) 応答を、妥当な数よりも多く送っている」ということを、 あなたに伝えるメッセージです。 ICMP 応答は良く、使われていない UDP ポートに接続しようとした結果として生成されます。 また、TCP リセットはオープンされていない TCP ポートに接続しようとした結果として生成されます。 その他、これらのメッセージが表示される原因となる状況として、 以下のようなものがあります。
メッセージ中の最初の数字は、
上限を設定しなかった場合にカーネルが送っていたであろうパケットの数を示し、
二番目の数字は、パケット数の上限値を示します。
この上限値は
# sysctl -w net.inet.icmp.icmplim=300 カーネルの応答制限を無効にせず、
ログファイル中のメッセージだけを抑制したい場合、
# sysctl -w net.inet.icmp.icmplim_output=0 最後に、もし応答制限を無効にしたい場合は、
|
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、
ドキュメント を読んだ上で
<questions@FreeBSD.org> まで (英語で) 連絡してください。
本文書に関する質問については、
<doc@FreeBSD.org> まで電子メールを (英語で) 送ってください。