訳: &a.arimura; &a.shou; &a.nishika; &a.kiroh . 4 October 1998. ``diskless boot'' に関する情報はどこで得られますか?

``diskless boot'' というのは, FreeBSD がネットワーク上で起動し, 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです. 詳細については を読んでください. FreeBSD をネットワークの router として使用することはできますか?

インターネット標準やこれまでのよい経験によって指摘されている通り, FreeBSD は標準ではパケットを forward するように設定されていません. しかし, の中で次の変数の値を gateway_enable=YES # Set to YES if this host will be a gateway

このオプションによって の変数 ほとんどの場合, router についての情報を同じネットワーク の他の計算機等に知らせるために, 経路制御のためのの process を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン である が付属していますが, より複雑な状況に対処するためには 注意してほしいのは, FreeBSD をこのようにして使用している場合でも, router に関するインターネット標準の必要条件を完全には満たしていない ということです. しかし, 普通に使用する場合にはほとんど問題ありません. Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか?

通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では FreeBSD が, もう一台では Win95 が走っているような場合です. ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを 経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します.

FreeBSDをとして設定する方法については, 役に立つ文書があります.

や のような また, に関する節も参照してください. ISC からリリースされている BIND の最新版は compile できないんでしょうか?

BIND の配布物と FreeBSD とでは ``compat/include/sys/cdefs.h を削除してください. FreeBSD で SLIP と PPP は使えますか?

使えます. FreeBSD を用いて他のサイトに接続する場合には, , , そして のマニュアルページを見てください. は SLIP のサーバ専用で, は SLIP のクライアント専用です.

これらのプログラムの解説が, の以下のセクションにあります.

「シェルアカウント」を通じてのみインターネットへアクセス可能な場合, package みたいなものが欲しくなるかもしれませんね. これを使えば, ローカルマシンから直接 ftp や http のようなサービスに (限定的ではありますが) アクセスすることができます. FreeBSD は NAT か IP マスカレードをサポートしていますか?

ローカルなサブネット (一台以上のローカルマシン) を持っているが, インターネットプロバイダから 1 つしか IP アドレスの割り当てを 受けていない場合 (または IP アドレスを動的に割り当てられている場合でも), プログラムを使いたくなるかもしれませんね. も, 同様の機能を持っており, が使われます.

まず のマニュアルと, を読んでみましょう. 次に, set log Phase Chat Connect Carrier lcp ipcp ccp command

という命令を /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください. その際, に !ppp *.* /var/log/ppp.log

と書かれた行が含まれているか, また, /var/log/ppp.log が存在しているかどうか確かめておいてください. さて, これで 何が起きているのか突き止めるために, ログファイルからたくさんの 情報を得られるようになりました. ログに訳の分らない部分があっても 心配ご無用. あなたが助けを求めた誰かにとっては, その部分が 意味をなす場合があるのです.

訳注: ログの取得に syslog を使用するようになったのは 2.2.5 以降からです.

使用中の ppp のバージョンで "set log" 命令を解釈しない場合は, をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます. ppp を実行するとハングします

ホスト名の解決がうまくいっていないのでしょう. まず, リゾルバが /etc/hostsを参照するように, /etc/host.conf の最初の行に host と書き込んでください. つぎに, /etc/hostsに使用しているマシンのエントリを 書き加えます. ローカルでネットワークを使用していない場合は, localhost の行を以下のように変更してください: 127.0.0.1 foo.bar.com foo localhost 使用しているホストのエントリを追加してもかまいません. 詳細は関連するマンページを参照してください. ppp が -auto モードでダイアルしてくれない

まず最初に, デフォルトルートが確立しているかどうかチェックして ください. を実行すると, 以下のような情報が表示されるはずです. Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0

これはあなたがハンドブックやマニュアル, ppp.conf.sample の中で 出てくるアドレスを使用していると仮定した場合の例です. デフォルトルートが確立していない場合, ppp.conf の中の が走っている可能性があります. FreeBSD 2.2.5 より前の バージョンに付属していた add 0 0 HISADDR

と書かれた行を以下のように修正してください. add 0 0 10.0.0.2

netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ, (2.2.2 より前のリリースでは /etc/sysconfig と呼ばれていました) の中でデフォルトの ルータを誤って設定し, ppp.conf から delete ALL

