<!doctype linuxdoctr system>

<article>

<title>netfilter/iptables FAQ</title>
<author>Harald Welte &lt;laforge@gnumonks.org&gt;</author>
<date>Version &dollar;Revision: 1.36 &dollar;, &dollar;Date: 2002/06/15 00:31:22 &dollar;</date>

<trans>日本語訳: yomoyomo &lt;ymgrtq@ma.neweb.ne.jp&gt;
<tdate> v1.36j 2002 年 08 月 09 日

<abstract>
<!--
This document contains the Frequently Asked Questions as encountered on the 
netfilter mailing list. Comments / additions / clarifications are 
appreciated and should be directed to the FAQ maintainer.
-->
この文書は、netfilter メーリングリストでみかける、よく聞かれる質問
(Frequently Asked Questions)を集めたものです。
コメント / 追加 / より良い解説を歓迎しますので、
FAQ 管理者にまわしてください。
原文は
<url url="http://www.netfilter.org/documentation/FAQ/netfilter-faq.html">
にあります。
</abstract>

<toc>

<sect><!-- General Questions -->
一般的な質問
<p>
<!--
This section covers general netfilter(and non-netfilter) related questions
we've encountered frequently on the mailing list.
-->
この節は、メーリングリストで頻繁にみかけてきた、
netfilter に関連する一般的な質問(と netfilter に関係ない質問)
を対象とします。

<sect1><!-- Where can I get netfilter/iptables? -->
netfilter/iptables はどこから入手できますか？
<p>
<!--
Netfilter and IPtables are integrated in the Linux 2.4.x kernel series.
Please obtain a recent kernel from <url url="http://www.kernel.org/"> or
one of its mirrors.
-->
Netfilter と IPtables は、Linux 2.4.x 系カーネルに統合されます。
<url url="http://www.kernel.org/"> ないしはミラーサイトから、
新しいカーネルを入手してください。
<p>
<!--
The userspace tool 'iptables' is available at the netfilter homepage on one of the mirrors at
<url url="http://www.netfilter.org/">,
<url url="http://www.iptables.org/">,
<url url="http://netfilter.samba.org/">,
<url url="http://netfilter.gnumonks.org/"> or
<url url="http://netfilter.filewatcher.org/">.
-->
ユーザ空間のツールである 'iptables' は、
<url url="http://www.netfilter.org/">、
<url url="http://www.iptables.org/">、
<url url="http://netfilter.samba.org/">、
<url url="http://netfilter.gnumonks.org/"> 、
<url url="http://netfilter.filewatcher.org/">
といったミラーにある netfilter ホームページから入手可能です。
</sect1>

<sect1><!-- Is there a backport of netfilter to Linux 2.2? -->
netfilter の Linux 2.2 系へバックポートしたものはありますか？
<p>
<!--
No, there currently is none. But if anybody wants to start, it shouldn't
be too difficult because of the clean interface to the network stack.
-->
いえ、現在のところありません。しかし、始めたいと思うなら、
ネットワーク・スタックのインタフェースはきれいにできてますので、
それほど難しいということはないはずです。
<p>
<!--
Please inform us about any work in this area.
-->
この方面で何か動きがありましたら、我々に知らせてください。
</sect1>

<sect1><!-- Is there an ICQ conntrack/NAT helper module? -->
ICQ conntrack/NAT ヘルパー・モジュールはありますか？
<p>
<!--
If you are used to masquerading on a Linux 2.2 box, you always used the
ip_masq_icq module in order to get direct client-to-client ICQ working.
-->
Linux 2.2 のマシンでの IP マスカレードに慣れているなら、
クライアントどうしで直接 ICQ 通信するのには、ずっと ip_masq_icq
モジュールを使ってきたことでしょう。
(訳注:ここで触れられている ip_masq_icq モジュールは、
<url url="http://djsf.narod.ru/masq-icq/"> より入手可能)。
<p>
<!--
Nobody re-implemented this module for netfilter, because the ICQ protocol
is too ugly :) But I guess it's just a matter of time until one is available.
-->
しかし、誰もこのモジュールを netfilter 用に再実装しませんでした。
というのも、ICQ プロトコルはひどく汚いんです:) でも、
それが利用できるようになるのも、時間の問題だと私は思ってます。
<p>
<!--
Rusty once pointed out that only modules for protocols with at least one
free client and one free server are going to get integrated into the main
netfilter distribution. As for ICQ, there are only free clients, so it
doesn't match this criteria. (free as in freedom, not in free beer, i.e.
RMS' definition)
-->
Rusty(訳注: netfilter の主要開発者である Rusty Russell のこと)
はかつて、あるプロトコルのモジュールを netfilter
ディストリビューションに組み込むには、フリーなクライアントと
フリーなサーバが少なくとも一つずつ存在しなければならない、と言いました。
ICQ に関して言えば、フリーなクライアントの方しか存在しませんので、
この基準には適合しません。(ここでフリーというのは自由のことで、
無料ビール(free beer)のフリーではありません。つまり、RMS の定義通り、
ということです)
</sect1>

