訳: &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 ......"

詳しくはお使いのモデムのマニュアルをご覧ください. 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でdialをするようなprocessがconnectしてくれない

これはを呼び出した時, tun intergaceのIP numberが socketのendpointに割り当てられます. kernelは最初に外へ出ていく packetを作り, それをtunデバイスへ書きます. 次にこの問題に対処する理論的な方法がいくつかあります. もし可能なら, 相手が同じIP numberを割り当てなおす事ができるのが最も良いです我々の側から対処できる最も簡単な方法は, tun interfaceのIP numberを固定する事ですが, かわりに外に出ていくpacketを変更して source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる 事によっても対処できます. これが, (およびpppのもう1つの(最も確かな)方法は, 全てのbindされているsocketの IPを変更するようにsystem callを実装する事です. 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで は255.255.255.255というIP numberを与えられます. これによって socketを完全に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''を使ってなんでもかんでも内部の計算機に向けて 流してしまう. これはちょっと無理矢理な解決法です. 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'' というメッセージが表示されるのですが.

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

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

FreeBSD の firewall の設定についての情報は にあります. IPFWのオーバーヘッドはどのくらいでしょうか?

この答えはあなたのrule setとprocessorのスピードによって ほとんど決まります. Ethernetに対して少しのrule setだけを使っ ているほどんどの場合には, その影響は無視できる程度です. 実 際の測定値を見ないと満足できない方々のために, 実際の測定結 果をお見せしましょう.

次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました. IPFWは変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが おこなわれました. ひとつ目のsetは最悪のケースを見るために ipfw add deny tcp from any to any 55555 というruleを繰り返したものです.

このsetを用いますと, (port番号によって) packetが全てのruleにマッチ しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン のほとんど全てが実行されますので, 最悪のケースとなります. この ruleを999個繰り返した後にallow ip from any to anyが 書かれています.

2つ目のsetは, なるべく早くチェックが終了するように書かれたものです: ipfw add deny ip from 1.2.3.4 to 1.2.3.4

このruleではsource側のIPアドレスがマッチしないのでチェックは すぐに終了します. 上のsetとおなじように, 1000個目のruleは allow ip from any to anyです.

1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet, 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです. 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の バンド幅までしか使えない事になります.

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて いますので1つのruleあたり1.2マイクロ秒となります. packetの 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので 10Mbps Ethernetのバンド幅を使い切ることができます.

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

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

ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp' はポートです.