の行をうっかり消してしまった可能性があります. この場合は, ハンドブックの の項を読み直してください. "No route to host" とはどういう意味ですか?

このエラーは通常, /etc/ppp/ppp.linkup に以下のような セクションが無い場合に起こります. MYADDR: delete ALL add 0 0 HISADDR

これは動的 IP アドレスを使用している場合, またはゲートウェイの アドレスを知らない場合にのみ必要な設定です. インタラクティブモード を使用している場合, delete ALL add 0 0 HISADDR

詳しい情報については, ハンドブックの の項を参照してください. 3 分ほど経つと接続が切れてしまう

ppp のタイムアウトは デフォルトでは 3 分です. これは set timeout NNN

という命令によって調整することができます. ppp.conf に入れることも, インタラクティブモードでプロンプトから入力することも できます. ソケットを用いる か を使用し, 訳注 pppctl は 2.2.5R からです.

詳しい情報は のマニュアルを参照してください. 負荷が高いと接続が切れてしまう

Link Quality Reporting (LQR) の設定を行っている場合, マシンと接続先の間で非常にたくさんの LQR パケットが失われている 可能性があります. 結果として ppp は回線の具合いが悪いと考え, 回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で 無効です. LQR は以下の命令で無効にすることができます. disable lqr 接続がランダムに切れてしまう

時々, ノイズの多い回線, あるいは待ち機能付きの回線では, モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう ことがあります.

大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか 設定で決めることができます. 例えば USR Sportster では, S10 レジスタ の値を 10 倍した秒数がその値になります. この場合, モデムをもっと のんびり屋さんにするには, dial 行に次のような文字列を加えると 良いでしょう. set dial "...... ATS10=10 OK ......"

詳しくはお使いのモデムのマニュアルをご覧ください. 接続が不規則にハングアップしてしまう

たくさんの人が, 原因不明のハングアップを経験しています. 検証のために必要なのは, まずどちら側のリンクでそれが起こっているか, ということです.

外部接続型モデムを利用しているなら, 単に 問題が回線のどちら側かにあることが分かったら, つぎの二つの可能性が考えられるでしょう. 回線の向こう側での反応がない

これに対処できることはほとんどありません. 大部分の ISP は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう. まず最初に, こちら側の圧縮機能を全て無効にしてみて下さい. それには, 設定ファイルをつぎのようにします. disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

そして再接続し, 変更前と同じように通信できることを確認します. もしこれによって状況が改善されるか, 完全に解決したら, (上の設定のうち)どの設定で状況が変化したのかを, 色々な組合せで試してみて下さい. これは, ISP に問い合わせを行なうときの有効な情報となります(ただし, あなたが Microsoft 社製品以外のものを利用していることも 明らかにしてしまいますが).

ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして, 接続がハングアップするまで待って下さい. この作業は, 非常に多くのディスク空間を消費するかも知れません. 興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです. それは通常 ASCII データで, 問題点の詳細(``Memory fault, core dump''など)が 記載されている可能性があります.

回線の向こう側で通信ログを監視することは可能なはずですので, ハングアップが発生した時, ISP の対応が好意的ならば どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません. まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません. ppp がハングアップする

ベストな方法は, スタックトレースの結果は, まで送って下さい. Login OK! のメッセージが出た後, 何も起こらない

2.2.5 より前のリリースの FreeBSD では, はリンクが確立した後, 接続先が Line Control Protocol (LCP) を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを 自分からは起こさず, クライアントが起こすのを待っています. set openmode active

でもまだ "magic is the same" というエラーが出る

時折, 接続直後のログに "magic is the same" というメッセージが あらわれることがあります. このメッセージがあらわれても何も起きない 場合もありますし, どちらかの側が接続を切ってしまう場合もあります. ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと link が上がっている状態であっても, ppp が最終的にあきらめてしまい 接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた という通知が log ファイルに残ると思います.

これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで getty が生きていて, ppp がログインスクリプトか, ログイン直後に 起動されたプログラムから実行されている場合に起こります. slirp を使用 している場合に同様の症状が見られたという報告もあります. 原因は getty の終了されるまでと, ppp が実行され, クライアント側の ppp が Line Control Protocol (LCP) を送り始めるまでのタイミングにあります. サーバ側のシリアルポートで ECHO が有効なままになっているので, クライアント側の ppp にパケットが「反射」してしまうのです.