<sect1><!-- Where did the ip_masq_vdolive / ip_masq_quake / ... modules go? -->
ip_masq_vdolive や ip_masq_quake などのモジュール群はどこに行ったのですか？
<p>
<!--
Some of them are not required, and some haven't been ported to
netfilter yet.  Netfilter does full connection tracking even for UDP,
and has a policy of trying to disturb the packets at little as
possible, so sometimes things `just work'.
-->
その必要がなくなったものもありますし、まだ netfilter
に移植されてないものもあります。netfilter は、
UDP についても完全なコネクションの追跡を行いますし、また
パケットの流れをできる限り妨げないようにするポリシーがありますので、
「やってみたら動く」というものもあります。

</sect1>

<sect1><!-- What is this patch-o-matic all about and how do I use it? -->
patch-o-matic とは一体何ですか？　またそれを私はどのように使えばよいのですか？
<p>
<!--
The 2.4.x kernels is a stable release, so we can't just submit our
current development into the mainstream kernel.  All our code is 
developed and tested in netfilter patch-o-matic first.  If you
want to use any of the bleeding-edge netfilter functions, you may have
to apply one or more of the patches from patch-o-matic.   You can find
patch-o-matic in the latest iptables package (or of course CVS), to be
downloaded from the netfilter homepage.
-->
2.4.x 系カーネルは安定版リリースですので、我々が現在開発中のものを、
リリース版のカーネルに持ちこむことはできません。我々のコードはすべて、
まず netfilter patch-o-matic において開発され、試験されます。
netfilter の最先端の機能を使いたいなら、patch-o-matic
からパッチを一つ以上あてなくてはならないかもしれません。
最新の iptables パッケージ(もちろん CVS のソースでも大丈夫です)
を netfilter ホームページからダウンロードすれば、patch-o-matic
を使うことができます。
<p>
<!--
patch-o-matic now has three different options:
-->
patch-o-matic には現在、三種類のオプションがあります:
<itemize>
<item>make pending-patches</item>
<item>make most-of-pom</item>
<item>make patch-o-matic</item>
</itemize>
<p>
<!--
The first one is just to make sure all important bugfixes (which have
been submitted to the kernel maintainers anyway) are applied to your kernel.
The second `most-of-pom` additionally prompts you for all new features which
can be applied without conflict.  The third option `patch-o-matic` is for
real experts who want to see all the patches - but be aware, they might
conflict which each other.
-->
一番目のオプションは、全ての重要なバグフィックス（何らかの形で、
既にカーネル管理者に提出されているもの）を、あなたのカーネルに
確実に適用するものです。二番目の `most-of-pom` は、既存の機能と
衝突を起こすことなく適用可能な全ての新機能を更に入れるよう促すものです。
三番目のオプションである `patch-o-matic` は、全てのパッチについて
確認しようと思う真のエキスパート向けのものです - しかし、
これだとパッチ同士で衝突を起こすかもしれないのに気をつけてください。
<p>
<!--
patch-o-matic has a neat user interface.  Just enter
-->
patch-o-matic は、すっきりしたユーザ・インタフェースを持っています。

<tscreen><verb>
make most-of-pom (か pending-patches か patch-o-matic。上記参照)
</verb></tscreen>

<!--
or, if your kernel tree is not in <tt>/usr/src/linux</tt> then use
-->
と入力するだけです。カーネル・ツリーが <tt>/usr/src/linux</tt>
にない場合は、iptables パッケージのトップ・ディレクトリで

<tscreen><verb>
make KERNEL_DIR={your-kernel-dir} most-of-pom
</verb></tscreen>

<!--
in the top directory of the iptables-package.  patch-o-matic checks
for each of the patches if it would apply against the kernel source
you have installed.  If a patch would apply, you will see a little
prompt, where you can ask for more information about this patch, apply
the patch, skip to the next one, ...
-->
としてください。patch-o-matic は、パッチ毎に、インストールされている
カーネル・ソースにそのパッチが適合するかどうかをチェックします。
パッチが適合すれば、このパッチに関するより詳しい情報を表示するか、
パッチを適用するか、スキップして次のパッチに行くか…などの選択ができる、
小さなプロンプトが表示されます。
<p>
<!--
For more information about patch-o-matic, please see the netfilter
extensions HOWTO, to be found at
<url url="http://www.netfilter.org/documentation/index.html#HOWTO">
-->
patch-o-matic についての情報がもっと必要なら、
<url url="http://www.netfilter.org/documentation/index.html#HOWTO">
にある、Netfilter Extensions HOWTO を参照ください。
</sect1>

<sect1><!-- Where can I find ipnatctl and more information about it? -->
ipnatctl と、それに関する詳細な情報はどこにありますか？
<p>
<!--
ipnatctl was used to set up your NAT rules from userspace in a very 
early development revision of netfilter during the 2.3.x kernels.
It is no longer needed, thus no longer available. All of its
functionality is provided by iptables itself. Have a look at the
NAT HOWTO on the Netfilter homepage.
-->
ipnatctl は、2.3.x カーネルの頃、netfilter のごく初期の開発版において、
ユーザ空間から NAT ルールを設定するのに使われていました。
もう必要なくなったので、入手もできなくなりました。
ipatctl の機能はすべて、iptables 自身により提供されています。
Netfilter ホームページにある NAT HOWTO を参照ください
(訳注: NAT HOWTO の日本語訳は、
<url url="http://www.linux.or.jp/JF/JFdocs/NAT-HOWTO.html"> にあります)。
</sect1>

</sect>

<sect><!-- Problems during the build process -->
ビルドの過程で起こる問題
<p>

<sect1><!-- I cannot compile iptables-1.1.1 with kernel >= 2.4.0-test4 -->
iptables-1.1.1 が、カーネルが 2.4.0-test4 以上のとき、
コンパイルできないんです。
<p>
<!--
This is a known issue. The mechanism for the detection which patches 
to apply is broken. Try using "make build" instead of "make".
-->
これは既知の問題です。どのパッチを適用するか検出するメカニズムが
壊れているのです。"make" のかわりに "make build" を試してください。

<p>
<!--
Better solution: Upgrade to iptables-1.1.2 or later
-->
より良い解決法は、iptables を 1.1.2 以降にアップグレードすることです。

</sect1>

<sect1><!-- I cannot compile iptables 1.1.0 with recent kernels (>= 2.3.99-pre8) -->
iptables 1.1.0 が最近のカーネル(2.3.99-pre8 以降)
でコンパイルできないんです。
<p>
<!--
Internal structures in iptables have changed. Upgrade to iptables >= 1.1.1
-->
iptables の内部構造が変わってます。iptables を 1.1.1
以降にアップグレードしてください。

</sect1>

<sect1><!-- Some patch-o-matic patches from iptables >= 1.2.1a don't work with kernel >= 2.4.4 -->
iptables 以降の 1.2.1a の patch-o-matic であてたパッチに、カーネルが
2.4.4 以降だと動かないものがあります。

<p>
<!--
Please use a recent iptables release.
-->
最新の iptables リリース版を利用してください。
</sect1>

<sect1><!-- ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP don't compile -->
ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP
がコンパイルできません。
<p>
<!--
Most likely you are experiencing compile problems with a function called
<tt>ip_nat_setup_info</tt>. 
-->
おそらく <tt>ip_nat_setup_info</tt>
という名前の関数をコンパイルする際に問題が起きるのでしょう。

<p>
<!--
If you are using iptables &lt;= 1.2.2, you <bf>NEED</bf> to apply the
`dropped-table' and `ftp-fixes' patches.
-->
1.2.2 以前の iptables を使用しているなら、`dropped-table' パッチと `ftp-fixes'
パッチをあてる<bf>必要</bf>があります。
<p>
<!--
If you are using iptables > 1.2.2 or recent CVS, please <bf>don't</bf> apply
the 'dropped-table', as it is incompatible with BALANCE, NETMAP, irc-nat,
SAME and talk-nat.
-->
1.2.2 より後の iptables か、最近の CVS のソースを利用されている場合は、'dropped-table'
パッチを<bf>あてない</bf>でください。
このパッチは BALANCE, NETMAP, irc-nat, SAME, talk-nat
との互換性がありません。

