netfilter/iptables FAQ
Harald Welte <laforge@gnumonks.org>
Version $Revision: 1.36 $, $Date: 2002/06/15 00:31:22 $
日本語訳: yomoyomo <ymgrtq@ma.neweb.ne.jp>
v1.36j 2002 年 08 月 09 日
この文書は、netfilter メーリングリストでみかける、よく聞かれる質問
(Frequently Asked Questions)を集めたものです。コメント / 追加 / より良
い解説を歓迎しますので、 FAQ 管理者にまわしてください。原文は
<http://www.netfilter.org/documentation/FAQ/netfilter-faq.html> にあり
ます。
______________________________________________________________________
目次
1. 一般的な質問
1.1 netfilter/iptables はどこから入手できますか？
1.2 netfilter の Linux 2.2 系へバックポートしたものはありますか？
1.3 ICQ conntrack/NAT ヘルパー・モジュールはありますか？
1.4 ip_masq_vdolive や ip_masq_quake などのモジュール群はどこに行ったのですか？
1.5 patch-o-matic とは一体何ですか？ またそれを私はどのように使えばよいのですか？
1.6 ipnatctl と、それに関する詳細な情報はどこにありますか？
2. ビルドの過程で起こる問題
2.1 iptables-1.1.1 が、カーネルが 2.4.0-test4 以上のとき、 コンパイルできないんです。
2.2 iptables 1.1.0 が最近のカーネル(2.3.99-pre8 以降) でコンパイルできないんです。
2.3 iptables 以降の 1.2.1a の patch-o-matic であてたパッチに、カーネルが 2.4.4 以降だと動かないものがあります。
2.4 ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP がコンパイルできません。
2.5 私は Alan Cox による 2.4.x-acXX シリーズのカーネルを使っているのですが、 問題が発生します。
3. 実行時の問題
3.1 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb
3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
3.3 netfilter を、Linux をブリッジにするコードと組み合わせて使う ことができないんです
3.4 IRC モジュールが、DCC RESUME を処理できません
3.5 複数のアドレスに対する SNAT は、どのように動作するのですか？
3.6 ip_conntrack: maximum limit of XXX entries exceeded
3.7 2.2.x 系カーネルのときに 'ipchains -L -M' でやったように、 追跡されている / マスカレードされているコネクションをすべて リストアップする方法はありますか？
3.8 有効なすべての IP テーブルを一覧する方法はありますか？
3.9 iptables-1.2 の iptables-save や iptables-restore で Segmentation Fault が出るようになりました
3.10 iptables -L とすると、ルールの表示に大変時間がかかります
3.11 LOG ターゲットによるコンソールへのログ出力を止めさせるには どうすればよいですか？
3.12 squid と iptables を使って透過型プロキシを構築するには どうすればよいでしょう？
3.13 LOG ターゲットはどのように使うのですか？ LOG と DROP を両方使うことはできますか？
3.14 XYZ ワームを netfilter で止めるにはどうしたらよいですか?
3.15 kernel logs: Out of window data xxx
3.16 何故、コネクション追跡システムは、UNREPLIED コネクションに大きな タイムアウト値を割り当てて追跡しているのですか？
3.17 なぜ 'iptables -C' (--check)オプションが実装されていないのですか?
4. netfilter の開発に関する質問
4.1 ユーザ空間からの QUEUE ターゲットの使い方が分からないんです
4.2 うちの libipq アプリケーションが "Failed to received netlink message: No buffer space available" というメッセージを出すんです
4.3 私はコードに貢献したいのですが、何をすれば良いか分かりません
4.4 バグを修正したり、拡張部分を書きました。どうすればそれを寄贈できますか？
5. 日本語訳について
______________________________________________________________________
1. 一般的な質問
この節は、メーリングリストで頻繁にみかけてきた、 netfilter に関連する
一般的な質問(と netfilter に関係ない質問) を対象とします。
1.1. netfilter/iptables はどこから入手できますか？
Netfilter と IPtables は、Linux 2.4.x 系カーネルに統合されます。
<http://www.kernel.org/> ないしはミラーサイトから、新しいカーネルを入
手してください。
ユーザ空間のツールである 'iptables' は、 <http://www.netfilter.org/>、
<http://www.iptables.org/>、 <http://netfilter.samba.org/>、
<http://netfilter.gnumonks.org/> 、
<http://netfilter.filewatcher.org/> といったミラーにある netfilter ホ
ームページから入手可能です。
1.2. netfilter の Linux 2.2 系へバックポートしたものはありますか？
いえ、現在のところありません。しかし、始めたいと思うなら、ネットワーク
・スタックのインタフェースはきれいにできてますので、それほど難しいとい
うことはないはずです。
この方面で何か動きがありましたら、我々に知らせてください。
1.3. ICQ conntrack/NAT ヘルパー・モジュールはありますか？
Linux 2.2 のマシンでの IP マスカレードに慣れているなら、クライアントど
うしで直接 ICQ 通信するのには、ずっと ip_masq_icq モジュールを使ってき
たことでしょう。 (訳注:ここで触れられている ip_masq_icq モジュールは、
<http://djsf.narod.ru/masq-icq/> より入手可能)。
しかし、誰もこのモジュールを netfilter 用に再実装しませんでした。とい
うのも、ICQ プロトコルはひどく汚いんです:) でも、それが利用できるよう
になるのも、時間の問題だと私は思ってます。
Rusty(訳注: netfilter の主要開発者である Rusty Russell のこと) はかつ
て、あるプロトコルのモジュールを netfilter ディストリビューションに組
み込むには、フリーなクライアントとフリーなサーバが少なくとも一つずつ存
在しなければならない、と言いました。 ICQ に関して言えば、フリーなクラ
イアントの方しか存在しませんので、この基準には適合しません。(ここでフ
リーというのは自由のことで、無料ビール(free beer)のフリーではありませ
ん。つまり、RMS の定義通り、ということです)
1.4. ip_masq_vdolive や ip_masq_quake などのモジュール群はどこに行っ
たのですか？
その必要がなくなったものもありますし、まだ netfilter に移植されてない
ものもあります。netfilter は、 UDP についても完全なコネクションの追跡
を行いますし、またパケットの流れをできる限り妨げないようにするポリシー
がありますので、「やってみたら動く」というものもあります。
1.5. patch-o-matic とは一体何ですか？ またそれを私はどのように使えば
よいのですか？
2.4.x 系カーネルは安定版リリースですので、我々が現在開発中のものを、リ
リース版のカーネルに持ちこむことはできません。我々のコードはすべて、ま
ず netfilter patch-o-matic において開発され、試験されます。 netfilter
の最先端の機能を使いたいなら、patch-o-matic からパッチを一つ以上あてな
くてはならないかもしれません。最新の iptables パッケージ(もちろん CVS
のソースでも大丈夫です) を netfilter ホームページからダウンロードすれ
ば、patch-o-matic を使うことができます。
patch-o-matic には現在、三種類のオプションがあります:
o make pending-patches
o make most-of-pom
o make patch-o-matic
一番目のオプションは、全ての重要なバグフィックス（何らかの形で、既にカ
ーネル管理者に提出されているもの）を、あなたのカーネルに確実に適用する
ものです。二番目の `most-of-pom` は、既存の機能と衝突を起こすことなく
適用可能な全ての新機能を更に入れるよう促すものです。三番目のオプション
である `patch-o-matic` は、全てのパッチについて確認しようと思う真のエ
キスパート向けのものです - しかし、これだとパッチ同士で衝突を起こすか
もしれないのに気をつけてください。
patch-o-matic は、すっきりしたユーザ・インタフェースを持っています。
make most-of-pom (か pending-patches か patch-o-matic。上記参照)
と入力するだけです。カーネル・ツリーが /usr/src/linux にない場合は
、iptables パッケージのトップ・ディレクトリで
make KERNEL_DIR={your-kernel-dir} most-of-pom
としてください。patch-o-matic は、パッチ毎に、インストールされているカ
ーネル・ソースにそのパッチが適合するかどうかをチェックします。パッチが
適合すれば、このパッチに関するより詳しい情報を表示するか、パッチを適用
するか、スキップして次のパッチに行くか…などの選択ができる、小さなプロ
ンプトが表示されます。
patch-o-matic についての情報がもっと必要なら、
<http://www.netfilter.org/documentation/index.html#HOWTO> にある
、Netfilter Extensions HOWTO を参照ください。
1.6. ipnatctl と、それに関する詳細な情報はどこにありますか？
ipnatctl は、2.3.x カーネルの頃、netfilter のごく初期の開発版において
、ユーザ空間から NAT ルールを設定するのに使われていました。もう必要な
くなったので、入手もできなくなりました。 ipatctl の機能はすべて
、iptables 自身により提供されています。 Netfilter ホームページにある
NAT HOWTO を参照ください (訳注: NAT HOWTO の日本語訳は、
<http://www.linux.or.jp/JF/JFdocs/NAT-HOWTO.html> にあります)。
2. ビルドの過程で起こる問題
2.1. iptables-1.1.1 が、カーネルが 2.4.0-test4 以上のとき、 コンパイ
ルできないんです。
これは既知の問題です。どのパッチを適用するか検出するメカニズムが壊れて
いるのです。"make" のかわりに "make build" を試してください。
より良い解決法は、iptables を 1.1.2 以降にアップグレードすることです。
2.2. iptables 1.1.0 が最近のカーネル(2.3.99-pre8 以降) でコンパイルで
きないんです。
iptables の内部構造が変わってます。iptables を 1.1.1 以降にアップグレ
ードしてください。
2.3. iptables 以降の 1.2.1a の patch-o-matic であてたパッチに、カーネ
ルが 2.4.4 以降だと動かないものがあります。
最新の iptables リリース版を利用してください。
2.4. ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP がコン
パイルできません。
おそらく ip_nat_setup_info という名前の関数をコンパイルする際に問題が
起きるのでしょう。
1.2.2 以前の iptables を使用しているなら、`dropped-table' パッチと
`ftp-fixes' パッチをあてる必要があります。
1.2.2 より後の iptables か、最近の CVS のソースを利用されている場合は
、'dropped-table' パッチをあてないでください。このパッチは BALANCE,
NETMAP, irc-nat, SAME, talk-nat との互換性がありません。
2.5. 私は Alan Cox による 2.4.x-acXX シリーズのカーネルを使っているの
ですが、 問題が発生します。
netfilter コア・チームは、Linus のカーネル・ツリーの元で開発をしていま
すので、-ac シリーズは、ご自身の責任の元でご利用ください。
3. 実行時の問題
3.1. NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa ->
224.bbb.bbb.bbb
このメッセージは、マルチキャスト・パケットが NAT テーブルを通る際に
NAT のコードにより出力されるもので、今のところコネクション追跡部がマル
チキャスト・パケットをうまく処理できないのが原因です。マルチキャストが
何であるか分からないか、またはマルチキャストをまったく必要としないなら
、以下のようにしてください:
iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8
3.2. NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa ->
bbb.bbb.bbb.bbb
syslog かコンソールに以下のメッセージが表示されます:
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
このメッセージは、NAT のコードにより表示されます。 NAT を行うには、有
効なコネクション追跡情報がないといけないので、パケットを破棄しているの
です。コネクション追跡部が conntrack 情報を決定できなかったパケットす
べてに対し、このメッセージが表示されます。
考えられる理由としては:
o conntrack データベース中のエントリ数が上限に達した
o 逆向きの組が決定できなかった(マルチキャスト、ブロードキャスト)
o kmem_cache_alloc に失敗(メモリ不足)
o 確立されてないコネクションのリプライ
o マルチキャスト・パケット(一つ前の質問を参照してください)
o 短すぎる ICMP パケット
o ICMP パケットがフラグメントされている
o ICMP パケットのチェックサム値が間違っている
こうしたパケットのもっと詳細なログを取りたいなら(つまり、リモート・プ
ローブやスキャニング・パケットだと疑うなら)、以下のルールを利用してく
ださい:
iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
そうです、パケットはフィルタ・テーブルに到達する前に、NAT のコードによ
って破棄されてしまうので、このルールを mangle テーブルに設定しなくては
なりません。
3.3. netfilter を、Linux をブリッジにするコードと組み合わせて使う こ
とができないんです
つまり、完全な透過型ファイアウォールを構築したいわけですね？素晴らしい
考えですね！カーネル 2.4.16 の時点でもなお、それを動かすには追加パッチ
をカーネルにあてる必要があります。そのパッチは、
<http://bridge.sourceforge.net/> で入手できます。
3.4. IRC モジュールが、DCC RESUME を処理できません
そうですね、それは半分本当のことです。NAT モジュールだけでは処理できま
せん。NAT 抜きでファイアウォールを利用すれば、それはうまくいきます。
3.5. 複数のアドレスに対する SNAT は、どのように動作するのですか？
netfilter は、できる限りパケットに手を加えないように努めます。ですので
、我々のところにリブートしたてのマシンがあり、 SNAT ボックスの背後にい
る誰かがローカル・ポート 1234 番でコネクションを開いた場合、netfilter
ボックスは IP アドレスだけに手を加え、ポート番号はそのままにしておきま
す。
SNAT 用の IP アドレスが一個しかない場合、誰かが同じ送信元ポート番号で
別のコネクションを開くと同時に、netfilter は IP アドレスとポート番号の
両方に手を加えなくてはならなくなります。
しかし、使用可能な IP アドレスが一個以上あるなら、この場合も IP 部に手
を加えるだけですみます。
3.6. ip_conntrack: maximum limit of XXX entries exceeded
このメッセージが syslog の中にあるのに気付いたら、ご利用の環境下では、
どうやら conntrack データベースが十分な数のエントリを持ってないようで
す。デフォルトでは、コネクション追跡部の処理できる同時接続数には、ある
一定の上限があります。この数は、ご利用のシステムのメモリ・サイズの上限
に依ります (メモリが 64MB でしたら 4096 個、128MB でしたら 8192 個
...)。
追跡するコネクションの数の上限を増やすことは簡単にできますが、追跡する
コネクション数ひとつあたり、swap できないカーネル・メモリを約 350 バイ
ト食うことをお忘れなく！
上限を例えば 8192 に増やすには、以下のように入力してください:
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
3.7. 2.2.x 系カーネルのときに 'ipchains -L -M' でやったように、 追跡
されている / マスカレードされているコネクションをすべて リストアップす
る方法はありますか？
proc ファイルシステム中に、/proc/net/ip_conntrack という名前のファイル
があります。以下のようにすれば、このファイルを出力して表示できます。
cat /proc/net/ip_conntrack
3.8. 有効なすべての IP テーブルを一覧する方法はありますか？
有効なすべての IP テーブルは、以下のようにしてリスト表示されます。
cat /proc/net/ip_tables_names
3.9. iptables-1.2 の iptables-save や iptables-restore で Segmenta-
tion Fault が出るようになりました
既知のバグです。できるだけ速やかに、最新の CVS のソースか、 1.2.1 以降
の iptables にアップグレードしてください。
3.10. iptables -L とすると、ルールの表示に大変時間がかかります
これは iptables が IP アドレス毎に DNS 検索を行っているためです。各ル
ール 2 つのアドレスから構成されますので、最悪の場合、ルール毎に 2 回
DNS 検索が入ります。
問題となるのは、プライベート IP アドレス(10.x.x.x や 192.168.x.x など)
を使っている場合で、DNS はホスト名を解決できず、タイムアウトします。こ
うしたタイムアウトの合計が、ご利用のルールセットによっては、とても長い
時間になるかもしれません。
DNS の逆引きを行わないようにするには、-n (numeric)オプションを入れて、
iptables をお使いください。
3.11. LOG ターゲットによるコンソールへのログ出力を止めさせるには どう
すればよいですか？
syslogd や klogd を適切に設定しなくてはなりません - LOG ターゲットは、
プライオリティ値 warning(4) で、ファシリティ値 kern のロギングを行いま
す。ファシリティ値とプライオリティ値についての詳細は、 syslogd.conf の
man ページを参照してください。
デフォルトでは、プライオリティ値が debug(7) より重要なカーネルのメッセ
ージがすべてコンソールに送られます。この値を 7 から 4 まで上げれば、コ
ンソール上に LOG メッセージが表示されることはありません。
こうすると、他の重要なメッセージもコンソールに表示されなくなるかも知れ
ません。気をつけてください (syslog ファイルには影響しません)。
3.12. squid と iptables を使って透過型プロキシを構築するには どうすれ
ばよいでしょう？
まず第一に、当然ながら、適切な DNAT か REDIRECT のルールが必要となりま
す。 squid が NAT ボックス自身の上で動くなら、REDIRECT のみ使ってくだ
さい。例えば:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128
その後、squid を正しく設定しなくてはなりません。我々がここで提供できる
情報は限られていますので、更に詳しい情報については、squid のドキュメン
トを参照ください。
Squid 2.3 での squid.conf に、以下のような設定が必要です:
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Squid 2.4 になると、さらに設定行が必要になります:
httpd_accel_single_host off
3.13. LOG ターゲットはどのように使うのですか？ LOG と DROP を両方使う
ことはできますか？
LOG ターゲットは、いわゆる「終了しないターゲット」です。つまりそれは、
パケットがルールに適合しても、そこで終了しません。 LOG ターゲットを利
用すると、パケットはロギングされ、ルール適合の検索が次のルールに引き継
がれます。
では、ログを取り、同時に破棄するにはどうすればよいのでしょう？最も簡単
なのは、二つのルールを含むチェインをあつらえることです:
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
今後パケットをログに記録してから破棄したい場合は、 "-j logdrop" を使う
だけですみます。
3.14. XYZ ワームを netfilter で止めるにはどうしたらよいですか?
netfilter では確実に止めることはできない、というのが端的な回答になりま
す。大部分のワームは、正規の高レベルのプロトコル(つまり、HTTP や SMTP
(電子メールに VB スクリプトが添付される)や、そうしたプロトコルを処理す
るデーモンに見つかった脆弱性を突くプログラム)を利用したものです。ここ
でいう高レベルのプロトコルとは、TCP/IP よりも上の層にあるプロトコルの
ことです。iptables はそうした高レベルのプロトコルを見ないので、適切に
フィルタリングするのはほとんど不可能です。それを行うには、アプリケーシ
ョン・プロキシ・フィルタリングが必要になります。
アプリケーション・プロキシ・フィルタリングを行うかわりに、patch-o-
matic にある string ターゲットを使うのは止めて下さい。それだと、フラグ
メントされたパケット(HTTP リクエストが二つの TCP パケットに分割される
ような場合)がきたり、IDS すり抜け技術をやられたり、その他もろもろの場
合に失敗してしまいます。警告はしましたよ! string マッチは有用ですが、
別の用途のためにあるのです。
3.15. kernel logs: Out of window data xxx
あなたは patch-o-matic から tcp-window-tracking パッチを適用しています
。そのコードは、パケットのシーケンス／確認応答番号、セグメント・サイズ
などにより、許可された TCP ストリームに関して、条件を満たしているパケ
ットを追跡し続けます。パケットの一つが条件を満たしていない(範囲外)のを
検出すると、そのパケットが無効であるとみなし、上記のメッセージを表示し
ます。
新バージョンから、そのパケットと、その不適合の原因を正確に記録するよう
にしています。
o ACK 番号が下限を下回っている (ひょっとすると、過度に遅延した ACK で
ある可能性はある)
o ACK 番号が上限を超えている(ACK 応答データがまだ届いていない)
o SEQ 番号が下限を下回っている(既に ACK 応答データが再送されている)
o SEQ 番号が上限を超えている (受信者のウィンドウ・サイズを超えている)
また新バージョンでは、sysctl によりそのロギングを完全に止めることも可
能です。
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
3.16. 何故、コネクション追跡システムは、UNREPLIED コネクションに大き
な タイムアウト値を割り当てて追跡しているのですか？
あなたは /proc/net/ip_conntrack を見て、UNREPLIED エントリに非常に大き
なタイマ値(最高で5日)が割り当てられているのに気付き、どうして我々が (
明らかにコネクションではない) UNREPLIED エントリに無駄に conntrack エ
ントリを使おうとするのかと不思議に思われたのですね?
その答えは簡単です: UNREPLIED エントリは、テンポラリなエントリだからで
す。つまり、コネクション追跡エントリが限界まで来たらすぐに、古い
UNREPLIED エントリを削除します。言いかえると、conntrack を何も持たない
よりは、 UNREPLIED エントリの中の有用かもしれない情報を、それが実際に
必要とするまで保持しておくのがよいだろうというわけです。
3.17. なぜ 'iptables -C' (--check)オプションが実装されていないのです
か?
えーと、つまるところ我々が怠惰だからです;) はっきり言って、ステートフ
ルなファイヤウォーリングを始めた時点で、チェックオプションを実装するの
がほとんど不可能になります。伝統的なステートレスなファイヤウォーリング
の場合、フィルタリングを行うかどうかは、パケットヘッダにのっている情報
だけで決まります。しかし、コネクション追跡(や '-m state' ベースのルー
ル) を行う場合、フィルタリングを行うかどうかは、そのパケットのヘッダと
ペイロードの内容だけでなく、そのコネクションに以前流れたパケットのヘッ
ダとペイロードの内容によっても変わります。
4. netfilter の開発に関する質問
4.1. ユーザ空間からの QUEUE ターゲットの使い方が分からないんです
libipq というライブラリが、ユーザ空間でのパケット操作のために提供され
ています。これに関するドキュメントは、現在 man ページの形式で存在しま
す。iptables の開発コンポーネントをビルドし、インストールする必要があ
ります:
make install-devel
インストールしたら libipq(3) を参照ください。
libipq 用の Perl バインディングである、Perlipq
<http://www.intercode.com.au/jmorris/perlipq/> にも興味があるかもしれ
ません。そのバインディング自身が、ライブラリの利用の一例になります。
その他のコード例として:
o netfilter CVS にある、testsuite/tools/intercept.c
o ipqmpd( <http://www.gnumonks.org/projects/> 参照)
o netfilter-tools の一部である、nfqtest(
<http://www.gnumonks.org/projects/> 参照)
o Jerome Etienne 作の WAN シミュレータ( <http://www.off.net/~jme/> 参
照)
4.2. うちの libipq アプリケーションが "Failed to received netlink
message: No buffer space available" というメッセージを出すんです
これは、カーネル側の Netlink ソケットバッファが領域不足に陥っています
。そうなると、ユーザスペースのアプリケーションは、カーネルから届いたデ
ータを全部は処理できません。
この問題を回避するためにカーネルバッファを今より大きくするこ
とは可能ですか?
はい、標準的な Netlink ソケットですので、/proc/sys/net/core に書きこん
だり、 sysctl を実行したり、もしくはファイルディスクリプタにおいて
SO_RCVBUF ソケットオプションを利用することで受信バッファサイズを調整で
きます。
アプリケーションができるだけ高速に受信データを読むようにすることも可能
です。パケット全体が必要でないなら、ユーザスペースにコピーするデータサ
イズを小さくしてみましょう(ipq_set_mode(3) 参照)。
4.3. 私はコードに貢献したいのですが、何をすれば良いか分かりません
netfilter コアチームは、望まれる変更や新機能の全てを一覧にした、 TODO
リストを管理しています。このリストは anonymous CVS 経由で入手可能で、
説明書は netfilter ホームページにあります。あるいは、CVSweb を使って、
<http://cvs.samba.org/cgi-bin/cvsweb/netfilter/TODO/> から取得可能です
。
4.4. バグを修正したり、拡張部分を書きました。どうすればそれを寄贈でき
ますか？
それを公開したい場合は、netfilter-devel メーリングリストまで送ってくだ
さい。購読に関する説明書は、
<http://lists.samba.org/mailman/listinfo/netfilter-devel/> にあります
。
パッチを送る正しいやり方は、以下のようなものです:
o Subject は、[PATCH] で始める
o メッセージ本体に直接含め、MIME 化しない。
o diff 以外に、cvs-checkin/Changelog エントリをつける
o ルート・ディレクトリからの `diff -u old new' 形式にする (つまり、他
のディレクトリにいても、 -p1 オプションでパッチを適用できるように)
もしあなたが新しい拡張を書いたか、もしくは以前からある拡張に新しいオプ
ションを追加したなら、その新規の拡張/機能に関する記述を入れて
、netfilter-extension-HOWTO を更新するのも良い考えです。そうすれば、よ
り多くのユーザにあなたが書いた拡張を知らしめますし、一般ユーザからのフ
ィードバックをより得られるようになります。
5. 日本語訳について
日本語訳は Linux Japanese FAQ Project が作成しました。翻訳に関するご意
見は JF プロジェクト <JF@linux.or.jp> または、yomoyomo
<ymgrtq@ma.neweb.ne.jp> 宛に連絡してください。
本日本語訳について、誤訳・誤記の指摘をして下さったつぎの方々に感謝しま
す(50音順)。
o office さん <office@office.ac>
o 小林雅典さん <zap03216@nifty.ne.jp>
o 中野武雄さん <nakano@apm.seikei.ac.jp>
o 水原文さん <mizuhara@acm.org>
o 森本淳さん <morimoto@xantia.citroen.org>
o 山森浩幸さん <h-yamamo@db3.so-net.ne.jp>