LCP ネゴジェーションの一部として, リンクの両サイドで magic number を定めて, 「反射」が起きていないかどうか確かめる作業があります. 規約では, 接続相手がこちらと同じ magic number を提示してきたら, NAK を送って新しい magic number を選択しなければならないと 定めています. この作業の間, サーバのシリアルポートの ECHO がずっと 有効になったままなので, クライアント側の ppp は LCP パケットを送り, パケットが反射して全く同じ magic number が送られてくるのを見つけ, それに対して NAK を送るのです. 一方 NAK 自体も (これは ppp が magic number を変更しなければいけないことを意味しています) 反射して くるので, 結果として magic number が数えきれないほど変更され, その全てがサーバの tty バッファの中に積み重なることになるのです. サーバでスタートした ppp はとすぐ magic number であふれかえってしまい, LCP のネゴジェーションを十分に行ったものと判断して, さっさと接続を 切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので 満足しますが, それもサーバが接続を切ったことを知るまでです.

この事態は, 以下の行を ppp.conf の中に書いて, 相手がネゴシェー ションを開始できるようにする事によって回避できます. set openmode passive

これで ppp はサーバが LCP ネゴジェーションを起こすのを待つように なります. しかし, 自分からは決してネゴジェーションを起こさないサーバ もあるかもしれません. もしこの状況に遭遇した場合には, 次のようにして ください. set openmode active 3

これによって ppp は 3 秒間 passive モードを続けた後で LCP リク エストを送り始めます. この間に相手がリクエストを送り始めた場合には 3 秒間待たずにこのリクエストに即座に応答します. 接続が切れるまでLCPのnegotiationが続く.