</sect1>

<sect1><!-- I'm using Alan Cox' 2.4.x-acXX series kernel and I experience problems -->
私は Alan Cox による 2.4.x-acXX シリーズのカーネルを使っているのですが、
問題が発生します。
<p>
<!--
The netfilter core team bases development on Linus' kernel tree, so using the
-ac series is on your own risk.
-->
netfilter コア・チームは、Linus のカーネル・ツリーの元で開発
をしていますので、-ac シリーズは、ご自身の責任の元でご利用ください。
</sect1>

</sect>

<sect><!-- Problems at runtime -->
実行時の問題

<sect1> NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb

<p>
<!--
This message is printed by the NAT code, because multicast packets are hitting
the NAT table, and connection tracking doesn't handle multicast packets right 
now. In case you have no idea what multicast is, or don't need it at all, use:
-->
このメッセージは、マルチキャスト・パケットが NAT テーブルを通る際に
NAT のコードにより出力されるもので、今のところコネクション追跡部が
マルチキャスト・パケットをうまく処理できないのが原因です。
マルチキャストが何であるか分からないか、
またはマルチキャストをまったく必要としないなら、
以下のようにしてください:
<tscreen><verb>
iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8
</verb></tscreen>

</sect1>

<sect1>NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
<p>
<!--
My syslog or my console shows the message:
-->
syslog かコンソールに以下のメッセージが表示されます:
<tscreen><verb>
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
</verb></tscreen>

<p>
<!--
This message is printed by the NAT code. It drops packets, because in order to
do NAT it has to have valid connection tracking information. This message is
printed for all packets for which connection tracking was unable to determine
conntrack information.
-->
このメッセージは、NAT のコードにより表示されます。
NAT を行うには、有効なコネクション追跡情報がないといけないので、
パケットを破棄しているのです。コネクション追跡部が conntrack
情報を決定できなかったパケットすべてに対し、このメッセージが表示されます。