これが, 片方のこれを回避する最も良い方法は, 片方を set openmode passive というコマンドでできます. このオプションは気を付けて使わないといけ ません. さらに set stopped N というコマンドを追加して, set openmode active N というコマンド(ここで, ppp が接続直後に固まってしまう

2.2.5 より前のバージョンの FreeBSD では, disable pred1 ppp の内部でシェルを起動しようとすると固まってしまう

このような場合は, 代わりに ヌルモデムケーブルを使用しているとき, ppp が終了しない

ヌルモデムケーブルを使用して直接接続している場合, enable lqr

こうすると, 接続先がネゴシエーションを行う場合, デフォルトで LQR の使用を受け入れるようになります. ppp を -auto モードで動かすと, 勝手にダイアルすることがある

原因を突き止めるためには, 以下の命令を使用してください. set log +tcp/ip

これで接続を通過する全てのトラヒックをログに残すことができるように なりました. 次に突然回線がつながったときのログのタイムスタンプを たどれば, 原因を突き止めることができるはずです.

原因がわかったら, 次に, このような状況ではダイヤルが起こらないように しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために 起こります. DNS による名前の解決によって, 接続が行われるのを防止する には, 次のような手段を用います (これは set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0

これはデマンドダイヤル機能に問題を生じさせるため, 常に適切であるとはかぎりません. ほとんどのプログラムは 他のネットワーク関連の処理をおこなう前に DNS への問い合わせ が必要になります.

DNS の場合は, 何が実際にホスト名を検索しようとしているのかを 突き止めるべきでしょう. 大抵の場合は, が犯人です. 設定ファイルで sendmail が DNS に問い合わせないようになっているか確認すべきです. 自分用の設定ファイルを作成するための詳しい方法は の節をご覧ください. または, define(`confDELIVERY_MODE', `d')dnl

この行を追加すると, sendmailはメールキューを処理する (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m'' というオプションを付けて起動されます) までか, または (多分ppp.linkupというファイルの中で) ``sendmail -q''というコマンドが実行されるまで, 全てのメールを キューに溜めるようになります．

訳注 ``sendmail -q'' はその時点のメールキューの内容を処理して 終了します． CCP エラーとはどういう意味ですか

ログファイル中の以下のエラーは, CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6)

ネゴジェーションにおいて ppp は Predictor1 圧縮を用いるべく主張したが, 接続先は圧縮を使用しないことを主張した場合に起こります. このメッセージ には何の害もありませんが, 出るのが嫌なら, 以下の命令を用いて こちら側でも Predictor1 圧縮を無効にすることで対応できます. disable pred1 ファイル転送の途中で, ppp が IO エラーを出して固まってしまう

FreeBSD 2.2.2 以前のバージョンの tun ドライバには, tun インタフェース の MTU のサイズより大きなパケットを受け取ることができないというバグが ありました. MTU のサイズより大きなパケットを受け付けると IO エラーが 起こり, syslogd 経由で記録されるのです.

ppp の仕様では, LCP のネゴジェーションを行う場合を含む どのような場合でも最低 1500 オクテットの Maximum Receive Unit (MRU) を受け入れる必要があります. ですから, MTU を 1500 以下に設定した場合でも, ISP はそれに関係なく 1500 の大きさのパケットを送ってくるでしょう. そしてこのイケてない 機能にぶちあたって, リンクが固まるのを目にすることになるのです.

FreeBSD 2.2.2 以前のバージョンでは, MTU を決して 1500 より小さく しないことで, この問題を回避することができます. どうして ppp は接続速度をログに残さないんでしょう?

モデムとの「やり取り」全ての行をログに残すには, 以下のようにして接続速度のログの有効化を行ってください: set log +connect

これは に最後にくることが要求されている "expect" という文字列がくるま でのすべてのものをログに記録させます.

接続速度はログにとりたいけれど, PAP や CHAP を使っている (その結果, dial スクリプト中の CONNECT 以降に全く「やりとり」 を行わない - "set login" スクリプトには何も書かない) のであれ ば, ppp に "expect" を含んだ CONNECT 行全てがくるまで待たせる ようにしないといけません, 以下のようになります: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

ここで, CONNECT を受信してから, 何も送らず, linefeed を 待っています, 私のchatスクリプトでは`\'という文字をPPPが解釈して くれません

PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような 特別なescape sequence (man pageを見てください)を見付けるために もう1回parseを行います. このようにparseは2回繰り返されま すので, 正しい回数だけescapeを行わないといけません.

モデムにたとえば``\''のような文字を送りたい場合には, 次のように する必要があります: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

実際にモデムに送られる文字列は次のようになります: ATZ OK AT\X OK

他の例ですと set phone 1234567 set dial "\"\" ATZ OK ATDT\\T"

は次のようになります: ATZ OK ATDT1234567 ppp が segmentation fault になるのですが,

ppp (や他のプログラム) はけして core を吐いてはいけません. ppp は 実効 uid が 0 で動いていますので, オペレーティングシステム は ppp を終了させる前にディスクに core イメージを書き込みません. しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因 となるようなシグナルによって $ tar xfz ppp-*.src.tar.gz $ cd ppp*/ppp $ echo STRIP= >>Makefile $ echo CFLAGS+=-g >>Makefile $ make clean all $ su # make install # chmod 555 /usr/sbin/ppp

これで debug 可能なバージョンの ppp がインストールされます. root で ppp を実行し, 全ての特権が無効になっているようにする必要 があるでしょう. ppp を実行する時には, current directory が make した directory であるようにしてください.

これで, ppp がセグメンテーション例外を受け取ったときには ppp.core という名前の core ファイルを吐くようになります. core が 吐かれたら次のようにしてください: $ su # gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l .....

質問する際には, これら全ての情報を提供して, 問題点の分析ができ るようにしてください.

gdb の使い方に慣れている場合には, 実際に dump の原因となった 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. auto mode でダイアルをするようなプロセスが接続されない

これは を呼び出した時, tun インターフェイスの IP アドレスが, ソケットの終端に割り当てられてしまうという問題です. カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます. そして この問題に対処する理論的な方法がいくつかあります. もし可能なら, 相手が再度, 同じ IP アドレスを割り当ててくれることが一番です 我々の側から対処できる最も簡単な方法は, tun インターフェイスの IP アドレスを固定する事です. またそのかわりに, 外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP アドレスから, 交渉によって得られた IP アドレスに, 適宜書きかえる事によっても対処できます. こ これは, 基本的に および, ppp の もう 1 つの(おそらく最も信頼できる)方法は, bind された 全てのソケットの IP アドレスを, 異なるものに変更できるシステムコールを実装することです. 3 つ目の方法は, IP アドレスを指定しないでインターフェイスを利用できるようにすることです. 外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで, 255.255.255.255 という IP アドレス が与えられます. これによって. ソケットは常に bind することができます. 何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか?

訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます. をご覧ください.

libalias を使っている時にゲームなどの類のものが動作しない理由は, 外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な) UDP パケットを送信しようとしているからです. 内側のマシンにこれらのパケットを送るべきかについて, packet alias ソフトウェアは関知しません.

うまく動かすためには, 実行中のものが問題の発生している ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化 (``set log +tcp/ip'') してください.

行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを 通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に, そのパケットは破棄されるでしょう (それが問題なのです). これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを 停止してください. これを数回繰り返して port 番号が常に同じであるかを確認してみてください. 同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると, そのソフトウェアは動作するようになるでしょう. alias port proto internalmachine:port port

ここで ``proto'' は ``tcp'' か ``udp'' であり, ``internalmachine'' はパケットを送りたいマシン, そして ``port'' はパケットのディストネーションの port 番号です.

上記のコマンドを変更せずに他のマシン上でそのソフトウェアを 使用できるようにはしたくないかもしれません. そして 同時に二つの内部のマシン上でそのソフトウェアを実行することは この質問の範囲を超えています. 結局, 外側の世界からは 内部ネットワーク全体がただ一つのマシンとして見えるのです.

port 番号が常に同じとは限らない場合, さらに三つのオプションがあります.

1)libalias でサポートするようにし, 結果を送り付ける. 特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります (alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み, 内部の計算機のある特定のポートへの接続を開始するような命令が 外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する, という作業が含まれます.

これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが 複数の計算機で動くようにできます.

2)プロクシを使う. アプリケーションが, 例えば socks5 をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを 避けるためにあるオプションです.

3)''alias addr''を使ってなんでもかんでも内部の計算機に向けて 流してしまう. これはちょっと無理矢理な解決法です. 有用な port 番号のリストはありませんか?

まだ出来ていません. しかし, これは(関心を持って頂けるならば,) そういったリストにしていく予定です. Quake

Quake は UDP ポートの 6112 を使用すると報告されています. つまり, 次の行により quake が動くようになります. alias port udp hostmachine:6112 6112 ここで, hostmachine は quake サーバの IP アドレスです.

このように設定する代わりに, で Quake のプロキシーがサポートされているか 調べてもいいでしょう. FCS エラーって何?

FCS とは show hdlc コマンドを使って表示できます.

リンクの品質が悪かったり, シリアルドライバがパケットを取り こぼしていたりすると, FCS エラーがたびたび発生します. FCS エラー は, 圧縮プロトコルの速度低下の原因にはなりますが, 特に心配する 必要はありません. 外付けモデムを使っている場合は, ケーブルが ちゃんとシールドされているかを確認してください. そうでない場合, FCS エラーの原因となる場合があります.

接続直後からリンクがフリーズし, 大量の FCS エラーが発生する 場合は, リンクが 8 ビットクリーンでない可能性があります. ソフト ウェアフロー制御 (XON/XOFF) が使われていないことを確認してくだ さい. どうしてもソフトウェアフロー制御を使わなければならない場 合は, set accmap 0x000a0000 コマンドを使用して, ppp に ^Q と ^S をエスケープさせてください

リモートホストが ログファイルにリンクを終了した原因となるような記録がない場合は, リモートホスト(プロバイダ?)の管理者に, セッションを終了された 理由を尋ねてください. どれにも当てはまらない! どうしたらいいの?

これまでの全ての質問に当てはまらない場合, 設定ファイル, コマンドの出力 (接続前と接続後) を含む, あなたの持っている全ての情報を メーリングリストや ニュースグループへ 送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう. /dev/ed0 デバイスを作成することができません.

Berkeley UNIX におけるネットワークの構成においては, ネットワーク のインタフェースは kernel のコードからのみ直接あつかうことが できます. より詳しく知りたい場合は, /etc/rc.network というファイルや, このファイルの中に書いてあるさまざまなプログラム についてのマニュアルページを見てください. それでもまだ分からない場合には, 他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう. ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0 や Ultrix と基本的に同じです. Ethernet アドレスのエイリアスはどのようにして設定できますか?

のコマンドラインに `` ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff 3C503 で他のネットワークの port を使用するにはどのようにすればよいですか?

他の port を使用したい場合には, のコマンドラインにパラメータを 追加しなければなりません. default は ``. の using the ifconfig_* の変数を使って指定されるはずです. FreeBSD との間で NFS がうまくできません.

PC 用のネットワークカードによっては NFS のようなネットワークを 酷使するアプリケーションにおいて問題を起こすものがあります.

この点に関しては を見てください. 何故 Linux のディスクを NFS マウントできないのでしょうか?

Linux の NFS のコードによっては許可されたportからの リクエストからしか受けつけないものがあります. 以下を試してみてください. mount -o -P linuxbox:/blah /mnt 何故 Sun のディスクを NFS マウントできないのでしょうか?

SunOS 4.X が走っている Sun Workstation は許可された port からの mount のリクエストしか受けつけません. 以下を試してみてください. mount -o -P sunbox:/blah /mnt PPP で NeXTStep に接続する際に問題があるのですが.

の中で次の変数を NO にして, TCP extension を無効にしてみてください. tcp_extensions=NO

Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう 場合にもこの変更を行ってください. IP multicast を有効にするには?

2.0 かそれ以降の FreeBSD は, 標準の状態で完全に multicast に対応しています. 現在使用している計算機を multicast の router として使用するには, /etc/rc.conf でフラグ MBONE用のツールは ports 内の専用のカテゴリー mbone にあります. 詳しい情報は にあります. DEC の PCI チップセットを用いている network カードにはどのような物がありますか?

による一覧に, よりmodernな物を追加したものを 以下に示します. Vendor Model ---------------------------------------------- ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Zynx ZX342 何故自分のサイトのホストに対して FQDN を使用する必要があるのですか?

実際にはそのホストは別のドメインにあるのではないですか. たとえば, foo.bar.edu というドメインの中から, bar.edu ドメインにある ``mumble'' というホストを指定したい場合には, ``mumble'' だけでは 駄目で, ``mumble.bar.edu'' という fully-qualified domain name で 指定しなければなりません.

伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが, FreeBSD に入っている の現在のバージョンでは, 自分以外のドメインに対して FQDN でない別名を自動的につけてくれるような事はありません. したがって mumble というホスト名は mumble.foo.bar.edu という名前か, もしくは root ドメイン内にある場合にしか適用されません.

これは, mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチがおこなわれていた 以前の振る舞いとは異なったものです. このような事が悪い例もしくは セキュリティホールとみなされる理由については RFC 1535 を見てください.

の中で domain foo.bar.edu

と書いてある行を search foo.bar.edu bar.edu

のように書きかえることで, 上のような事ができます. しかし, RFC 1535 にあるように, search order が ``ローカルな管理と パブリックな管理の境界'' をまたがないようにしてください. すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが.

もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる ようにするには, root でログインして次のコマンドを実行してください. ipfw add 65534 allow all from any to any

/etc/rc.conf に "firewall_type='open'" を追加してもよい でしょう.

FreeBSD のファイアウォールの設定についての情報は にあります. 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 個目のruleは 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のバンド幅を使い切ることができます.

このテストでのルール数は多過ぎるため, 実際に使用する際の 結果を反映している訳ではありません. これらは上に示した数値を出す ためだけに用いられたものです. 効率の良いルールセットを作るためには, 次のような事を考えておけばよいでしょう. `確定している' ルールは先頭の方に持ってきてください. これは, 多数の TCP のトラフィックがこのルールで処理されるためです. そしてこのルールの前には allow tcp という記述を置かないでください. 良く使われるルールを, あまり良く使われないルールよりも 前の方に(もちろんファイアウォールの許可設定を変えない範囲で) 持ってきてください. ipfw -a l のようしてパケット数の統計を取ることで, どのルールが最もよく使われているかを調べることができます. サービス要求を他のマシンにリダイレクトするには?

FTP などのサービスのリクエストは, 'socket' パッケージを利用 してリダイレクトできます. 'socket' パッケージは ports の 'sysutils' カテゴリに含まれています. リダイレクトしたいサービ ス(/etc/inet.confのコマンド行をソケットを呼ぶように変 更してください. 変更例: ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp

ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp' はポートです. バンド幅の管理を行なえるツールはどこで手に入れられますか?

FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる と, から入手できる Bandwidth Manager という市販のものの 2 種類があります. なぜ ``/dev/bpf0: device not configured" が出るのでしょうか?

バークレーパケットフィルタ ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります. カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をして下さい. pseudo-device bpfilter # Berkeley Packet Filter

そして再起動してから, 次にデバイスノードを作成する必要があります. これは, 次のように入力し, /dev を変更することで行ないます. # sh MAKEDEV bpf0

デバイスノードの作成の詳細は, を参照して下さい.