<p>
<!--
Possible reasons are:
-->
考えられる理由としては:
<itemize>
<item><!-- maximum limit of entries in the conntrack database reached -->
conntrack データベース中のエントリ数が上限に達した
<item><!-- couldn't determine inverted tuple (multicast, broadcast) -->
逆向きの組が決定できなかった(マルチキャスト、ブロードキャスト)
<item><!-- kmem_cache_alloc fails (out of memory) -->
kmem_cache_alloc に失敗(メモリ不足)
<item><!-- reply on unconfirmed connection -->
確立されてないコネクションのリプライ
<item><!-- multicast packet (please see previous question) -->
マルチキャスト・パケット(一つ前の質問を参照してください)
<item><!-- icmp packet too short -->
短すぎる ICMP パケット
<item><!-- icmp is fragmented -->
ICMP パケットがフラグメントされている
<item><!-- icmp checksum wrong -->
ICMP パケットのチェックサム値が間違っている
</itemize>

<p>
<!--
If you want to have a more detailed logging of these packets (i.e. if
you suspect it are remote probe / scanning packets), use the following
rule:
-->
こうしたパケットのもっと詳細なログを取りたいなら(つまり、
リモート・プローブやスキャニング・パケットだと疑うなら)、
以下のルールを利用してください:
<tscreen><verb>
iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
</verb></tscreen>
<p>
<!--
And yes, you have to put the rule in the mangle table, because the
packets get dropped by the NAT code before they reach the filter
table.
-->
そうです、パケットはフィルタ・テーブルに到達する前に、NAT
のコードによって破棄されてしまうので、このルールを mangle
テーブルに設定しなくてはなりません。

</sect1>

<sect1><!-- I'm unable to use netfilter in combination with the Linux bridging 
code-->
netfilter を、Linux をブリッジにするコードと組み合わせて使う
ことができないんです
<p>
<!--
So you want to build a completely transparent firewall?  Great idea! 
As of kernel 2.4.16, you still need to patch your kernel with an extra
patch to get this running.  You can find it at
<url url="http://bridge.sourceforge.net/">.
-->
つまり、完全な透過型ファイアウォールを構築したいわけですね？
素晴らしい考えですね！
カーネル 2.4.16 の時点でもなお、それを動かすには追加パッチを
カーネルにあてる必要があります。そのパッチは、
<url url="http://bridge.sourceforge.net/"> で入手できます。

</sect1>

<sect1><!-- The IRC module is unable to handle DCC RESUME -->
IRC モジュールが、DCC RESUME を処理できません
<p>
<!--
Well, that's half the truth.  Only the NAT module is unable to handle
them.  If you just use firewalling without NAT it should work fine.
-->
そうですね、それは半分本当のことです。NAT モジュールだけでは
処理できません。NAT 抜きでファイアウォールを利用すれば、
それはうまくいきます。

</sect1>

<sect1><!-- How does SNAT to multiple addresses work? -->
複数のアドレスに対する SNAT は、どのように動作するのですか？
<p>
<!--
Netfilter tries to mangle as little as possible. So if we have a freshly-
rebooted machine, and somebody behind the SNAT box opens a connection
with local port 1234, the netfilter box only mangles the IP address and
the port stays the same. 
-->
netfilter は、できる限りパケットに手を加えないように努めます。
ですので、我々のところにリブートしたてのマシンがあり、
SNAT ボックスの背後にいる誰かがローカル・ポート
1234 番でコネクションを開いた場合、netfilter ボックスは IP
アドレスだけに手を加え、ポート番号はそのままにしておきます。
<p>
<!--
As soon as somebody else opens another connection
with the same source port, netfilter would have to mangle IP and port if
it only has a single IP for SNAT. 
-->
SNAT 用の IP アドレスが一個しかない場合、誰かが同じ送信元ポート番号
で別のコネクションを開くと同時に、netfilter は IP
アドレスとポート番号の両方に手を加えなくてはならなくなります。
<p>
<!--
But if there are more than one available, it <bf>again</bf> only has to
mangle the IP part.
-->
しかし、使用可能な IP アドレスが一個以上あるなら、
<bf>この場合も</bf> IP 部に手を加えるだけですみます。
</sect1>

<sect1>ip_conntrack: maximum limit of XXX entries exceeded
<p>
<!--
If you notice the following message in syslog, it looks like the conntrack
database doesn't have enough entries for your environment. Connection
tracking by default handles up to a certain number of simultaneous connections.
This number is dependent on you system's maximum memory size (at 64MB: 4096,
128MB: 8192, ...). 
-->
このメッセージが syslog の中にあるのに気付いたら、ご利用の環境下では、
どうやら conntrack データベースが十分な数のエントリを持ってないようです。
デフォルトでは、コネクション追跡部の処理できる同時接続数には、
ある一定の上限があります。
この数は、ご利用のシステムのメモリ・サイズの上限に依ります
(メモリが 64MB でしたら 4096 個、128MB でしたら 8192 個 ...)。
<p>
<!--
You can easily increase the number of maximal tracked connections, but be 
aware that each tracked connection eats about 350 bytes of non-swappable 
kernel memory!
-->
追跡するコネクションの数の上限を増やすことは簡単にできますが、
追跡するコネクション数ひとつあたり、swap できないカーネル・メモリを約
350 バイト食うことをお忘れなく！
<p>
<!--
To increase this limit to e.g. 8192, type:
-->
上限を例えば 8192 に増やすには、以下のように入力してください:

<tscreen><verb>
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
</verb></tscreen>

</sect1>

<sect1><!-- How do I list all tracked / masqueraded connections, similar to 'ipchains -L -M' in 2.2.x ? -->
2.2.x 系カーネルのときに 'ipchains -L -M' でやったように、
追跡されている / マスカレードされているコネクションをすべて
リストアップする方法はありますか？
<p>
<!--
There is a file in the proc-filesystem, which is called <tt>/proc/net/ip_conntrack</tt>. You can print the output of this file using
-->
proc ファイルシステム中に、<tt>/proc/net/ip_conntrack</tt>
という名前のファイルがあります。以下のようにすれば、
このファイルを出力して表示できます。

<tscreen><verb>
cat /proc/net/ip_conntrack
</verb></tscreen>
</sect1>

<sect1><!-- How do I list all available IP tables? -->
有効なすべての IP テーブルを一覧する方法はありますか？
<p>
<!--
All available IP tables are listed with
-->
有効なすべての IP テーブルは、以下のようにしてリスト表示されます。
<tscreen><verb>
cat /proc/net/ip_tables_names
</verb></tscreen>
</sect1>

<sect1><!-- iptables-save / iptables-restore from iptables-1.2 segfaults -->
iptables-1.2 の iptables-save や iptables-restore で
Segmentation Fault が出るようになりました
<p>
<!--
Known Bug.  Please update to latest CVS or use iptables >= 1.2.1 as 
soon as it is available.
-->
既知のバグです。できるだけ速やかに、最新の CVS のソースか、
1.2.1 以降の iptables にアップグレードしてください。
</sect1>

<sect1><!-- iptables -L takes a very long time to display the rules -->
iptables -L とすると、ルールの表示に大変時間がかかります
<p>
<!--
This is because iptables does a DNS lookup for each IP address. As each
rule consists out of two addresses, the worst case is two DNS lookups per
rule.
-->
これは iptables が IP アドレス毎に DNS 検索を行っているためです。
各ルール 2 つのアドレスから構成されますので、最悪の場合、
ルール毎に 2 回 DNS 検索が入ります。
<p>
<!--
The problem is, if you use private IP addresses (like 10.x.x.x or 192.168.x.x),
DNS is unable to resolve a hostname and times out. The sum of all these 
timeouts may be _very_ long, depending on your ruleset.
-->
問題となるのは、プライベート IP アドレス(10.x.x.x や 192.168.x.x など)
を使っている場合で、DNS はホスト名を解決できず、タイムアウトします。
こうしたタイムアウトの合計が、ご利用のルールセットによっては、
とても長い時間になるかもしれません。
<p>
<!--
Please use the -n (numeric) option for iptables in order to prevent it from
making reverse DNS lookups.
-->
DNS の逆引きを行わないようにするには、-n (numeric)オプションを入れて、
iptables をお使いください。
</sect1>

<sect1><!-- How do I stop the LOG target from logging to my console? -->
LOG ターゲットによるコンソールへのログ出力を止めさせるには
どうすればよいですか？
<p>
<!--
You have to configure your syslogd and/or klogd appropriately:
The LOG target logs to facility kern at priority warning (4).
See the syslogd.conf manpage to learn more about facilities and priorities.
-->
syslogd や klogd を適切に設定しなくてはなりません -
LOG ターゲットは、プライオリティ値 warning(4) で、ファシリティ値
kern のロギングを行います。
ファシリティ値とプライオリティ値についての詳細は、
syslogd.conf の man ページを参照してください。
<p>
<!--
By default, all kernel messages at priority more severe than debug (7)
are sent to the console. If you raise that to 4, instead of 7, you will
make the LOG messages no longer appear on the console.
-->
デフォルトでは、プライオリティ値が debug(7)
より重要なカーネルのメッセージがすべてコンソールに送られます。
この値を 7 から 4 まで上げれば、コンソール上に LOG
メッセージが表示されることはありません。

<p>
<!--
Be aware that this might also suppress other important messages from 
appearing on the console (does not affect syslog).
-->
こうすると、他の重要なメッセージもコンソールに表示されなく
なるかも知れません。気をつけてください
(syslog ファイルには影響しません)。

</sect1>

<sect1><!-- How do I build a transparent proxy using squid and iptables? -->
squid と iptables を使って透過型プロキシを構築するには
どうすればよいでしょう？
<p>
<!--
First, of course, you need a suitable DNAT or REDIRECT rule. Use REDIRECT
only if squid is running on the NAT box itself. Example:
-->
まず第一に、当然ながら、適切な DNAT か REDIRECT のルールが必要となります。
squid が NAT ボックス自身の上で動くなら、REDIRECT のみ使ってください。
例えば:
<tscreen><verb>
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128
</verb></tscreen>
<p>
<!--
After that, you have to configure squid appropriately. We can only give
short notes here, please refer to the squid documentation for further details.
-->
その後、squid を正しく設定しなくてはなりません。
我々がここで提供できる情報は限られていますので、
更に詳しい情報については、squid のドキュメントを参照ください。
<p>
<!--
The squid.conf for Squid 2.3 needs to be something like the following:
-->
Squid 2.3 での squid.conf に、以下のような設定が必要です:
<tscreen><verb>
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header on
</verb></tscreen>
<!--
Squid 2.4 needs an <bf>additional</bf> line added:
-->
Squid 2.4 になると、<bf>さらに</bf>設定行が必要になります:

<tscreen><verb>
httpd_accel_single_host off
</verb></tscreen>
</sect1>

<sect1><!-- How do I use the LOG target / How can i LOG and DROP? -->
LOG ターゲットはどのように使うのですか？
LOG と DROP を両方使うことはできますか？
<p>
<!--
The LOG target is what we call a "non-terminating target", i.e. it doesn't 
terminate the packets rule traversal.  If you use the LOG target, the packet
will be logged, and rule traversal continues at the next rule.
-->
LOG ターゲットは、いわゆる「終了しないターゲット」です。
つまりそれは、パケットがルールに適合しても、そこで終了しません。
LOG ターゲットを利用すると、パケットはロギングされ、
ルール適合の検索が次のルールに引き継がれます。

<p>
<!--
So how do I log and drop at the same time? Nothing easier than that, you
create a custom chain which contains the two rules:
-->
では、ログを取り、同時に破棄するにはどうすればよいのでしょう？
最も簡単なのは、二つのルールを含むチェインをあつらえることです:

<tscreen><verb>
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
</verb></tscreen>
<p>
<!--
Now everytime you want to log and drop a packet, you can easily use a
"-j logdrop".
-->
今後パケットをログに記録してから破棄したい場合は、
"-j logdrop" を使うだけですみます。

</sect1>

<sect1><!-- How do I stop worm XYZ with netfilter ? -->
XYZ ワームを netfilter で止めるにはどうしたらよいですか?
<p>
<!--
The short answer is you cannot do that properly with netfilter. Most of the worms are using
a legitimate high level protocol (i.e. HTTP, SMTP(i.e VB script attached in email), or any exploit
of a vulnerability found in the daemon handling the protocol). By high level protocol, we mean above TCP/IP.
As iptables does not understand these high level protocols, it's almost impossible to filter
part of them out properly. For that you need application filtering proxies.
-->
netfilter では確実に止めることはできない、というのが端的な回答になります。
大部分のワームは、正規の高レベルのプロトコル(つまり、HTTP や SMTP
(電子メールに VB スクリプトが添付される)や、そうしたプロトコルを
処理するデーモンに見つかった脆弱性を突くプログラム)を利用したものです。
ここでいう高レベルのプロトコルとは、TCP/IP よりも上の層にあるプロトコル
のことです。iptables はそうした高レベルのプロトコルを見ないので、
適切にフィルタリングするのはほとんど不可能です。それを行うには、
アプリケーション・プロキシ・フィルタリングが必要になります。
<p>
<!--
Please do not use the string target from patch-o-matic instead of application proxy filtering.
It would be defeated anytime by fragmented packets (i.e. an HTTP request split on two TCP packets),
by IDS evasion techniques, etc... you have been warned!
The string match is useful but for different purposes.
-->
アプリケーション・プロキシ・フィルタリングを行うかわりに、patch-o-matic
にある string ターゲットを使うのは止めて下さい。それだと、
フラグメントされたパケット(HTTP リクエストが二つの TCP
パケットに分割されるような場合)がきたり、IDS すり抜け技術をやられたり、
その他もろもろの場合に失敗してしまいます。警告はしましたよ!
string マッチは有用ですが、別の用途のためにあるのです。
</sect1>

<sect1>kernel logs: Out of window data xxx
<p>
<!--
You use the tcp-window-tracking patch from patch-o-matic, which code keeps
track the acceptable packets for the allowed TCP streams according to the
sequence/acknowledgement numbers, segment sizes, etc of the packets. When
it detects that one of the packets is not acceptable (out of the window),
it marks it as INVALID and prints the message above.
-->
あなたは patch-o-matic から tcp-window-tracking パッチを適用しています。
そのコードは、パケットのシーケンス／確認応答番号、
セグメント・サイズなどにより、許可された TCP ストリームに関して、
条件を満たしているパケットを追跡し続けます。
パケットの一つが条件を満たしていない(範囲外)のを検出すると、
そのパケットが無効であるとみなし、上記のメッセージを表示します。
<p>
<!--
Newer versions logs the packet and exactly what condition failed for it:
-->
新バージョンから、そのパケットと、その不適合の原因を正確に
記録するようにしています。
<itemize>
<item><!-- ACK is under the lower bound (possibly overly delayed ACK) -->
ACK 番号が下限を下回っている
(ひょっとすると、過度に遅延した ACK である可能性はある)
<item><!-- ACK is over the upper bound (ACKed data has never seen yet) -->
ACK 番号が上限を超えている(ACK 応答データがまだ届いていない)
<item><!-- SEQ is under the lower bound (retransmitted already ACKed data) -->
SEQ 番号が下限を下回っている(既に ACK 応答データが再送されている)
<item><!-- SEQ is over the upper bound (over the window of the receiver) -->
SEQ 番号が上限を超えている
(受信者のウィンドウ・サイズを超えている)
</itemize>
<p>
<!--
Also, in newer versions the logging can completely be suppressed via
sysctl
-->
また新バージョンでは、sysctl によりそのロギングを完全
に止めることも可能です。
<tscreen><verb>
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
</verb></tscreen>

<sect1><!-- Why does the connection tracking system track UNREPLIED connections with a high timeout? -->
何故、コネクション追跡システムは、UNREPLIED コネクションに大きな
タイムアウト値を割り当てて追跡しているのですか？

<p>
<!--
So you have read /proc/net/ip_conntrack and found UNREPLIED entries with a very high timer (can be up to five days) and are wondering why we want to waste conntrack entries with UNREPLIED entries (which are obviously not connections)?
-->
あなたは /proc/net/ip_conntrack を見て、UNREPLIED エントリに非常に大きな
タイマ値(最高で5日)が割り当てられているのに気付き、どうして我々が
(明らかにコネクションではない) UNREPLIED エントリに無駄に conntrack
エントリを使おうとするのかと不思議に思われたのですね?
<p>
<!--
The answer is easy: UNREPLIED entries are temporary entries, i.e. as soon as we
run out of connection tracking entries (we reach
/proc/sys/net/ipv4/ip_conntrack_max), we delete old UNREPLIED entries.  In other words: instead of having empty conntrack entries, we'd rather keep some maybe useful information in them until we really need them.
-->
その答えは簡単です: UNREPLIED エントリは、テンポラリなエントリだからです。
つまり、コネクション追跡エントリが限界まで来たらすぐに、古い UNREPLIED
エントリを削除します。言いかえると、conntrack を何も持たないよりは、
UNREPLIED エントリの中の有用かもしれない情報を、それが実際に必要
とするまで保持しておくのがよいだろうというわけです。
</sect1>

<sect1><!-- Why isn't the 'iptables -C' (&#045;&#045;check) option implemented? -->
なぜ 'iptables -C' (--check)オプションが実装されていないのですか?
<p>
<!--
Well, first of all, we're lazy ;).  To be honest, implementing a check option
is almost impossible as soon as you start to do stateful firewalling.
Traditional stateless firewalling bases it's decision just on information
present in the packets header.  But with connection tracking (and '-m state'
based rules), the outcome of the filtering decision depends on header+payload,
as well as header+payload of previous packets within this connection.
-->
えーと、つまるところ我々が怠惰だからです;) はっきり言って、
ステートフルなファイヤウォーリングを始めた時点で、
チェックオプションを実装するのがほとんど不可能になります。
伝統的なステートレスなファイヤウォーリングの場合、
フィルタリングを行うかどうかは、パケットヘッダにのっている情報
だけで決まります。しかし、コネクション追跡(や '-m state' ベースのルール)
を行う場合、フィルタリングを行うかどうかは、そのパケットのヘッダと
ペイロードの内容だけでなく、そのコネクションに以前流れたパケットの
ヘッダとペイロードの内容によっても変わります。
</sect1>

</sect>

<sect><!-- Questions about netfilter development -->
netfilter の開発に関する質問

<sect1><!-- I don't understand how to use the QUEUE target from userspace -->
ユーザ空間からの QUEUE ターゲットの使い方が分からないんです
<p>
<!--
A library called libipq is provided for userspace packet handling.
There is now documentation for this in the form of man pages.  You
need to build and install the iptables development components:
-->
libipq というライブラリが、ユーザ空間でのパケット操作のために提供
されています。これに関するドキュメントは、現在 man
ページの形式で存在します。iptables の開発コンポーネントをビルドし、
インストールする必要があります:
<tscreen><verb>
make install-devel
</verb></tscreen>

<!--
then see libipq(3).
-->
インストールしたら libipq(3) を参照ください。
<p>
<!--
You may also be interested in the Perl bindings for libipq, Perlipq at:
<url url="http://www.intercode.com.au/jmorris/perlipq/">.  The binding itself
is an example of using the library.
-->
libipq 用の Perl バインディングである、Perlipq
<url url="http://www.intercode.com.au/jmorris/perlipq/">
にも興味があるかもしれません。そのバインディング自身が、
ライブラリの利用の一例になります。
<p>
<!--
Other code examples include:
-->
その他のコード例として:

<itemize>
<item><!-- testsuite/tools/intercept.c from netfilter CVS -->
netfilter CVS にある、testsuite/tools/intercept.c
<item><!-- ipqmpd (see <url url="http://www.gnumonks.org/projects/">) -->
ipqmpd(<url url="http://www.gnumonks.org/projects/"> 参照)
<item><!-- nfqtest, part of netfilter-tools (see <url url="http://www.gnumonks.org/projects/">) -->
netfilter-tools の一部である、nfqtest(<url url="http://www.gnumonks.org/projects/"> 参照)
<item><!-- Jerome Etienne's WAN simulator (see <url url="http://www.off.net/~jme/">) -->
Jerome Etienne 作の WAN シミュレータ(<url url="http://www.off.net/~jme/"> 参照)
</itemize>

</sect1>

<sect1><!-- My libipq application says "Failed to received netlink message: No buffer space available" -->
うちの libipq アプリケーションが
"Failed to received netlink message: No buffer space available"
というメッセージを出すんです
<p>
<!--
This means that the kernel-side Netlink socket buffer ran out of space; the userspace
application is not able to handle the amount of data being delivered from the kernel.
-->
これは、カーネル側の Netlink ソケットバッファが領域不足に陥っています。
そうなると、ユーザスペースのアプリケーションは、
カーネルから届いたデータを全部は処理できません。
<p>
<!--
<quote><em>Is it possible to make those kernel buffers bigger so that I don't run into this problem?</em></quote>
-->
<quote><em>この問題を回避するためにカーネルバッファを今より大きく
することは可能ですか?
</em></quote>
<p>
<!--
Yes, these are standard Netlink sockets, and you can tune their receive 
buffer sizes via /proc/sys/net/core, sysctl, or use the SO_RCVBUF socket
option on the file descriptor. 
-->
はい、標準的な Netlink ソケットですので、/proc/sys/net/core に書きこんだり、
sysctl を実行したり、もしくはファイルディスクリプタにおいて SO_RCVBUF
ソケットオプションを利用することで受信バッファサイズを調整できます。
<p>
<!--
You can also try ensuring that your application is reading any received data as
quickly as possible.  If you don't need the entire packet, try copying less
data to userspace (see ipq_set_mode(3)).
-->
アプリケーションができるだけ高速に受信データを読むようにすることも可能です。
パケット全体が必要でないなら、ユーザスペースにコピーするデータサイズ
を小さくしてみましょう(ipq_set_mode(3) 参照)。
</sect1>

<sect1><!-- I want to contribute some code, but have no idea what to do -->
私はコードに貢献したいのですが、何をすれば良いか分かりません
<p>
<!--
The netfilter core-team keeps a TODO list where it lists all the desired
changes / new features. You can retrieve this list via anonymous CVS,
instructions are on the netfilter Homepage. Alternatively you can also go
to <url url="http://cvs.samba.org/cgi-bin/cvsweb/netfilter/TODO/"> using
CVSweb.
-->
netfilter コアチームは、望まれる変更や新機能の全てを一覧にした、
TODO リストを管理しています。このリストは anonymous CVS
経由で入手可能で、説明書は netfilter ホームページにあります。
あるいは、CVSweb を使って、
<url url="http://cvs.samba.org/cgi-bin/cvsweb/netfilter/TODO/">
から取得可能です。

</sect1>

<sect1><!-- I've fixed a bug or written an extension. How do I contribute it? -->
バグを修正したり、拡張部分を書きました。どうすればそれを寄贈できますか？
<p>
<!--
If you want to publish it, please send it to the netfilter-devel mailinglist.
Subscription instructions are at <url url="http://lists.samba.org/mailman/listinfo/netfilter-devel/">. 
-->
それを公開したい場合は、netfilter-devel メーリングリストまで送ってください。
購読に関する説明書は、
<url url="http://lists.samba.org/mailman/listinfo/netfilter-devel/">
にあります。

<!--
The correct way of sending a patch is the following :
-->
パッチを送る正しいやり方は、以下のようなものです:
<itemize>
<item> <!-- Subject starting with <bf>&#91;PATCH&#93;</bf> -->
Subject は、<bf>&#91;PATCH&#93;</bf> で始める
<item> <!-- Included straight in the body of the message, not MIME'd. -->
メッセージ本体に直接含め、MIME 化しない。
<item> <!-- a cvs-checkin/Changelog entry outside the diff. -->
diff 以外に、cvs-checkin/Changelog エントリをつける
<item> <!-- `diff -u old new' form, from outside root directory (ie. can be applied with -p1 when sitting in the untarred dir. -->
ルート・ディレクトリからの `diff -u old new' 形式にする
(つまり、他のディレクトリにいても、
-p1 オプションでパッチを適用できるように)

</itemize>

<p>
<!--
If you wrote a new extension, or added some new options to an old extension, it's usually
a good idea to also update the netfilter-extension-HOWTO to include that new extension/functionality description.
Additionally, it will draw more users to your extension, and will allow you to get more feedback in general.
-->
もしあなたが新しい拡張を書いたか、もしくは以前からある拡張
に新しいオプションを追加したなら、その新規の拡張/機能に関する
記述を入れて、netfilter-extension-HOWTO を更新するのも良い考えです。
そうすれば、より多くのユーザにあなたが書いた拡張を知らしめますし、
一般ユーザからのフィードバックをより得られるようになります。
</sect1>

</sect>

<!-- 以下、訳者による日本語訳についてのコメント -->
<sect>日本語訳について

<p>日本語訳は Linux Japanese FAQ Project が作成しました。
翻訳に関するご意見は JF プロジェクト &lt;JF@linux.or.jp&gt;
または、yomoyomo &lt;ymgrtq@ma.neweb.ne.jp&gt;
宛に連絡してください。

<p>本日本語訳について、誤訳・誤記の指摘をして下さった
つぎの方々に感謝します(50音順)。

<itemize>
<item>office さん &lt;office@office.ac&gt;
<item>小林雅典さん &lt;zap03216@nifty.ne.jp&gt;
<item>中野武雄さん &lt;nakano@apm.seikei.ac.jp&gt;
<item>水原文さん &lt;mizuhara@acm.org&gt;
<item>森本淳さん &lt;morimoto@xantia.citroen.org&gt;
<item>山森浩幸さん &lt;h-yamamo@db3.so-net.ne.jp&gt;
</itemize>

</sect>

</article>