<!doctype linuxdoctr system>

<!-- This is the Linux Packet Filtering HOWTO.
 -->

<!-- &dollar;Id: packet-filtering-HOWTO.sgml,v 1.24 2002/01/14 09:35:13 laforge Exp $ -->

<article>

<!-- Title information -->

<title>Linux 2.4 Packet Filtering HOWTO
<author>Rusty Russell, mailing list <tt>netfilter@lists.samba.org</tt>
<date>&dollar;Revision: 1.24 $ &dollar;Date: 2002/01/14 09:35:13 $

<trans>日本語訳: 山森 浩幸 (<tt>h-yamamo@db3.so-net.ne.jp</tt>)
<tdate>v1.24j  Jan. 20, 2002

<abstract>
<!--
This document describes how to use iptables to filter out bad packets
for the 2.4 Linux kernels.
-->
この文書は、2.4系 Linux カーネルにおける、不当なパケットをフィルターアウト
する iptables の使い方について述べています。
</abstract>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->

<!--
<sect>Introduction<label id="intro">
-->
<sect>はじめに<label id="intro">

<p>
<!--
Welcome, gentle reader.
-->
ようこそ、読者のみなさん。

<p>
<!--
It is assumed you know what an IP address, a network address, a
netmask, routing and DNS are.  If not, I recommend that you read the
Network Concepts HOWTO.
-->
ここでは、IP アドレス、ネットワークアドレス、ネットマスク、ルーティング
そして DNS が何であるか知っていることを前提にしています。もし、分からない
のであれば、Network Concepts HOWTO (訳注: この文書の原文が
公開されている場所にある Linux Networking-concepts HOWTO)
を読むことをお勧めします。

<p>
<!--
This HOWTO flips between a gentle introduction (which will leave you
feeling warm and fuzzy now, but unprotected in the Real World) and raw
full-disclosure (which would leave all but the hardiest souls
confused, paranoid and seeking heavy weaponry).
-->
この HOWTO は 2つの顔を持っています。やさしい入門書風の箇所では、読者を
何となく安心させますが、現実世界の厳しさには気付かないままです。
しかし、細部までむき出しにして隠さずに伝えようとする箇所では、徹底理解
に勤めない読者を混乱させ、不安にし、徹底武装させてしまうことでしょう。

<p>
<!--
Your network is not <bf>secure</bf>.  The problem of allowing rapid,
convenient communication while restricting its use to good, and not
evil intents is congruent to other intractable problems such as
allowing free speech while disallowing a call of ``Fire!'' in a
crowded theater.  It will not be solved in the space of this HOWTO.
-->
あなたのネットワークは決して<bf>安全</bf>ではありません。高速で
便利な通信を確保して、それを善良な利用者にだけ提供し、しかも悪意
のある者を締め出そうと言うのは、数ある手に負えない問題の 1つです。
例えば、言論の自由を保証しながらも満員の映画館で「火事だー！」など
と叫び出す危険な言動を禁じようとするのと同じことです。
この HOWTO では、そうした問題の解決方法についてまで解説するスペース
はありません。
<!-- 第１文は読者に注意を向けていると考え直訳風のままにしました。
 rapid は高速なのか手間いらずなのか分かりません。-->

<p>
<!--
So only you can decide where the compromise will be.  I will try to
instruct you in the use of some of the tools available and some
vulnerabilities to be aware of, in the hope that you will use them for
good, and not evil purposes.  Another equivalent problem.
-->
ですから、どこで妥協するかを決められるのは、あなた自身だけなのです。
以下では、有効ないくつかのツールを紹介し、知っておくべき弱点などを
注意していきます。これらを悪用することなく、正しい目的のために使って
ください。このような話をすること自体も、悪用の可能性が残ってしまう
問題の一例ですね。
<!-- 第２文: available だが vulnerabilities と考えました。-->

<p>(C) 2000 Paul `Rusty' Russell.  Licenced under the GNU GPL.

<!--
<sect>Where is the official Web Site?  Is there a Mailing List?
-->
<sect>公式ウェブサイトはどこにありますか? メーリングリストはありますか?
<label id="website">

<!--
<p>There are three official sites:
-->
<p>3つの公式サイトがあります:
<itemize>
<!--
<item>Thanks to <url url="http://netfilter.filewatcher.org/" name="Filewatcher">.
<item>Thanks to <url url="http://netfilter.samba.org/" name="The Samba Team and SGI">.
<item>Thanks to <url url="http://netfilter.gnumonks.org/" name="Harald Welte">.
-->
<item><url url="http://netfilter.filewatcher.org/" name="Filewatcher">
に感謝します。
<item><url url="http://netfilter.samba.org/" name="Samba チームと SGI">
に感謝します。
<item><url url="http://netfilter.gnumonks.org/" name="Harald Welte">
に感謝します。
</itemize>
<!--
<p> You can reach all of them using round-robin DNS via
<url url="http://www.netfilter.org/"> and <url url="http://www.iptables.org">
-->
<p>上記全ては
<url url="http://www.netfilter.org/"> と <url url="http://www.iptables.org/">
から、ラウンドロビン DNS を参照して到達できます。

<!--
<p>For the official netfilter mailing list, see
-->
<p>公式 netfilter メーリングリストはこちら:
<!--
<url url="http://www.netfilter.org/contact.html#list"> name="netfilter List">.
-->
<url url="http://www.netfilter.org/contact.html#list" name="netfilter リスト">
を見てください。

<!--
<sect>So What's A Packet Filter?
-->
<sect>それで、パケットフィルターって何ですか?

<p>
<!--
A packet filter is a piece of software which looks at the
<em>header</em> of packets as they pass through, and decides the fate
of the entire packet.  It might decide to <bf>DROP</bf> the packet
(i.e., discard the packet as if it had never received it),
<bf>ACCEPT</bf> the packet (i.e., let the packet go through), or
something more complicated.
-->
パケットフィルターというのは、流れて行くパケットの<em>ヘッダー</em>
を読んで、そのパケットの運命を決めるソフトウェアです。
パケットを <bf>DROP</bf>(まるで受け取っていないかのように破棄)したり、
<bf>ACCEPT</bf> (パケットを通過させる)したり、設定によっては
もっと複雑な処理をしたりします。
<!-- やはり原文に近くなるようにしました。-->

<p>
<!--
Under Linux, packet filtering is built into the kernel (as a kernel
module, or built right in), and there are a few trickier things we can
do with packets, but the general principle of looking at the headers
and deciding the fate of the packet is still there.
-->
Linux において、パケットフィルタリングはカーネルに組み込まれて
(カーネルモジュールとして、または直に組み込まれて)います。
パケットに対して多少の曲芸的なこともできますが、パケットのヘッダー
を見てその運命を決定すると言う一般原則が常にあります。

<!--
<sect1>Why Would I Want to Packet Filter?
-->
<sect1>なぜ、パケットフィルターが必要なのでしょう?

<p>
<!--
Control.  Security.  Watchfulness.
-->
コントロール。セキュリティ。監視。

<p>
<descrip>
<!--
<tag/Control:/ when you are using a Linux box to connect your internal
network to another network (say, the Internet) you have an opportunity
to allow certain types of traffic, and disallow others.  For example,
the header of a packet contains the destination address of the packet,
so you can prevent packets going to a certain part of the outside
network.  As another example, I use Netscape to access the Dilbert
archives.  There are advertisements from doubleclick.net on the page,
and Netscape wastes my time by cheerfully downloading them.
Telling the packet filter not to allow any packets to or from the
addresses owned by doubleclick.net solves that problem (there are
better ways of doing this though: see Junkbuster).
-->
<tag/コントロール:/あなたが Linux ボックスを内部のネットワークと別の
ネットワーク(例えば、インターネット)を繋ぐために使っているなら、
あなたには、特定のトラフィックだけ許可して、他のものを許さないように
するチャンスがあります。例えば、パケットのヘッダーにはあて先アドレス
が含まれていて、外部ネットワークのとある所へ向かうパケットを拒否する
ことができます。別の例として、Netscape を使って Dilbert のアーカイブ
(訳注: Dilbert というエンジニアが主人公の風刺漫画のサイト、ちなみに
dilbert の意味は‘ばか’)
にアクセスする場合です。ページには doubleclick.net の広告があり、
Netscape はそれをいそいそとダウンロードするために私の時間を浪費します。
パケットフィルターに doubleclick.net 所有のアドレスからのどんな
パケットも許可しないように指示すれば問題は解決します(もっといい方法が
ありますけれど: Junkbuster(訳注: http://internet.junkbuster.com) を
見てください)。
<!-- destination の訳として、送信先、終点、などありますが、
  あて先としました。-->

<!--
<tag/Security:/ when your Linux box is the only thing between the
chaos of the Internet and your nice, orderly network, it's nice to
know you can restrict what comes tromping in your door.  For example,
you might allow anything to go out from your network, but you might be
worried about the well-known `Ping of Death' coming in from malicious
outsiders.  As another example, you might not want outsiders
telnetting to your Linux box, even though all your accounts have
passwords.  Maybe you want (like most people) to be an observer on the
Internet, and not a server (willing or otherwise).  Simply don't let
anyone connect in, by having the packet filter reject incoming packets
used to set up connections.
-->
<tag/セキュリティ:/あなたの Linux ボックスがインターネットの混沌と、
ナイスで秩序正しいあなたのネットワークの間にある唯一の物なら、
すばらしいことに、あなたは殴りにやって来る者をドアのところで制限する
ことができます。例えば、あなたのネットワークから出て行くものは何でも
許すようにして、悪意のある外部からのよく知られた `Ping of Death' 攻撃
を気に掛けるようにできます。別の例として、あなたの Linux ボックスに、
たとえ全てのアカウントにパスワードが付いているとしても、外部の者が
telnet してくることを望まないかもしれません。たぶん、あなたは
(たいていの人々のように)インターネットをただ眺めていたいだけで、
サーバーに(好むと好まずにかかわらず)なりたくないのです。単純に、
パケットフィルターで接続を開始するパケットの流入を拒否して、だれにも
接続されないようにしてください。

<!--
<tag/Watchfulness:/ sometimes a badly configured machine on the local
network will decide to spew packets to the outside world.  It's nice
to tell the packet filter to let you know if anything abnormal occurs;
maybe you can do something about it, or maybe you're just curious by
nature.
-->
<tag/監視:/ときどきローカルネットワーク中に環境設定の悪いマシンがあり、
外の世界にパケットが漏れ出るようになっていることがあります。
すばらしいことに、パケットフィルターは何か異常なことが起こったときに
あなたに知らせてくれます。たぶんあなたは何らかの対処ができるでしょうし、
あるいはあなたの性質上、単に興味を持つだけかもしれません。
</descrip>

<!--
<sect1>How Do I Packet Filter Under Linux?<label id="filter-linux">
-->
<sect1>Linux でパケットフィルターはどのようにやるの?<label id="filter-linux">

<!--
<p>Linux kernels have had packet filtering since the 1.1 series.  The
first generation, based on ipfw from BSD, was ported by Alan Cox in
late 1994.  This was enhanced by Jos Vos and others for Linux 2.0; the
userspace tool `ipfwadm' controlled the kernel filtering rules.  In
mid-1998, for Linux 2.2, I reworked the kernel quite heavily, with the
help of Michael Neuling, and introduced the userspace tool `ipchains'.
Finally, the fourth-generation tool, `iptables', and another kernel
rewrite occurred in mid-1999 for Linux 2.4.  It is this iptables which
this HOWTO concentrates on.
-->
<p>Linux カーネルには 1.1系からパケットフィルタリングがありました。
第1世代は、1994年後期に Alan Cox により、BSD の ipfw を基礎にして
移植されました。Linux 2.0 では、Jos Vos を初めとする人達により拡張
され、カーネルのフィルタリングルールをコントロールするユーザ空間ツール
`ipfwadm' が生まれました。1998年中期、Linux 2.2 では、私は
Michael Neuling の援助を得てカーネルを全くどっさりと作り直し、
ユーザ空間ツール `ipchains' を導入しました。最終的に、1999年中期、
Linux 2.4 では、第4世代ツール `iptables' とカーネルの別の部分を
書き換えました。この HOWTO が集中して述べているのはこの iptables
についてです。

<p>
<!--
You need a kernel which has the netfilter infrastructure in it:
netfilter is a general framework inside the Linux kernel which other
things (such as the iptables module) can plug into.  This means you
need kernel 2.3.15 or beyond, and answer `Y' to CONFIG_NETFILTER in
the kernel configuration.
-->
netfilter という基盤を持ったカーネルが必要です ― Linux カーネル
には追加機能(例えば iptables モジュール)を差し込むことができますが、
netfilter はこの一般的な枠組みの中に含まれています。これは、
カーネル 2.3.15 かそれ以降が必要で、カーネルコンフィギュレーション
の CONFIG_NETFILTER に `Y' と答える必要があります。

<p>
<!--
The tool <tt>iptables</tt> talks to the kernel and tells it what
packets to filter.  Unless you are a programmer, or overly curious,
this is how you will control the packet filtering.
-->
<tt>iptables</tt> というツールは、カーネルに話かけて、カーネルがどの
パケットをフィルターすべきかを伝えるものです。プログラマーや特に好奇心
旺盛な人は別ですが、普通はこれを使ってパケットフィルターをコントロール
します。

<sect2> iptables

<p>
<!--
The <tt>iptables</tt> tool inserts and deletes rules from the kernel's
packet filtering table.  This means that whatever you set up, it will
be lost upon reboot; see <ref id="permanent" name="Making Rules
Permanent"> for how to make sure they are restored the next time Linux
is booted.
-->
iptables はカーネルのパケットフィルタリングテーブルにルールを挿入
したり削除したりします。これは、あなたが設定したものはリブートすると
失われることを意味しています。次回、Linux がブートしたとき設定を
回復させる確かな方法は <ref id="permanent" name="ルールを永続させる">
を見てください。

<p>
<!--
<tt>iptables</tt> is a replacement for <tt>ipfwadm</tt> and
<tt>ipchains</tt>: see
<ref id="oldstyle" name="Using ipchains and ipfwadm"> for how to painlessly
avoid using iptables if you're using one of those tools.
-->
<tt>iptables</tt> は ipfwadm と ipchains の置き換えです。
もし、あなたが現在これらのどちらか一方のツールを使っていて、
苦労を避けるため iptables を使わずに済ます方法は
<ref id="oldstyle" name="ipchains と ipfwadm を使う"> を見てください。

<!--
<sect2> Making Rules Permanent<label id="permanent">
-->
<sect2>ルールを永続させる<label id="permanent">

<!--
<p>Your current firewall setup is stored in the kernel, and thus will
be lost on reboot.  You can try the iptables-save and iptables-restore
scripts to save them to, and restore them from a file.
-->
<p>あなたの現在のファイアーウォールの設定はカーネル中にあるだけなので、
リブートすると失われてしまいます。iptables-save と iptables-restore
スクリプトを使えば、設定をファイルに保存しておき、その後、そのファイル
から回復することができます。

<!--
<p>The other way is to put the commands required to set up your rules
in an initialization script.  Make sure you do something intelligent
if one of the commands should fail (usually `exec /sbin/sulogin').
-->
<p>別の方法は、ルールを設定するために必要なコマンドを初期化
スクリプト中に書くことです。万一コマンドの内の 1つが失敗したなら、
頭を絞ってやろうとしていることを確かめてください(普通、`/sbin/sulogin'
を実行してシングルユーザモードで作業します)。
<!-- カッコのことはシングルユーザモードで作業しなさい、と言うことか? -->

<!--
<sect>Who the hell are you, and why are you playing with my kernel?
-->
<sect>いったいおまえは誰なんだ、そしてなぜ私のカーネルで遊んでるんだ?

<p>
<!--
I'm Rusty Russell; the Linux IP Firewall maintainer and just another
working coder who happened to be in the right place at the right time.
I wrote ipchains (see <ref id="filter-linux" name="How Do I Packet
Filter Under Linux?"> above for due credit to the people who did the
actual work), and learnt enough to get packet filtering right this
time.  I hope.
-->
私は Rusty Russell。Linux の IP ファイアーウォールのメインテナーと、ほんの
もう 1つ、別の箇所のコーディングを担当していますが、それはたまたま
適切な時期に適切な場所にいたからにすぎません。私は ipchains を書きました
(実際に作業した人々に称賛をはらい、<ref id="filter-linux" name="Linux
でパケットフィルターはどのようにやるの?"> を見てください)。そして
このときパケットフィルタリングの正しいあり方を十分に学びました。
そうあることを望んでいます。

<p>
<!--
<url url="http://www.watchguard.com" name="WatchGuard">, an excellent
firewall company who sell the really nice plug-in Firebox, offered to
pay me to do nothing, so I could spend all my time writing this stuff,
and maintaining my previous stuff.  I predicted 6 months, and it took
12, but I felt by the end that it had been done Right.  Many rewrites,
a hard-drive crash, a laptop being stolen, a couple of corrupted
filesystems and one broken screen later, here it is.
-->
<url url="http://www.watchguard.com" name="WatchGuard">、本当にナイスな
プラグインの Firebox (訳注: Linux 内蔵のファイアーウォール製品)を
売っているすばらしいファイアーウォールの会社で、何もしない私に給料を
払ってくれて、それで私は全ての時間をこのしろものを書くことに、そして
以前のもののメンテナンスに費やすことができました。私は 6か月と予測
して、12か月かかりましたが、それを適切なものにすると言う目的を
果たせたと感じました。多くの書き直し、ハードディスクのクラッシュ、
ラップトップの盗難、ファイルシステム不正に続けてスクリーンの故障、
がありました。
<!-- ラップトップなのでスクリーン? -->

<p>
<!--
While I'm here, I want to clear up some people's misconceptions: I am
no kernel guru.  I know this, because my kernel work has brought me
into contact with some of them: David S. Miller, Alexey Kuznetsov,
Andi Kleen, Alan Cox.  However, they're all busy doing the deep magic,
leaving me to wade in the shallow end where it's safe.
-->
私がここにいる間に、何人かの人々の誤解を解いておきたいです ― 私は
カーネルの神様ではありません。と言うのは、私はカーネルの仕事をするのに
彼ら: David S. Miller, Alexey Kuznetsov, Andi Kleen, Alan Cox の何人
かと接触することになったからです。とは言え、彼らは皆底深いマジックを
するのに忙しくて、私はかまってもらえず安全な浅い川の縁を苦労して進んで
います。

<!-- This is probably no longer true; somewhere in writing all this
kernel code and documentation I seem to have picked up a fair number
of kernel tricks.  But I'm still nowhere near as clever as I think I
am. -->
<!-- (訳注: 原文もコメント) たぶん、これはもはや本当ではないです ―
このカーネルコード全てやドキュメントを書いているとき、どこかに
私はかなりの数のカーネルトリックを見つけました。
しかし、私はまだまだ賢いと言うにはほど遠いです。
-->

<!--
<sect> Rusty's Really Quick Guide To Packet Filtering
-->
<sect>Rusty のパケットフィルタリング、本当にクイックガイド

<p>
<!--
Most people just have a single PPP connection to the Internet, and
don't want anyone coming back into their network, or the firewall:
-->
ほとんどの人はインターネットにただ 1つの PPP コネクションで繋いで
いますが、そこから自分のネットワークに誰かが入ってくることを望む
人は誰もいません。すなわちファイアーウォールの出番です。

<!--
<tscreen><verb>
## Insert connection-tracking modules (not needed if built into kernel).
# insmod ip_conntrack
# insmod ip_conntrack_ftp

## Create chain which blocks new connections, except if coming from inside.
# iptables -N block
# iptables -A block -m state -&#045;state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state -&#045;state NEW -i ! ppp0 -j ACCEPT
# iptables -A block -j DROP

## Jump to that chain from INPUT and FORWARD chains.
# iptables -A INPUT -j block
# iptables -A FORWARD -j block
</verb></tscreen>
-->
<tscreen><verb>
## コネクション追跡モジュールの挿入(カーネル直組み込みの場合は不要)
# insmod ip_conntrack
# insmod ip_conntrack_ftp

## 内部からのもの以外の新しいコネクションをブロックするチェインの作成
# iptables -N block
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
# iptables -A block -j DROP

## INPUT および FORWARD チェインから上記のチェインへジャンプする
# iptables -A INPUT -j block
# iptables -A FORWARD -j block
</verb></tscreen>
<!-- block の訳は、遮る、妨げる、などがありますが、ブロックで通じる
  と思いますので。-->

<!--
<sect> How Packets Traverse The Filters
-->
<sect>どのようにパケットはフィルターを通り抜けるか

<p>
<!--
The kernel starts with three lists of rules in the `filter' table;
these lists are called <bf>firewall chains</bf> or just
<bf>chains</bf>.  The three chains are called <bf>INPUT</bf>,
<bf>OUTPUT</bf> and <bf>FORWARD</bf>.
-->
カーネルは起動時に `filter' テーブルという所に 3つのルールリストを
保持しています。これらのリストは<bf>ファイアーウォールチェイン</bf>、
または単に<bf>チェイン</bf>と呼ばれます。3つのチェインは
<bf>INPUT</bf>, <bf>OUTPUT</bf> そして <bf>FORWARD</bf> と呼ばれて
います。

<p>
<!--
For ASCII-art fans, the chains are arranged like so: <bf>(Note: this
is a very different arrangement from the 2.0 and 2.2 kernels!)</bf>
-->
ASCII アートファンのために、チェインはこのように配置されています 
<bf>(これは、2.0 および 2.2 カーネルの配置と大変異なっています!)</bf> :
<!--
<verb>
                          _____
Incoming                 /     \         Outgoing
       -&#045;>[Routing ]-&#045;->|FORWARD|-&#045;-&#045;-&#045;->
          [Decision]     \_____/        ^
               |                        |
               v                       ____
              ___                     /    \
             /   \ 	            |OUTPUT|
            |INPUT|	             \____/
             \___/                      ^
               |                        |
                -&#045;-&#045;> Local Process -&#045;-&#045;
-->
<verb>

入って来る┌──────┐   ／￣￣￣＼        出て行く
      ―→│ルーティング│→｜FORWARD ｜――→
          │の決定      │   ＼＿＿＿／         ↑
          └──────┘                      │
                   │                           │
                   ↓                        ／￣￣＼
                ／￣￣＼                    ｜OUTPUT｜
               ｜INPUT ｜                    ＼＿＿／
                ＼＿＿／                        ↑
                   │                           │
                   └─→ ローカル プロセス ──┘
</verb>
<!-- JIS アートにしました。元の絵でコメント中の連続ハイフンは -＆＃045；
に置き換えました。-->
(訳注: この他に NAT 用のチェインとして、‘ルーティングの決定’の手前に
`PREROUTING' チェインが、‘出て行く’の手前に `POSTROUTING' チェインが
あります。)

<!--
<p>The three circles represent the three chains mentioned above.  When
a packet reaches a circle in the diagram, that chain is examined to
decide the fate of the packet.  If the chain says to DROP the packet,
it is killed there, but if the chain says to ACCEPT the packet, it
continues traversing the diagram.
-->
<p>3つの円は、上で述べた 3つのチェインを表わしています。パケットが図上
の 1つの円に達したら、そのチェインが検査されてパケットの運命を決めます。
もし、チェインがパケットを DROP(破棄)すると言ったら、パケットはそこで
抹殺されますが、もし、チェインがパケットを ACCEPT(受け入れ)すると言ったら、
パケットは図上を移って行きます。

<p>
<!--
A chain is a checklist of <bf>rules</bf>.  Each rule says `if the packet
header looks like this, then here's what to do with the packet'.  If
the rule doesn't match the packet, then the next rule in the chain is
consulted.  Finally, if there are no more rules to consult, then the
kernel looks at the chain <bf>policy</bf> to decide what to do.  In a
security-conscious system, this policy usually tells the kernel to
DROP the packet.
-->
1つのチェインは複数の<bf>ルール</bf>のチェックリストから構成されて
います。各々のルールは「もし、パケットのヘッダーがこんなだったら、
パケットをこのようにしなさい」と指示します。もし、あるルールがパケット
とマッチしなければ、チェイン内の次のルールが調べられます。最終的に、
調べるルールが無くなったら、カーネルはそのチェインの<bf>ポリシー</bf>
(方針)を見て何をするか決めます。セキュリティ意識の強いシステムでは、
このポリシーは普通、パケットを DROP するようにカーネルに指示します。

<p>
<enum>
<!--
<item>When a packet comes in (say, through the Ethernet card) the kernel
first looks at the destination of the packet: this is called
`routing'.
-->
<item>パケットが入って来たとき(例えば、イーサネットカードから)、
カーネルは最初にパケットの行き先を見ます。これは‘ルーティング’
と呼ばれます。

<!--
<item>If it's destined for this box, the packet passes downwards
in the diagram, to the INPUT chain.  If it passes this, any processes
waiting for that packet will receive it.
-->
<item>もし、行き先が自分の Linux ボックスなら、パケットは図では下に
降りて INPUT チェインに入ります。もし、そこを通過すれば、パケットは
それを待っているプロセスに受け取られます。

<!--
<item>Otherwise, if the kernel does not have forwarding enabled, or it
doesn't know how to forward the packet, the packet is dropped.  If
forwarding is enabled, and the packet is destined for another network
interface (if you have another one), then the packet goes rightwards
on our diagram to the FORWARD chain.  If it is ACCEPTed, it will be
sent out.
-->
<item>そうでないなら、カーネルのフォワード(転送)機能が有効に
なっていない場合、あるいはカーネルがそのパケットのフォワードの方法を
知らない場合、パケットは破棄されます。フォワード機能が有効になっていて、
パケットの行き先が別のネットワークインターフェイス(もう
1つあるなら)であれば、図ではパケットは右の方へ進み FORWARD チェイン
に入ります。もし、ACCEPT されれば、パケットは送り出されます。
<!-- くどいので  もし、 を取りました。-->

<!--
<item>Finally, a program running on the box can send network packets.
These packets pass through the OUTPUT chain immediately: if it says
ACCEPT, then the packet continues out to whatever interface it is
destined for.
-->
<item>最後になりますが、この箱で動いているプログラムは
ネットワークへパケットを送ることができます。これらのパケットは
直接 OUTPUT チェインに入ります。もし、そこで ACCEPT と言われれば、
パケットはその行き先に従ったインターフェイスから出て行きます。
</enum>

<!--
<sect>Using iptables
-->
<sect>iptables を使う

<p>
<!--
iptables has a fairly detailed manual page (<tt>man iptables</tt>),
and if you need more detail on particulars.  Those of you familiar
with ipchains may simply want to look at <ref id="Appendix-A"
name="Differences Between iptables and ipchains">; they are very
similar.
-->
個々の事項についてのもっと詳しい説明が必要なら、iptables にはかなり
詳しいマニュアルページ(<tt>man iptables</tt>)があります。
ipchains に精通している人はすぐにでも<ref id="Appendix-A" name=
"iptables と ipchains の違い">を見たいにちがいありません。実際、
2つはとても似ています。

<p>
<!--
There are several different things you can do with <tt>iptables</tt>.
You start with three built-in chains <tt>INPUT</tt>, <tt>OUTPUT</tt>
and <tt>FORWARD</tt> which you can't delete.  Let's look at the
operations to manage whole chains:
-->
<tt>iptables</tt> を使って色々なことができます。
まず、3つの組み込み済みチェイン <tt>INPUT</tt>, <tt>OUTPUT</tt>
そして <tt>FORWARD</tt> (これらは削除できません)から始めます。
では、チェインを扱う操作を見てみましょう:

<enum>
<!--
<item> Create a new chain (-N).
<item> Delete an empty chain (-X).
<item> Change the policy for a built-in chain. (-P).
<item> List the rules in a chain (-L).
<item> Flush the rules out of a chain (-F).
<item> Zero the packet and byte counters on all rules in a chain (-Z).
-->
<item>新しいチェインを作る (-N)
<item>空のチェインを削除する (-X)
<item>組み込み済みチェインのポリシーを変更する (-P)
<item>チェイン内のルールをリストアップする (-L)
<item>チェインからルールを全て消し去る (-F)
<item>チェイン内の全てのルールのパケットとバイトのカウンターをゼロにする (-Z)
</enum>

<!--
There are several ways to manipulate rules inside a chain:
-->
チェイン内のルールを操作するには様々な方法があります:

<enum>
<!--
<item> Append a new rule to a chain (-A).
<item> Insert a new rule at some position in a chain (-I).
<item> Replace a rule at some position in a chain (-R).
<item> Delete a rule at some position in a chain, or the first that matches (-D).
-->
<item>チェインに新しいルールを追加する (-A)
<item>チェイン内のある位置に新しいルールを挿入する (-I)
<item>チェイン内のある位置のルールを置き換える (-R)
<item>チェイン内のある位置の、または記述と一致した最初のルールを削除する (-D)
</enum>

<!--
<sect1> What You'll See When Your Computer Starts Up
-->
<sect1>コンピュータを起動したとき見るべきこと

<p>
<!--
iptables may be a module, called (`iptable_filter.o'), which should be
automatically loaded when you first run <tt>iptables</tt>.  It can
also be built into the kernel permenantly.
-->
iptables はたぶんモジュールになっています。名前は(`iptable_filter.o')
で、最初に <tt>iptables</tt> を実行したときに自動的に
ロードされるはずです。また、カーネルに恒常的に組み込むこともできます。

<!--
<p>Before any iptables commands have been run (be careful: some
distributions will run iptables in their initialization scripts),
there will be no rules in any of the built-in chains (`INPUT',
`FORWARD' and `OUTPUT'), all the chains will have a policy of ACCEPT.
You can alter the default policy of the FORWARD chain by providing the
`forward=0' option to the iptable_filter module.
-->
<p>全く iptables コマンドを実行していない状態では(注意しましょう:
初期化スクリプトで iptables を実行するディストリビューションがあります)、
組み込み済みチェイン(`INPUT', `FORWARD' および `OUTPUT')のどれにも
ルールは存在せず、全てのチェインのポリシーは ACCEPT です。
しかし、iptable_filter モジュールのオプションに `forward=0' を与えれば、
FORWARD チェインのポリシーの初期値を(訳注: DROP に)変えることができます。
<!-- しかし を追加 -->

<!--
<sect1> Operations on a Single Rule
-->
<sect1>ルールの操作
<!-- 他の見出しとのバランスから Single を省略しました。-->

<p>
<!--
This is the bread-and-butter of packet filtering; manipulating rules.
Most commonly, you will probably use the append (-A) and delete (-D)
commands.  The others (-I for insert and -R for replace) are simple
extensions of these concepts.
-->
ルールを操作すること ― それはパケットフィルタリングの基本です。
ほとんどの場合、普通、あなたは追加 (-A) と削除 (-D) コマンドを使うこと
になるでしょう。残りのコマンド(挿入の -I と置換の -R )はこれらの概念を
単純に延長したものです。
<!-- bread-and-butter の訳は イロハ でもよいかもしれませんが、
  基本 にしました。-->

<p>
<!--
Each rule specifies a set of conditions the packet must meet, and what
to do if it meets them (a `target').  For example, you might want to
drop all ICMP packets coming from the IP address 127.0.0.1.  So in
this case our conditions are that the protocol must be ICMP and that
the source address must be 127.0.0.1.  Our target is `DROP'.
-->
各々のルールには、パケットが満たすべき条件のセットと、条件が満たされた
ときにすること(‘ターゲット’)を指定します。例えば、IP アドレス 127.0.0.1
からやって来る全ての ICMP パケットを破棄したいとします。その場合の条件は
プロトコルが ICMP でソースアドレスが 127.0.0.1 で、ターゲットは `DROP'
です。
<!-- source の訳として、発信元、送信元、始点などがありますが、
  カタカナで十分通じると思われるので、ここではソースとします。-->

<p>
<!--
127.0.0.1 is the `loopback' interface, which you will have even if you
have no real network connection.  You can use the `ping' program to
generate such packets (it simply sends an ICMP type 8 (echo request)
which all cooperative hosts should obligingly respond to with an ICMP
type 0 (echo reply) packet).  This makes it useful for testing.
-->
127.0.0.1 は‘ループバック’インターフェイスで、それはあなたのマシンが
実際のネットワークに繋がっていなくても存在します。`ping' プログラムは
そのようなパケットを発生させるのに使います(ping は 単純に ICMP タイプ
8 (エコー要求)を送り、全ての協力的なホストは親切にも ICMP タイプ 0
(エコー応答)のパケットでそれに応えます)。これはテストに役立ちます。
<!-- loopback は英語のままとカタカナのどちらがよいでしょう? --> 

<tscreen><verb>
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#
</verb></tscreen>

<!--
You can see here that the first ping succeeds (the `-c 1' tells ping
to only send a single packet).
-->
ご覧のとおり最初の ping が成功しています(`-c 1' は ping にパケットを
1個だけ送るように指示しています)。

<p>
<!--
Then we append (-A) to the `INPUT' chain, a rule specifying that for
packets from 127.0.0.1 (`-s 127.0.0.1') with protocol ICMP (`-p icmp')
we should jump to DROP (`-j DROP').
-->
次にルールを `INPUT' チェインに追加 (-A) します。ルールの指定は、
127.0.0.1 から (`-s 127.0.0.1') でプロトコル ICMP (`-p icmp')
のパケットは、DROP へジャンプする (`-j DROP') です。

<p>
<!--
Then we test our rule, using the second ping.  There will be a pause
before the program gives up waiting for a response that will never
come.
-->
それから 2番目の ping でルールをテストします。帰って来ない応答を待つのを
ping が止めるまで少しの間があるでしょう。

<p>
<!--
We can delete the rule in one of two ways.  Firstly, since we know
that it is the only rule in the input chain, we can use a numbered
delete, as in:
-->
ルールを削除するには 2通りの方法があります。1番目は、例えば、input
チェインにはルールが 1個だけしかないのを分っている場合では、番号を
使って以下のように削除できます:
<tscreen><verb>
	# iptables -D INPUT 1
	#
</verb></tscreen>
<!--
To delete rule number 1 in the INPUT chain.
-->
INPUT チェインのルール番号 1 を削除。

<p>
<!--
The second way is to mirror the -A command, but replacing the -A with
-D.  This is useful when you have a complex chain of rules and you
don't want to have to count them to figure out that it's rule 37 that
you want to get rid of.  In this case, we would use:
-->
2番目の方法は -A コマンドをそっくり写して -A を -D に置き換えたものです。
これはルールが複雑なチェインの場合で、例えば、取り除きたいのがルール
37 だと探し当てるためにルールを数えたくない場合に有効です。この場合、
次のように使います:
<tscreen><verb>
	# iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP
	#
</verb></tscreen>
<!--
The syntax of -D must have exactly the same options as the -A (or -I
or -R) command.  If there are multiple identical rules in the same
chain, only the first will be deleted.
-->
-D の書き方は、-A (または -I か -R) コマンドのときと正確に同じ
オプションでなければなりません。もし、同一チェイン中に複数のマッチ
するルールがあったら、最初のだけが削除されます。

<!--
<sect1>Filtering Specifications
-->
<sect1>フィルタリングの仕様

<p>
<!--
We have seen the use of `-p' to specify protocol, and `-s' to specify
source address, but there are other options we can use to specify
packet characteristics.  What follows is an exhaustive compendium.
-->
これまでに、プロトコルを指定する `-p' オプションと、ソースアドレスを
指定する `-s' オプションを見てきましたが、この他にもパケットの特徴を
指定する様々なオプションがあります。これから、その概要をあますところなく
お話します。

<!--
<sect2>Specifying Source and Destination IP Addresses
-->
<sect2>ソースとあて先 IP アドレスの指定

<p>
<!--
Source (`-s', `-&#045;source' or `-&#045;src') and destination (`-d',
`-&#045;destination' or `-&#045;dst') IP addresses can be specified in four
ways.  The most common way is to use the full name, such as
`localhost' or `www.linuxhq.com'.  The second way is to specify the IP
address such as `127.0.0.1'.
-->
ソース(`-s', `--source' または `--src') および、あて先(`-d',
`--destination' または `--dst') IP アドレスは 4通りの指定方法が
あります。もっとも一般的な方法は完全に記述された名前(FQDN)を使うことで、
例えば、`localhost' とか `www.linuxhq.com' です。2番目の方法は `127.0.0.1'
のような IP アドレスを指定する方法です。

<p>
<!--
The third and fourth ways allow specification of a group of IP
addresses, such as `199.95.207.0/24' or `199.95.207.0/255.255.255.0'.
These both specify any IP address from 199.95.207.0 to 199.95.207.255
inclusive; the digits after the `/' tell which parts of the IP address
are significant.  `/32' or `/255.255.255.255' is the default (match
all of the IP address).  To specify any IP address at all `/0' can be
used, like so:
-->
3番目と 4番目の方法は IP アドレスのグループを指定する方法で、
`199.95.207.0/24' とか `199.95.207.0/255.255.255.0' のように書きます。
両方とも 199.95.207.0 から 199.95.207.255 までのどの IP アドレスも
含まれる指定で、数字のあとの `/' は IP アドレスのどの部分まで有効かを
示しています。省略時は `/32' または `/255.255.255.255' (IP アドレスの
完全一致)です。どんな IP アドレスでもよい場合は、以下のように `/0' が
使えます:
<!--
<tscreen><verb>
	[ NOTE: `-s 0/0' is redundant here. ]
	# iptables -A INPUT -s 0/0 -j DROP
	#
-->
<tscreen><verb>
	[ 注記: `-s 0/0' はここでは冗長です。]
	# iptables -A INPUT -s 0/0 -j DROP
	#
</verb></tscreen>

<!--
This is rarely used, as the effect above is the same as not specifying
the `-s' option at all.
-->
上記の効果は `-s' オプションを指定しないのと全く同じなので、
こんな使い方はめったにしません。

<!--
<sect2>Specifying Inversion
-->
<sect2>否定の指定

<p>
<!--
Many flags, including the `-s' (or `-&#045;source') and `-d'
(`-&#045;destination') flags can have their arguments preceded by `!'
(pronounced `not') to match addresses NOT equal to the ones given.
For example. `-s ! localhost' matches any packet <bf>not</bf> coming
from localhost.
-->
`-s' (または `--source') や `-d' (`--destination') オプション
を含めて多くのオプションは、`!' (否定の宣言)を
その引数の前に置くことができます。`-s' や `-d' の場合は与えられた
アドレスと等しくないアドレスとマッチします。
例えば、`-s ! localhost' は localhost から<bf>でない</bf>パケットと
マッチします。

<!--
<sect2>Specifying Protocol
-->
<sect2>プロトコルの指定

<p>
<!--
The protocol can be specified with the `-p' (or `-&#045;protocol') flag.
Protocol can be a number (if you know the numeric protocol values for
IP) or a name for the special cases of `TCP', `UDP' or `ICMP'.  Case
doesn't matter, so `tcp' works as well as `TCP'.
-->
プロトコルは `-p' (または `--protocol') オプションで指定します。
プロトコルの値は番号(あなたが IP のプロトコルの数値番号を知って
いる場合)か `TCP', `UDP' または `ICMP' という特定の名称で指定します。
大文字小文字の区別はしませんから、`tcp' も `TCP' と同じ働きをします。

<p>
<!--
The protocol name can be prefixed by a `!', to invert it, such as `-p
! TCP' to specify packets which are <bf>not</bf> TCP.
-->
プロトコル名称はそれを否定するために `!' を前に付けることができます。
例えば、`-p ! TCP' は TCP <bf>でない</bf>パケットを指定します。

<!--
<sect2>Specifying an Interface
-->
<sect2>インターフェイスの指定

<p>
<!--
The `-i' (or `-&#045;in-interface') and `-o' (or `-&#045;out-interface') options
specify the name of an <bf>interface</bf> to match.  An interface is
the physical device the packet came in on (`-i') or is going out on
(`-o').  You can use the <tt>ifconfig</tt> command to list the
interfaces which are `up' (i.e., working at the moment).
-->
`-i' (または `--in-interface') と `-o' (または `--out-interface')
オプションはマッチすべき<bf>インターフェイス</bf>の名前を指定します。
インターフェイスとは、パケットが入って来る (`-i') または出て行く
(`-o') 物理デバイスです。`ifconfig' コマンドを使って `up' である
(すなわち、今動いている)インターフェイスをリストアップできます。

<p>
<!--
Packets traversing the <tt>INPUT</tt> chain don't have an output
interface, so any rule using `-o' in this chain will never match.
Similarly, packets traversing the <tt>OUTPUT</tt> chain don't have an
input interface, so any rule using `-i' in this chain will never match.
-->
<tt>INPUT</tt> チェインに入って来るパケットには output インターフェイス
が無いので、このチェインで `-o' を使ったルールは決してマッチしません。
同様に、<tt>OUTPUT</tt> チェインに入って来るパケットには
input インターフェイスが無いので、このチェインで `-i' を使ったルールは
決してマッチしません。

<!--
<p>Only packets traversing the <tt>FORWARD</tt> chain have both an
input and output interface.
-->
<p><tt>FORWARD</tt> チェインに入って来るパケットだけが、input と output
の両方のインターフェイスを持っています。

<p>
<!--
It is perfectly legal to specify an interface that currently does not
exist; the rule will not match anything until the interface comes up.
This is extremely useful for dial-up PPP links (usually interface
<tt>ppp0</tt>) and the like.
-->
現在存在していないインターフェイスを指定することは全く問題がありません
が、指定したインターフェイスが up して来るまでルールがマッチすることは
ありません。これはダイアルアップ PPP リンク(通常インターフェイスは
<tt>ppp0</tt> )や同様のものについて非常に有効です。

<p>
<!--
As a special case, an interface name ending with a `+' will match all
interfaces (whether they currently exist or not) which begin with that
string.  For example, to specify a rule which matches all PPP
interfaces, the <tt>-i ppp+</tt> option would be used.
-->
特別なケースとして、インターフェイス名の後ろに `+' を付けたものはその
文字列から始まる全てのインターフェイス(現在存在してようとなかろうと)
にマッチします。例えば、全ての PPP インターフェイスにマッチするルール
の指定は、<tt>-i ppp+</tt> オプションを使います。

<p>
<!--
The interface name can be preceded by a `!' with spaces around it, to
match a packet which does <bf>not</bf> match the specified
interface(s), eg <tt>-i ! ppp+</tt>.
-->
指定したインターフェイスと一致<bf>しない</bf>パケットにマッチするように
インターフェイス名の前には前後に空白を挟んで `!' を置くことができます。
例えば、<tt>-i ! ppp+</tt> とします。

<!--
<sect2>Specifying Fragments
-->
<sect2>フラグメントの指定

<p>
<!--
Sometimes a packet is too large to fit down a wire all at once.  When
this happens, the packet is divided into <bf>fragments</bf>, and sent
as multiple packets.  The other end reassembles these fragments to
reconstruct the whole packet.
-->
ときどきパケットが、一度にケーブルに送り出すには大き過ぎることがあります。
こんなときは、パケットはフラグメントに分割され、複数のパケットで送られ
ます。受信点でこれらのフラグメントを再び集めて完全なパケットに再構成
します。

<p>
<!--
The problem with fragments is that the initial fragment has the
complete header fields (IP + TCP, UDP and ICMP) to examine, but
subsequent packets only have a subset of the headers (IP without the
additional protocol fields).  Thus looking inside subsequent fragments
for protocol headers (such as is done by the TCP, UDP and ICMP
extensions) is not possible.
-->
フラグメントの問題点は、先頭のフラグメントには完全な
ヘッダーフィールド(IP + TCP, UDP および ICMP)があり検査できますが、
後続のパケットにはヘッダー全てが揃っていません(IP ヘッダーだけで
追加のプロトコルフィールドは無し)。従って後続のフラグメントの
プロトコル固有ヘッダー(TCP, UDP および ICMP で拡張された)をのぞき込む
ことはできません。

<p>
<!--
If you are doing connection tracking or NAT, then all fragments will
get merged back together before they reach the packet filtering code,
so you need never worry about fragments.
-->
もし、コネクション追跡や NAT を行っているなら、全てのフラグメントは
パケットフィルタリングのコードに届く前にマージされて元通りにされる
ので、フラグメントについて心配する必要はありません。

<p>
<!--
Otherwise, it is important to understand how fragments get treated by
the filtering rules.  Any filtering rule that asks for information we
don't have will <em>not</em> match.  This means that the first fragment is
treated like any other packet.  Second and further fragments won't be.
Thus a rule <tt>-p TCP -&#045;sport www</tt> (specifying a source port of
`www') will never match a fragment (other than the first fragment).
Neither will the opposite rule <tt>-p TCP -&#045;sport ! www</tt>.
-->
そうでなければ、フィルタリングルールがフラグメントをどのように扱うか
を理解することが重要です。情報が無ければどんなフィルタリングルールも
マッチ<em>しません</em>。この意味するところは 1番目のフラグメントは
他のパケットと同じように扱われます。2番目以降のフラグメントは異なり
ます。従って <tt>-p TCP --sport www</tt> というルール(ソースポートが
`www' の指定)はフラグメント(1番目のフラグメント以外)と決してマッチ
しません。同様に否定のルール <tt>-p TCP --sport ! www</tt> もマッチ
しません。

<p>
<!--
However, you can specify a rule specifically for second and further
fragments, using the `-f' (or `-&#045;fragment') flag.  It is also legal to
specify that a rule does <em>not</em> apply to second and further
fragments, by preceding the `-f' with ` ! '.
-->
とはいえ、`-f' (または `--fragment')オプションを使って 2番目以降の
フラグメントを特定するルールを指定できます。また、` ! ' を `-f' の
前に付けて(訳注: <tt/! -f/ として) 2番目以降のフラグメントと適合
<em>しない</em>ルールの指定もできます。

<p>
<!--
Usually it is regarded as safe to let second and further fragments
through, since filtering will effect the first fragment, and thus
prevent reassembly on the target host; however, bugs have been known
to allow crashing of machines simply by sending fragments.  Your call.
-->
通常、フィルタリングは 1番目のフラグメントに効力があるので、目的の
ホストでのフラグメントの再組み立てを妨げるため、2番目以降のフラグメント
を通過させることは安全とみなされています。とはいえ、フラグメントを送る
ことにより簡単にマシンをクラッシュさせることができるバグが知られて
います。調べてくださいね。
<!-- Your call あなたの要求、から意訳。自信なし。 -->

<p>
<!--
Note for network-heads: malformed packets (TCP, UDP and ICMP packets
too short for the firewalling code to read the ports or ICMP code and
type) are dropped when such examinations are attempted.  So are TCP
fragments starting at position 8.
-->
ネットワーク管理者のための注記: 異常なパケット(TCP, UDP および ICMP の
パケットで短すぎてファイアーウォールのコードがポート番号または ICMP の
コードと種類を読めないもの)はそれらの検査が試みられるとき破棄されます。
それで TCP パケットのフラグメントの位置は最低でも 8 から始まります。
<!-- 訳注が必要か? ICMP: 種類(1)+コード(1)
  TCP: ソースポート(2)+あて先ポート(2)+シーケンス番号(4)
  ( )はバイト数 -->

<p>
<!--
As an example, the following rule will drop any fragments going to
192.168.1.1:
-->
例えば、次のルールは 192.168.1.1 へ行くフラグメントはどれでも破棄します:

<tscreen><verb>
# iptables -A OUTPUT -f -d 192.168.1.1 -j DROP
#
</verb></tscreen>

<!--
<sect2>Extensions to iptables: New Matches
-->
<sect2>iptables への拡張 ― 新しいマッチ

<!--
<p><tt>iptables</tt> is <bf>extensible</bf>, meaning that both the
kernel and the iptables tool can be extended to provide new features.
-->
<p><tt>iptables</tt> は<bf>拡張性</bf>に富んでいます、その意味する
ところは、カーネルと iptables ツールの両方が新しい機能を提供するために
拡張可能であると言うことです。

<!--
<p>Some of these extensions are standard, and other are more exotic.
Extensions can be made by other people and distributed separately for
niche users.
-->
<p>これらの拡張には標準的なものもありますが、もっと風変わりなものも
あります。私達以外の人々が拡張を作って特殊な利用者に個別に配布する
ことができます。

<!--
<p>Kernel extensions normally live in the kernel module subdirectory,
such as /lib/modules/2.4.0-test10/kernel/net/ipv4/netfilter.  They are demand loaded if your
kernel was compiled with CONFIG_KMOD set, so you should not need to
manually insert them.
-->
<p>カーネルの拡張は、通常カーネルモジュールのサブディレクトリ、
例えば /lib/modules/2.4.0-test10/kernel/net/ipv4/netfilter に存在します。
それらはカーネルが
CONFIG_KMOD をセットしてコンパイルされていれば要求時にロードされます。

<!--
<p>Extensions to the iptables program are shared libraries which
usually live in /usr/local/lib/iptables/, although a distribution
would put them in /lib/iptables or /usr/lib/iptables.
-->
<p>iptables プログラムへの拡張は、共有ライブラリで通常は
/usr/local/lib/iptables/ に存在します。ディストリビューションに
よっては /lib/iptables または /usr/lib/iptables に置かれます。

<!--
<p>Extensions come in two types: new targets, and new matches (we'll
talk about new targets a little later).  Some protocols automatically
offer new tests: currently these are TCP, UDP and ICMP as shown below.
-->
<p>拡張には 2種類あります: 新しいターゲット、そして新しいマッチです
(新しいターゲットについては、もう少し後でお話します)。いくつかの
プロトコルは自動的に新しい検査を提供します: 現在のところ以下に示す
TCP, UDP および ICMP があります。
<!-- 2000/9/13 ( ) のところが変更されました。-->

<!--
<p>For these you will be able to specify the new tests on the command
line after the `-p' option, which will load the extension.  For
explicit new tests, use the `-m' option to load the extension, after
which the extended options will be available.
-->
<p>これらは `-p' オプションで拡張がロードされ、その後のコマンドラインで
新しい検査を指定できます。新しい検査を指定するには、`-m' オプションを
使うと拡張がロードされて、拡張されたオプションが有効になります。

<!--
<p>To get help on an extension, use the option to load it (`-p', `-j' or
`-m') followed by `-h' or `-&#045;help', eg:
-->
<p>拡張のヘルプを見るには、拡張をロード(`-p', `-j' または `-m')した後に
`-h' または `--help' オプションを使います。例えば:
<tscreen><verb>
# iptables -p tcp --help
#
</verb></tscreen>

<!--
<sect3>TCP Extensions
-->
<sect3>TCP 拡張

<p>
<!--
The TCP extensions are automatically loaded if `-p tcp' is specified.
It provides the following options (none of which match fragments).
-->
TCP 拡張は `-p tcp' を指定すると自動的にロードされます。
以下のオプションが提供されています(フラグメントは決してマッチしません)。

<p>
<descrip>
<!--
<tag>-&#045;tcp-flags</tag> Followed by an optional `!', then two strings
of flags, allows you to filter on specific TCP flags.  The first
string of flags is the mask: a list of flags you want to examine.  The
second string of flags tells which one(s) should be set.  For example,
-->
<tag>--tcp-flags</tag> 後に `!' オプション指定可で、2つのフラグ文字列
をとり、指定した TCP フラグでフィルターできます。1番目の文字列はマスク
するフラグで、検査したいフラグを書き並べます。2番目の文字列は(訳注:
1番目の文字列のうちで)セットされているべきフラグを指定します。例えば、

<tscreen><verb>
# iptables -A INPUT --protocol tcp --tcp-flags ALL SYN,ACK -j DROP
</verb></tscreen>

<!--
This indicates that all flags should be examined (`ALL' is synonymous
with `SYN,ACK,FIN,RST,URG,PSH'), but only SYN and ACK should be set.
There is also an argument `NONE' meaning no flags.
-->
これは全てのフラグを検査し(`ALL' は `SYN,ACK,FIN,RST,URG,PSH' と同じ
意味)、SYN と ACK だけがセットされているべきことを示しています。
また `NONE' はどのフラグもセットされていないことを意味します
(訳注: `NONE' を使うのは普通、2番目の文字列で、1番目で指定したフラグが
全てオフであることを検査します)。

<!--
<tag>-&#045;syn</tag> Optionally preceded by a `!', this is shorthand
  for `-&#045;tcp-flags SYN,RST,ACK SYN'.
-->
<tag>--syn</tag> 前に `!' オプション指定可で、これは
`--tcp-flags SYN,RST,ACK SYN' の省略表現です。

<!--
<tag>-&#045;source-port</tag> followed by an optional `!', then either a
single TCP port, or a range of ports.  Ports can be port names, as
listed in /etc/services, or numeric.  Ranges are either two port names
separated by a `:', or (to specify greater than or equal to a given
port) a port with a `:' appended, or (to specify less than or equal to
a given port), a port preceded by a `:'.
-->
<tag>--source-port</tag> 後に `!' オプション指定可で、1つの TCP
ポート、またはポートの範囲のどちらでも指定できます。ポートは
/etc/services に一覧されている名前でも、番号でも指定できます。
範囲の指定は 2つのポートを `:' で区切るか、後ろに `:' を付ける
(指定したポート番号以上を示す)か、前に `:' を付ける
(指定したポート番号以下を示す)かのいずれかです。

<!--
<tag>-&#045;sport</tag> is synonymous with `-&#045;source-port'.
-->
<tag>--sport</tag> は `--source-port' と同じ意味です。

<!--
<tag>-&#045;destination-port</tag> and <tag>-&#045;dport</tag> are the same as
above, only they specify the destination, rather than source, port to
match.
-->
<tag>--destination-port</tag> と <tag>--dport</tag> は上記と同様で、
ソースの代わりに、単にあて先のポートとマッチするかの指定です。

<!--
<tag>-&#045;tcp-option</tag> followed by an optional `!' and a number,
matches a packet with a TCP option equaling that number.  A packet
which does not have a complete TCP header is dropped automatically if
an attempt is made to examine its TCP options.
-->
<tag>--tcp-option</tag> 後に `!' オプション指定可で、数値を指定し、
パケットの TCP オプション(訳注: オプションフィールドの 1バイト目の種別)
が指定値と等しいときマッチします。TCP オプションの検査をしようとする
とき、パケットに TCP ヘッダーが完全に含まれていなければパケットは
自動的に破棄されます。
<!-- オプションフィールドは可変長、追加オプションで MSS 拡張がある。-->
</descrip>

<!--
<sect4>An Explanation of TCP Flags
-->
<sect4>TCP フラグの説明

<p>
<!--
It is sometimes useful to allow TCP connections in one direction, but
not the other.  For example, you might want to allow connections to an
external WWW server, but not connections from that server.
-->
一方向だけ TCP コネクションを許可し、他方は許可しないようにすることは
往々にして有効です。例えば、あなたが外部の WWW サーバーと接続したいが、
そのサーバーからの接続を許可したくないときです。

<p>
<!--
The naive approach would be to block TCP packets coming from the
server.  Unfortunately, TCP connections require packets going in both
directions to work at all.
-->
そのサーバーから来る TCP パケットをブロックすることは自然な方法です。
残念なことに、TCP コネクションにはとにかく両方向のパケットが行き来する
ことが必要です。

<p>
<!--
The solution is to block only the packets used to request a
connection.  These packets are called <bf>SYN</bf> packets (ok,
technically they're packets with the SYN flag set, and the RST and ACK
flags cleared, but we call them SYN packets for short).  By
disallowing only these packets, we can stop attempted connections in
their tracks.
-->
その解決方は、接続を要求するパケットだけをブロックすることです。
このようなパケットは <bf>SYN</bf> パケットと呼ばれています(オーケー、
技術的には SYN フラグがセットされていて、RST と ACK フラグがクリア
されているパケットですが、短縮して SYN パケットと呼んでいます)。
これらのパケットだけ許可しないようにすれば、パケットを逆にたどって
接続して来るのを止めることができます。

<p>
<!--
The `-&#045;syn' flag is used for this: it is only valid for rules which
specify TCP as their protocol.  For example, to specify TCP connection
attempts from 192.168.1.1:
-->
`--syn' オプションはこのために使われます。このオプションは TCP プロトコルが
指定されているルールにだけ有効です。例えば、192.168.1.1 からの TCP 接続
の試みの指定:
<tscreen><verb>
-p TCP -s 192.168.1.1 --syn
</verb></tscreen>

<p>
<!--
This flag can be inverted by preceding it with a `!', which means
every packet other than the connection initiation.
-->
このオプションは `!' を前に付けて(訳注: <tt/! --syn/ として)否定すること
ができ、その意味は接続開始のパケットを除く全てのパケットです。

<!--
<sect3>UDP Extensions
-->
<sect3>UDP 拡張

<p>
<!--
These extensions are automatically loaded if `-p udp' is specified.
It provides the options `-&#045;source-port', `-&#045;sport',
`-&#045;destination-port' and `-&#045;dport' as detailed for TCP above.
-->
この拡張は `-p udp' を指定すると自動的にロードされます。オプションは
`--source-port' または `--sport' と `--destination-port' または `--dport'
が提供され、詳細は TCP と同様です。

<!--
<sect3>ICMP Extensions
-->
<sect3>ICMP 拡張

<p>
<!--
This extension is automatically loaded if `-p icmp' is specified.  It
provides only one new option:
-->
この拡張は `-p icmp' を指定すると自動的にロードされます。新しい
オプションが 1つだけ提供されます:

<p>
<descrip>
<!--
<tag>-&#045;icmp-type</tag> followed by an optional `!', then either an
icmp type name (eg `host-unreachable'), or a numeric type (eg. `3'),
or a numeric type and code separated by a `/' (eg. `3/3').  A list
of available icmp type names is given using `-p icmp -&#045;help'.
-->
<tag>--icmp-type</tag> 後に `!' オプション指定可で、ICMP の種類を名前で
(例えば `host-unreachable')、または種類を数値で(例えば `3')、または種類
とコードを `/' で区切ったもの(例えば `3/3')を指定します。
ICMP の種類で指定できる名前のリストは `-p icmp --help' で得られます。
</descrip>

<!--
<sect3>Other Match Extensions
-->
<sect3>その他のマッチの拡張

<p>
<!--
The other extensions in the netfilter package are demonstration
extensions, which (if installed) can be invoked with the `-m' option.
-->
netfilter パッケージのその他の拡張は実証的拡張で、インストール済み
なら `-m' オプションで呼び出すことができます。
<!-- demonstration がよく分かりません。-->

<descrip>
<!--
<tag>mac</tag> This module must be explicitly specified with `-m mac'
or `-&#045;match mac'.  It is used for matching incoming packet's source
Ethernet (MAC) address, and thus only useful for packets traversing
the PREROUTING and INPUT chains.  It provides only one option:
-->
<tag>mac</tag> このモジュールは明示的に `-m mac' または `--match mac'
で指定されなければなりません。これは入って来るパケットの発信元
イーサネット(MAC)アドレスとのマッチングに使い、そのため、PREROUTING と
INPUT チェインに入って来るパケットにだけ有効です。このモジュールは
オプションを 1つだけ提供します:
<!-- いきなり PREROUTING とは。前章に訳注を追加しました。-->

  <descrip>
<!--
  <tag>-&#045;mac-source</tag> followed by an optional `!', then an
  ethernet address in colon-separated hexbyte notation, eg
  `-&#045;mac-source 00:60:08:91:CC:B7'.
-->
  <tag>--mac-source</tag> 後に `!' オプション指定可で、イーサネット
  アドレスをコロンで区切った 16進表記で指定します。例えば、
  `--mac-source 00:60:08:91:CC:B7'
  </descrip>

<!--
<tag>limit</tag> This module must be explicitly specified with `-m
limit' or `-&#045;match limit'.  It is used to restrict the rate of
matches, such as for suppressing log messages.  It will only match a
given number of times per second (by default 3 matches per hour,
with a burst of 5).  It takes two optional arguments:
-->
<tag>limit</tag> このモジュールは明示的に `-m limit' または
`--match limit' で指定されなければなりません。これはマッチするレート
(頻度)を制限するために使われ、例えば、ログメッセージを抑止するために
使います。このオプションは単位時間あたりに指定された回数分だけマッチ
します(初期値は 1時間あたり 3回のマッチで、バーストは 5 です)。これは
2つのオプション引数をとります:
<!-- per second は 1秒あたり だと後と話しが合わないので 単位時間? -->

  <descrip>
<!--
  <tag>-&#045;limit</tag> followed by a number; specifies the maximum
  average number of matches to allow per second.  The number can
  specify units explicitly, using `/second', `/minute', `/hour' or
  `/day', or parts of them (so `5/second' is the same as `5/s').
-->
  <tag>--limit</tag> 後に数値を指定します。単位時間あたりに許される
  平均マッチ回数の最大値を指定します。指定値は、`/second', `/minute',
  `/hour' または `/day' を使って、あるいはその一部(それで `5/second'
  は `5/s' と同じ)で単位を明示することができます。

<!--
  <tag>-&#045;limit-burst</tag> followed by a number, indicating the
  maximum burst before the above limit kicks in.
-->
  <tag>--limit-burst</tag> 後に数値を指定します。これは上記の limit が
  作動し始める手前の最大バースト値(訳注: 許容できる突発的な増大係数で、
  平均レートの倍数)を指定します。
  </descrip>

<!--
This match can often be used with the LOG target to do rate-limited
logging.  To understand how it works, let's look at the following
rule, which logs packets with the default limit parameters:
-->
このマッチは、しばしばログのレート(頻度)制限をするために LOG ターゲット
と共に使われます。どのように働くのか理解するために、初期値の limit
パラメータでパケットをログする次のルールを見てみましょう:

<tscreen><verb>
# iptables -A FORWARD -m limit -j LOG
</verb></tscreen>

<!--
The first time this rule is reached, the packet will be logged; in
fact, since the default burst is 5, the first five packets will be
logged.  After this, it will be twenty minutes before a packet will be
logged from this rule, regardless of how many packets reach it.  Also,
every twenty minutes which passes without matching a packet, one of
the burst will be regained; if no packets hit the rule for 100
minutes, the burst will be fully recharged; back where we started.
-->
最初にこのルールに達したとき、パケットはログされます。実際、初期値の
バーストは 5 なので、最初の 5パケットがログされます。このあと、何個の
パケットが届くかには関係なく、20分間はこのルールによりログされることは
ありません。そして、20分経過する毎にマッチするパケットがなければ、
バーストは 1 づつ回復します。もし、100分間にルールにヒットするパケット
がなければ、バーストは完全に回復し、始めと同じに戻ります。

<!--
<p>Note: you cannot currently create a rule with a recharge time
greater than about 59 hours, so if you set an average rate of one per
day, then your burst rate must be less than 3.
-->
<p>注記: 現在のところ約 59時間を超える回復時間のルールは作れないので、
もし、平均レートを 1日 1回に設定した場合、バーストレートは 3 未満で
なくてはなりません。

<!--
<p>You can also use this module to avoid various denial of service
attacks (DoS) with a faster rate to increase responsiveness.
-->
<p>このモジュールは、また、速いレートの感応性を高めることで、各種の
サービス拒否攻撃(DoS)を防ぐことができます。

<!--
<p>Syn-flood protection:
-->
<p>SYN パケット溢れへの防御:
<tscreen><verb>
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
</verb></tscreen>

<!--
Furtive port scanner:
-->
こっそり覗きのポートスキャナー:
<tscreen><verb>
# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
</verb></tscreen>

Ping of death:
<tscreen><verb>
# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
</verb></tscreen>

<!--
This module works like a "hysteresis door", as shown in the graph
below.  
-->
このモジュールは、下のグラフに示すように、“ヒステリシスドア”
のように働きます。

<!--
<tscreen><verb>
       rate (pkt/s)  
             ^        .-&#045;-.
             |       / DoS \
             |      /       \
Edge of DoS -|.....:.........\.......................
 = (limit *  |    /:          \
limit-burst) |   / :           \         .-.
             |  /  :            \       /   \
             | /   :             \     /     \
End of DoS  -|/....:..............:.../.......\..../.
 = limit     |     :              :`-'         `-&#045;'
-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-+-&#045;-&#045;-+-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;+-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;> time (s)
   LOGIC =>  Match | Didn't Match |    Match
-->
<tscreen><verb>
  レート(パケット数／秒)
             ^         .---.
             |        / DoS \
             |       /       \
DoSの始まり -|......:.........\.......................
 = (limit *  |     /:          \
limit-burst) |    / :           \         .-.
             |   /  :            \       /   \
             |  /   :             \     /     \
DoSの終わり -|./....:..............:.../.......\..../.
 = limit     |/     :              :`-'         `--'
-------------+------+--------------+------------------> 時間 (秒)
    論理  ⇒  マッチ| マッチしない |  マッチ
</verb></tscreen>

<!--
Say we say match one packet per second with a five packet
burst, but packets start coming in at four per second, for three
seconds, then start again in another three seconds.
-->
例えば、1秒あたり 1パケットでバーストが 5パケットのマッチを指定している
ところに、1秒あたり 4パケットがやって来て 3秒間続き、それから、3秒間で
再びパケットがやって来るとします。
<!--
<tscreen><verb>


        <-&#045;Flood 1-&#045;>           <-&#045;-Flood 2-&#045;->

Total  ^                   Line  __-&#045;      YNNN
Packets|               Rate  __-&#045;      YNNN
       |            mum  __-&#045;      YNNN
    10 |        Maxi __-&#045;         Y
       |         __-&#045;            Y
       |     __-&#045;               Y
       | __-&#045;    YNNN           
       |-    YNNN
     5 |    Y    
       |   Y                                Key:  Y -> Matched Rule
       |  Y                                       N -> Didn't Match Rule
       | Y
       |Y 
     0 +-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;>  Time (seconds)
        0   1   2   3   4   5   6   7   8   9  10  11  12
-->
<tscreen><verb>

        ←―溢れ 1―→          ←― 溢れ 2 ―→

トータル^                         ＿―￣    YNNN
パケット|               ライン＿―      YNNN
  数    |           レート＿―      YNNN
     10 |        最大 ＿―         Y
        |         ＿―            Y
        |     ＿―               Y
        | ＿―    YNNN
        |-    YNNN
      5 |    Y
        |   Y                             キー: Y ⇒ ルールにマッチする
        |  Y                                    N ⇒ ルールにマッチしない
        | Y
        |Y
      0 +--------------------------------------------------> 時間 (秒)
         0   1   2   3   4   5   6   7   8   9  10  11  12
</verb></tscreen>

<!--
You can see that the first five packets are allowed to exceed the one
packet per second, then the limiting kicks in.  If there is a pause,
another burst is allowed but not past the maximum rate set by the
rule (1 packet per second after the burst is used).
-->
最初の 5パケットは 1秒に 1パケットを超えるのに許可されていますが、
その後、制限が働いていることが分かります。もし、少し途絶えていれば、
ルールに設定された最大レートの範囲内で、またバーストが許されます
(バースト作動後は 1秒 1パケット)。

<tag>owner</tag> 
<!--
This module attempts to match various characteristics of the packet
creator, for locally-generated packets.  It is only valid in the
OUTPUT chain, and even then some packets (such as ICMP ping responses)
may have no owner, and hence never match.
-->
このモジュールは、ローカルに生成されたパケットの作成者の各種の特質と
マッチを試みます。これは OUTPUT チェインでのみ有効ですが、いくつかの
パケット(例えば、ICMP ping の応答)には所有者がないので、それゆえ決して
マッチしません。

<descrip>
	<tag>--uid-owner userid</tag>
<!--
Matches if the packet was created by a process with the given
effective (numerical) user id.
-->
パケットを生成したプロセスの実行ユーザ id (数値)にマッチします。

	<tag>--uid-owner groupid</tag>
<!--
Matches if the packet was created by a process with the given
effective (numerical) group id.
-->
パケットを生成したプロセスの実行グループ id (数値) にマッチします。

	<tag>--pid-owner processid</tag>
<!--
Matches if the packet was created by a process with the given
process id.
-->
パケットを生成したプロセスのプロセス id にマッチします。

	<tag>--sid-owner sessionid</tag>
<!-- 2000/9/13 変更されました。-->
<!--
Matches if the packet was created by a process in the given session
group.
-->
パケットを生成したプロセスのセッショングループにマッチします。
</descrip>

<!--
<tag>unclean</tag> This experimental module must be explicitly
specified with `-m unclean or `-&#045;match unclean'.  It does various
random sanity checks on packets.  This module has not been audited,
and should not be used as a security device (it probably makes things
worse, since it may well have bugs itself).  It provides no options.
-->
<tag>unclean</tag> この実験的モジュールは `-m unclean または
`--match unclean' を明示的に指定する必要があります。これはパケット
について手当たりしだい様々の正当性をチェックします。このモジュール
は検査されていないので、セキュリティ装置として使うべきではありません
(バグがよくあるので、ことによると事態が悪化します)。オプションはありま
せん。
</descrip>

<!--
<sect3>The State Match
-->
<sect3>状態のマッチ

<!--
<p>The most useful match criterion is supplied by the `state'
extension, which interprets the connection-tracking analysis of the
`ip_conntrack' module.  This is highly recommended.
-->
<p>最も役に立つマッチ判定基準は `state' 拡張によって提供され、
`ip_conntrack' モジュールのコネクション追跡の分析結果を簡単に利用
できるようにします。これは非常にお勧めです。

<!--
<p>Specifying `-m state' allows an additional `-&#045;state' option, which
is a comma-separated list of states to match (the `!'  flag indicates
<bf>not</bf> to match those states).  These states are:
-->
<p>`-m state' を指定すると追加して `--state' オプションが指定でき、
そこにマッチすべき状態のリストをカンマで区切って指定します(`!' オプション
は指定した状態にマッチ<bf>しない</bf>ことを示します)。状態には以下の
ものがあります:

<descrip>
<!--
<tag>NEW</tag> A packet which creates a new connection.
-->
<tag>NEW</tag> 新しいコネクションを作るパケットです。

<!--
<tag>ESTABLISHED</tag> A packet which belongs to an existing
connection (i.e., a reply packet, or outgoing packet on a connection
which has seen replies).
-->
<tag>ESTABLISHED</tag> 既存のコネクションに属するパケットです
(すなわち、応答パケット、あるいはコネクション確立中の応答のため
出て行くパケット)。

<!--
<tag>RELATED</tag> A packet which is related to, but not part of, an
existing connection, such as an ICMP error, or (with the FTP module
inserted), a packet establishing an ftp data connection.
-->
<tag>RELATED</tag> 既存のコネクションの一部ではなくて関係するパケット、
例えば、ICMP エラーとか、または(FTP モジュールが挿入済みなら)、ftp
データコネクションの確立パケットです。

<!--
<tag>INVALID</tag> A packet which could not be identified for some
reason: this includes running out of memory and ICMP errors which
don't correspond to any known connection.  Generally these packets
should be dropped.
-->
<tag>INVALID</tag> いくつかの理由から ― これにはメモリ不足、どの
コネクションにも対応するものがない ICMP エラー を含みますが、身元不明
のパケットがあります。一般的にこれらのパケットは破棄すべきです。
</descrip>

<!--
An example of this powerful match extension would be:
-->
この強力なマッチ拡張の使用例は以下のようになります:
<tscreen><verb>
# iptables -A FORWARD -i ppp0 -m state ! --state NEW -j DROP
</verb></tscreen>

<!--
<sect1>Target Specifications
-->
<sect1>ターゲットの仕様

<!--
<p>Now we know what examinations we can do on a packet, we need a way
of saying what to do to the packets which match our tests.  This is
called a rule's <bf>target</bf>.
-->
<p>今や、私達はパケットに関してどんな検査ができるか知っています。
次に必要なのは検査にマッチしたパケットに対して何をするか指示する方法です。
これはルールの<bf>ターゲット</bf>と呼ばれています。

<!--
<p>There are two very simple built-in targets: DROP and ACCEPT.  We've
already met them.  If a rule matches a packet and its target is one of
these two, no further rules are consulted: the packet's fate has been
decided.
-->
<p>とても単純な 2つの組み込み済みターゲット: DROP と ACCEPT があります。
これらについては前に述べました。もし、ルールがパケットにマッチし、
ターゲットがこれら 2つのどちらか一方なら、パケットの運命が決定されて、
これ以上ルールが調べられることはありません。

<!--
<p>There are two types of targets other than the built-in ones:
extensions and user-defined chains.
-->
<p>組み込み済みターゲット以外に 2種類のターゲット: 拡張ターゲット
とユーザ定義チェインがあります。

<!--
<sect2>User-defined chains
-->
<sect2>ユーザ定義チェイン

<p>
<!--
One powerful feature which <tt>iptables</tt> inherits from
<tt>ipchains</tt> is the ability for the user to create new chains, in
addition to the three built-in ones (INPUT, FORWARD and OUTPUT).  By
convention, user-defined chains are lower-case to distinguish them
(we'll describe how to create new user-defined chains below in <ref
id="chain-ops" name="Operations on an Entire Chain">).
-->
<!-- 2000/9/13 最終文が変更されました。-->
<tt>ipchains</tt> から継承した <tt>iptables</tt> の強力な特徴の 1つ
は、3つの組み込み済みチェイン(INPUT, FORWARD そして OUTPUT)に加えて、
ユーザが新しいチェインを作ることができるということです。慣例で、
ユーザ定義チェインは組み込み済みチェインと区別するために小文字に
します(新しいユーザ定義チェインの作り方は、以下の<ref id="chain-ops"
name="チェインの操作">で説明します)。

<p>
<!--
When a packet matches a rule whose target is a user-defined chain, the
packet begins traversing the rules in that user-defined chain.  If
that chain doesn't decide the fate of the packet, then once traversal
on that chain has finished, traversal resumes on the next rule in the
current chain.
-->
パケットがルールにマッチし、そのターゲットがユーザ定義チェインであれば、
パケットはそのユーザ定義チェインに移り、ルールの検査を始めます。その
ユーザ定義チェインでの検査が全て終ってもパケットの運命が決まらなければ、
現在のチェインに戻り、その次のルールから検査を再開します。

<p>
<!--
Time for more ASCII art.  Consider two (silly) chains: <tt>INPUT</tt> (the
built-in chain) and <tt>test</tt> (a user-defined chain).
-->
ASCII アートの時間です。2つの(おばかさんな)チェイン: <tt>INPUT</tt>
(組み込み済みチェイン)と <tt>test</tt> (ユーザ定義チェイン)で考えま
しょう。

<!--
<tscreen><verb>
	 `INPUT'			 `test'
	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;
	| Rule1: -p ICMP -j DROP   |	| Rule1: -s 192.168.1.1    |
	|-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;|	|-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;|
	| Rule2: -p TCP -j test    |	| Rule2: -d 192.168.1.1    |
        |-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;|	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;
	| Rule3: -p UDP -j DROP    |
	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;
-->
<tscreen><verb>
	 `INPUT'                          `test'
	┌─────────────┐   ┌─────────────┐
	│ルール 1: -p ICMP -j DROP │   │ルール 1: -s 192.168.1.1  │
	├─────────────┤   ├─────────────┤
	│ルール 2: -p TCP -j test  │   │ルール 2: -d 192.168.1.1  │
	├─────────────┤   └─────────────┘
	│ルール 3: -p UDP -j DROP  │
	└─────────────┘
</verb></tscreen>

<p>
<!--
Consider a TCP packet coming from 192.168.1.1, going to 1.2.3.4.  It
enters the <tt>INPUT</tt> chain, and gets tested against Rule1 - no match.
Rule2 matches, and its target is <tt>test</tt>, so the next rule examined
is the start of <tt>test</tt>.  Rule1 in <tt>test</tt> matches, but doesn't
specify a target, so the next rule is examined, Rule2.  This doesn't
match, so we have reached the end of the chain.  We return to the
<tt>INPUT</tt> chain, where we had just examined Rule2, so we now examine
Rule3, which doesn't match either.
-->
192.168.1.1 から来て 1.2.3.4 へ向かう TCP パケットについて考えましょう。
パケットは <tt>INPUT</tt> チェインに入り、まず、ルール 1 が検査されます
― マッチしません。ルール 2 がマッチして、そのターゲットは <tt>test</tt>
なので、次に検査されるルールは <tt>test</tt> の先頭です。<tt>test</tt>
のルール 1 はマッチしますが、ターゲットを指定していないので、次のルール
であるルール 2 が検査されます。これはマッチしないので、チェインの終わりに
達しました。先程検査したルール 2 のある <tt>INPUT</tt> チェインに戻り、
それで今度はルール 3 が検査されますが、これもまたマッチしません。

<p>
<!--
So the packet path is:
-->
それで、パケットの経路は次のようになります:
<!--
<tscreen><verb>
                                v    __________________________
	 `INPUT'		|   /	 `test'                v
	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;|-&#045;/	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-|-&#045;-&#045;
	| Rule1                 | /|	| Rule1                |   |
	|-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-|/-|	|-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;|-&#045;-|
	| Rule2                 /  |	| Rule2                |   |
        |-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;|	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-v-&#045;-&#045;
	| Rule3                 /-&#045;+___________________________/
	-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;-&#045;|-&#045;-
                                v
-->
<tscreen><verb>
	                        v    __________________________
	 `INPUT'                |   /     `test'               v
	┌───────────|─/     ┌──────────|─┐
	│ルール 1              | /│    │ルール 1            |  │
	├───────────|/-┤    ├──────────|─┤
	│ルール 2              /  │    │ルール 2            |  │
	├───────────-─┤    └──────────v─┘
	│ルール 3              /─┼─\_______________________/
	└───────────|─┘
	                        v
</verb></tscreen>

<!--
<p>User-defined chains can jump to other user-defined chains (but
don't make loops: your packets will be dropped if they're found to
be in a loop).
-->
<p>ユーザ定義チェインは他のユーザ定義チェインへジャンプできます
(しかし、ループしてはいけません。ループしていることが判ると
パケットは破棄されます)。

<!--
<sect2>Extensions to iptables: New Targets
-->
<sect2>iptables への拡張 ― 新しいターゲット

<!--
<p>The other type of extension is a target.  A target extension
consists of a kernel module, and an optional extension to
<tt>iptables</tt> to provide new command line options.  There are
several extensions in the default netfilter distribution:
-->
<p>拡張のもう 1つの種類はターゲットです。ターゲットの拡張
はカーネルモジュールから成り、<tt>iptables</tt> へのオプションの
拡張は新しいコマンドラインオプションによって提供されます。netfilter
の配布物には始めから数々の拡張があります:

<descrip>
<!--
<tag>LOG</tag> This module provides kernel logging of matching
packets.  It provides these additional options:
-->
<tag>LOG</tag> このモジュールはマッチしたパケットのカーネルロギング
を提供します。以下の追加オプションを提供します:

  <descrip>
<!--
  <tag>-&#045;log-level</tag> Followed by a level number or name.  Valid
  names are (case-insensitive) `debug', `info', `notice', `warning',
  `err', `crit', `alert' and `emerg', corresponding to numbers 7
  through 0.  See the man page for syslog.conf for an explanation of
  these levels.  The default is `warning'.
-->
  <tag>--log-level</tag> 後にレベル番号か名前を続けます。有効な名前
  は(大文字小文字を問わず) `debug', `info', `notice', `warning',
  `err', `crit', `alert' および `emerg' で、それぞれ番号の 7 から 0
  に該当します。これらのレベルの説明は syslog.conf の man ページを見て
  ください。初期値は `warning' です。

<!--
  <tag>-&#045;log-prefix</tag> Followed by a string of up to 29 characters,
  this message is sent at the start of the log message, to allow it to
  be uniquely identified.
-->
<!-- 2000/9/13 変更されました。-->
  <tag>--log-prefix</tag> 後に最大 29文字までの文字列を続けます。
  このメッセージはログメッセージの開始時に送られるので、それを識別
  できます。
  </descrip>

<!--
  This module is most useful after a limit match, so you don't flood
  your logs.
-->
<!-- 2000/9/13 変更されました。-->
  このモジュールは limit マッチの後で最も有効で、それはログがあふれる
  のを防ぎます。

<!--
<tag>REJECT</tag> This module has the same effect as `DROP', except
that the sender is sent an ICMP `port unreachable' error message.
Note that the ICMP error message is not sent if (see RFC 1122):
-->
<tag>REJECT</tag> このモジュールは `DROP' と同じ効果がありますが、
送信者に ICMP の `ポート未到達' エラーメッセージを送り返すところが
違います。注記として、以下の場合(RFC 1122 を見てください) ICMP
エラーメッセージは送られません:

<itemize>
<!--
<item> The packet being filtered was an ICMP error message in the
first place, or some unknown ICMP type.
-->
<item>フィルターしようとしているパケットが最初から ICMP エラー
メッセージであるか、または ICMP の種類が不明なものである。

<!--
<item> The packet being filtered was a non-head fragment.
-->
<item>フィルターしようとしているパケットが先頭以外のフラグメントである。

<!--
<item> We've sent too many ICMP error messages to that destination
recently (see /proc/sys/net/ipv4/icmp_ratelimit).
-->
<item>直前に、そのあて先にあまりに多くの ICMP エラーメッセージを送った
(/proc/sys/net/ipv4/icmp_ratelimit を見てください)。
</itemize>

<!--
REJECT also takes a `-&#045;reject-with' optional argument which alters the
reply packet used: see the manual page.
-->
REJECT はまた、使われる応答パケットを変更するのに `--reject-with'
オプション引数をとります: マニュアルページを見てください。
</descrip>

<!--
<sect2>Special Built-In Targets
-->
<sect2>特別な組み込み済みターゲット

<!--
<p>There are two special built-in targets: <tt>RETURN</tt> and
<tt>QUEUE</tt>.
-->
<p>2つの特別な組み込み済みターゲット: <tt>RETURN</tt> と <TT>QUEUE</tt>
があります。

<!--
<p><tt>RETURN</tt> has the same effect of falling off the end of a
chain: for a rule in a built-in chain, the policy of the chain is
executed.  For a rule in a user-defined chain, the traversal continues
at the previous chain, just after the rule which jumped to this chain.
-->
<p><tt>RETURN</tt> はチェインの末尾まで落っこちるのと同じ効果があります
 ― 組み込み済みチェイン内のルールの場合は、そのチェインのポリシー
が実行されます。ユーザ定義チェイン内のルールの場合は、そのチェインを
呼び出したチェインに戻り、呼び出し元のルールの直後から検査が続行されます。

<!--
<p><tt>QUEUE</tt> is a special target, which queues the packet for
userspace processing.  For this to be useful, two further components are
required:
-->
<p><tt>QUEUE</tt> はパケットをユーザ空間で処理するためにキューに入れる
という特別なターゲットです。これを有効にするには、さらに 2つの構成物が
必要です:

<itemize>
<!--
<item>a "queue handler", which deals with the actual mechanics of
passing packets between the kernel and userspace; and
-->
<item>“キューハンドラー”はパケットをカーネルからユーザ空間
に渡す実際の機構を扱います。そして、
<!--
<item>a userspace application to receive, possibly manipulate, and
issue verdicts on packets.
-->
<item>ユーザ空間アプリケーションはパケットを受け取り、場合によっては
操作し、そしてパケットに判定を下します。
</itemize>
<!--
The standard queue handler for IPv4 iptables is the ip_queue module,
which is distributed with the kernel and marked as experimental.
-->
IPv4 iptables の標準キューハンドラーは ip_queue モジュールで、カーネル
と一緒に配布され、開発中(experimental)としてマークされています。
<p>
<!--
The following is a quick example of how to use iptables to queue packets
for userspace processing:
-->
ユーザ空間で処理するためにキューへパケットを入れる iptables の使い方の
簡単な例を以下に示します:
<tscreen><verb>
# modprobe iptable_filter
# modprobe ip_queue
# iptables -A OUTPUT -p icmp -j QUEUE
</verb></tscreen>
<!--
With this rule, locally generated outgoing ICMP packets (as created with,
say, ping) are passed to the ip_queue module, which then attempts to deliver
the packets to a userspace application.  If no userspace application is 
waiting, the packets are dropped.
-->
このルールでは、ローカルに生成された外に出て行く ICMP パケット(例えば、
ping で生成された)は ip_queue モジュールに渡されます。それから、ip_queue
はパケットをユーザ空間のアプリケーションに届けようとします。もし、待機
しているユーザ空間アプリケーションが無ければ、パケットは破棄されます。

<!--
<p>To write a userspace application, use the libipq API.  This is
distributed with iptables.  Example code may be found in the testsuite
tools (e.g. redirect.c) in CVS.
-->
<p>ユーザ空間アプリケーションを書くためには、libipq API を使います。
これは iptables と一緒に配布されています。実例のコードは CVS 中の
testsuite ツール(例えば、redirect.c)の中で見つけられます。

<!--
<p>The status of ip_queue may be checked via:
-->
<p>ip_queue の状態は以下でチェックできます:
<tscreen><verb>
/proc/net/ip_queue
</verb></tscreen>
<!--
The maximum length of the queue (i.e. the number packets delivered
to userspace with no verdict issued back) may be controlled via:
-->
キューの最大長(すなわち、ユーザ空間に届けられていて、まだ判定がなされて
いないパケットの数)は以下でコントロールできます:
<tscreen><verb>
/proc/sys/net/ipv4/ip_queue_maxlen
</verb></tscreen>
<!--
The default value for the maximum queue length is 1024.  Once this limit 
is reached, new packets will be dropped until the length of the queue falls
below the limit again.  Nice protocols such as TCP interpret dropped packets
as congestion, and will hopefully back off when the queue fills up.  However,
it may take some experimenting to determine an ideal maximum queue length 
for a given situation if the default value is too small.
-->
キューの最大長の初期値は 1024 です。一旦この限界値に達したら、キューの
長さが限界値より低くなるまで新しいパケットは破棄されます。TCP のような
すばらしいプロトコルは、混雑で落ちこぼれたパケットを検出して、キューが
一杯になったとき、再送を試みます。とはいえ、与えられた状況下で初期値は
小さ過ぎるかもしれないので、理想的な最大キュー長を決定するのにいくらか
実験するとよいでしょう。
<!-- hopefully back off の訳、自信なし。-->

<!--
<sect1>Operations on an Entire Chain<label id="chain-ops">
-->
<sect1>チェインの操作<label id="chain-ops">

<p>
<!--
A very useful feature of <tt>iptables</tt> is the ability to group
related rules into chains.  You can call the chains whatever you want,
but I recommend using lower-case letters to avoid confusion with the
built-in chains and targets.  Chain names can be up to 31 letters
long.
-->
<tt>iptables</tt> のとても有効な特徴は、チェイン中の関連するルールを
グループ化できることです。お望みのチェインは何でも呼び出せますが、
組み込み済みチェインやターゲットと混同を避けるため小文字を使う
ことをお勧めします。チェインの名前は最大 31文字まで使えます。

<!--
<sect2>Creating a New Chain
-->
<sect2>新しいチェインを作る

<p>
<!--
Let's create a new chain.  Because I am such an imaginative fellow,
I'll call it <tt>test</tt>.  We use the `-N' or `-&#045;new-chain' options:
-->
新しいチェインを作りましょう。私はとっても創造力に富んだ野郎なので、
それを <tt>test</tt> と名付けます。`-N' または `--new-chain' オプション
を使います:

<tscreen><verb>
# iptables -N test
#
</verb></tscreen>

<p>
<!--
It's that simple.  Now you can put rules in it as detailed above.
-->
これは簡単です。今や、あなたはこれまで詳細に述べてきたように、これに
ルールを入れることができます。

<!--
<sect2>Deleting a Chain
-->
<sect2>チェインを削除する

<p>
<!--
Deleting a chain is simple as well, using the `-X' or `-&#045;delete-chain'
options.  Why `-X'?  Well, all the good letters were taken.
-->
チェインを削除するのも同様に簡単で、`-X' または `--delete-chain'
オプションを使います。なぜ `-X' かって?  うーん、よい文字が全て
取られてたんです。

<tscreen><verb>
# iptables -X test
#
</verb></tscreen>

<p>
<!--
There are a couple of restrictions to deleting chains: they must be
empty (see <ref id="flushing" name="Flushing a Chain"> below) and they
must not be the target of any rule.  You can't delete any of the three
built-in chains.
-->
チェインを削除するには 2つの制限があります ― そのチェインは空である必要
があり(下記の<ref id="flushing" name="チェインを空にする">を見てくださ
い)、しかも、決してどのルールのターゲットにもなっていないことです。
組み込み済みの 3つのチェインはどれも削除できません。

<p>
<!--
If you don't specify a chain, then <em>all</em> user-defined chains
will be deleted, if possible.
-->
もし、チェイン名を指定しなければ、<em>全て</em>のユーザ定義チェインが
可能な限り削除されます。

<!--
<sect2> Flushing a Chain<label id="flushing">
-->
<sect2>チェインを空にする<label id="flushing">

<p>
<!--
There is a simple way of emptying all rules out of a chain, using the
`-F' (or `-&#045;flush') commands.
-->
チェインから全てのルールを取り去り空にするのは簡単で、`-F' (または
`--flush') コマンドを使います。

<tscreen><verb>
# iptables -F FORWARD
#
</verb></tscreen>
<!-- 2000/9/13 変更されました。-->

<p>
<!--
If you don't specify a chain, then <em>all</em> chains will be flushed.
-->
もし、チェイン名を指定しなければ、<em>全て</em>のチェインを空にします。

<!--
<sect2>Listing a Chain
-->
<sect2>チェインの内容をリストアップする

<p>
<!--
You can list all the rules in a chain by using the `-L' (or `-&#045;list')
command.
-->
チェイン中の全てのルールをリストアップするには、`-L' (または `--list')
コマンドを使います。

<p>
<!--
The `refcnt' listed for each user-defined chain is the number of rules
which have that chain as their target.  This must be zero (and the
chain be empty) before this chain can be deleted.
-->
各々のユーザ定義チェインに表示される `refcnt' は、それをターゲットに
指定しているルールの数です。この数が 0 でないと(かつチェインが空である
こと)、そのチェインを削除することはできません。

<p>
<!--
If the chain name is omitted, all chains are listed, even empty ones.
-->
もし、チェイン名を指定しなければ、空のも含めて全てのチェインについて
リストアップされます。

<p>
<!--
There are three options which can accompany `-L'.  The `-n' (numeric)
option is very useful as it prevents <tt>iptables</tt> from trying to
lookup the IP addresses, which (if you are using DNS like most people)
will cause large delays if your DNS is not set up properly, or you
have filtered out DNS requests.  It also causes TCP and UDP ports to
be printed out as numbers rather than names.
-->
`-L' には 3つのオプションがあります。
(たいていの人々は DNS を使っていますが) DNS が適切に設定
されていない場合や DNS の要求をフィルターアウトしている場合は、
<tt>iptables</tt> が IP アドレスを調べようとするときに長く待たされます。
それを防ぐのに `-n' (数値)オプションはとても有効です。このオプションは
また、TCP や UDP ポートを名前ではなく番号で表示します。

<p>
<!--
The `-v' options shows you all the details of the rules, such as the
the packet and byte counters, the TOS comparisons, and the interfaces.
Otherwise these values are omitted.
-->
`-v' オプションはルールの詳細を全て、例えば、パケットやバイトの
カウンター、TOS マスク、そしてインターフェイス、を表示します。
このオプションを指定しなければ、これらの値は省略されます。
<!-- TOS comparisons が分かりません。man から、一応 マスク に -->

<p>
<!--
Note that the packet and byte counters are printed out using the
suffixes `K', `M' or `G' for 1000, 1,000,000 and 1,000,000,000
respectively.  Using the `-x' (expand numbers) flag as well prints the
full numbers, no matter how large they are.
-->
注記として、パケットとバイトのカウンターは、1000, 1,000,000 および
1,000,000,000 を、それぞれ `K', `M' および `G' の接尾辞を使って表示
します。`-x' (拡張数値)オプションを使うと、値の大きさにかかわらず完全な数値
を同様に表示します。

<!--
<sect2>Resetting (Zeroing) Counters
-->
<sect2>カウンターをリセット(ゼロに)する

<p>
<!--
It is useful to be able to reset the counters.  This can be done with
the `-Z' (or `-&#045;zero') option.
-->
カウンターをリセットできると便利です。これは `-Z' (または `--zero')
オプションでできます。

<p>
<!--
Consider the following:
-->
以下について考えてみましょう:

<tscreen><verb>
# iptables -L FORWARD
# iptables -Z FORWARD
# 
</verb></tscreen>

<!--
In the above example, some packets could pass through between the `-L'
and `-Z' commands.  For this reason, you can use the `-L' and `-Z'
<em>together</em>, to reset the counters while reading them.
-->
<!-- 2000/9/13 変更されました。-->
<!--
このやり方では、リセットする直前のカウンター値を知る必要があるときに
問題になります。-->
上記の方法では、`-L' から `-Z' コマンドまでの間に
いくつかのパケットが通過するかもしれません。そのため、カウンターを
読むと同時にリセットするには、`-L' と `-Z' を<em>同時に</em>使います。

<!--
<sect2>Setting Policy<label id="policy">
-->
<sect2>ポリシーを設定する<label id="policy">

<p>
<!--
We glossed over what happens when a packet hits the end of a built-in
chain when we discussed how a packet walks through chains earlier.  In
this case, the <bf>policy</bf> of the chain determines the fate of the
packet.  Only built-in chains (<tt>INPUT</tt>, <tt>OUTPUT</tt> and
<tt>FORWARD</tt>) have policies, because if a packet falls off the end
of a user-defined chain, traversal resumes at the previous chain.
-->
以前にパケットがどのようにチェインを通り抜けるのか論じたとき、パケットが
組み込み済みチェインの終わりに達したとき何が起きるのか大体述べました。
この場合、チェインの<bf>ポリシー</bf>がそのパケットの運命を決定します。
組み込み済みチェイン(<tt>INPUT</tt>, <tt>OUTPUT</tt> および
<tt>FORWARD</tt>)だけがポリシーを持っています。なぜなら、パケットが
ユーザ定義チェインの終わりまで下り落ちると、前のチェインに戻って行く
からです。

<p>
<!--
The policy can be either <tt>ACCEPT</tt> or <tt>DROP</tt>, for
example:
-->
ポリシーは <tt>ACCEPT</tt> か <tt>DROP</tt> のどちらかです。
例えば:
<!-- 2000/9/13 追加されました。-->

<tscreen><verb>
# iptables -P FORWARD DROP
#
</verb></tscreen>

<!--
<sect> Using ipchains and ipfwadm<label id="oldstyle">
-->
<sect>ipchains と ipfwadm を使う<label id="oldstyle">

<!--
<p> There are modules in the netfilter distribution called ipchains.o
and ipfwadm.o.  Insert one of these in your kernel (NOTE: they are
incompatible with ip_tables.o!).  Then you can use ipchains or ipfwadm
just like the good old days.
-->
<p>netfilter の配布物の中に、ipchains.o と ipfwadm.o という名前の
モジュールがあります。カーネルに、このうちの一方を挿入してください
(注記: これらは、ip_tables.o
と同時に使えません!)。そうすれば、古き良き時代のように ipchains
または ipfwadm が使えます。
<!-- Rusty にモジュール名を問い合わせ中 - 9/19 訂正されました。-->

<!--
<p> This will be supported for some time yet.  I think a reasonable
formula is 2 * [notice of replacement - initial stable release],
beyond the date that a stable release of the replacement is available.
This means that support will probably be dropped in Linux 2.6 or 2.8.
-->
<p>これらは、いつまでもサポートされるわけではありません。私が考える
合理的な公式は、代わりの安定版が利用できるようになった日から
 2 *［交代通告 - 安定版初リリース］の間です。
これは、たぶん、Linux 2.6 か 2.8 でサポートが打ち切られることを意味します。

<!-- 2001/08/15 サポート期間の式が削除されました。-->

<!--
<sect> Mixing NAT and Packet Filtering
-->
<sect>NAT とパケットフィルタリングの混合

<p>
<!--
It's common to want to do Network Address Translation (see the NAT
HOWTO) and packet filtering.  The good news is that they mix extremely
well.
-->
ネットワークアドレス変換(NAT HOWTO を見てください(訳注: 日本語訳が
あります))とパケットフィルタリングを同時にやりたいときがよくあります。
よいお知らせです ― 2つは実によく調和します。

<!--
<p>You design your packet filtering completely ignoring any NAT you
are doing.  The sources and destinations seen by the packet filter
will be the `real' sources and destinations.  For example, if you are
doing DNAT to send any connections to 1.2.3.4 port 80 through to
10.1.1.1 port 8080, the packet filter would see packets going to
10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80.
Similarly, you can ignore masquerading: packets will seem to come from
their real internal IP addresses (say 10.1.1.1), and replies will seem
to go back there.
-->
<p>あなたは NAT のことは完全に忘れて、パケットフィルタリングの設計を
してください。パケットフィルターにとってのソースとあて先は
‘実際の’ソースとあて先です。例えば、IP アドレス 1.2.3.4 ポート番号 80
に接続してくるものは何でも IP アドレス 10.1.1.1 ポート番号 8080 へ転送
する DNAT(訳注: あて先 NAT、一般的な NAT のこと)をするなら、パケット
フィルターには、1.2.3.4 の 80 ではなくて、10.1.1.1 の 8080 (実際の
あて先)へ、パケットが行くように見えます。同様に、IP マスカレードの
ことも忘れることができます ― パケットが実際の内部 IP アドレス(例えば
10.1.1.1)から来て、応答パケットもそこへ戻って行くように見えます。

<!--
<p>You can use the `state' match extension without making the packet
filter do any extra work, since NAT requires connection tracking
anyway.  To enhance the simple masquerading example in the NAT HOWTO
to disallow any new connections from coming in the ppp0 interface, you
would do this:
-->
<p>NAT には、とにかくコネクション追跡が必要なので、パケットフィルターに
余分な仕事をさせずに `state' マッチを使うことができます。NAT HOWTO の
簡単なマスカレードの例を増強して ppp0 インターフェイスから入って来る
どんな新しいコネクションも禁止するためには、このようにします:

<!--
<tscreen><verb>
# Masquerade out ppp0
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Disallow NEW and INVALID incoming or forwarded packets from ppp0.
iptables -A INPUT -i ppp0 -m state -&#045;state NEW,INVALID -j DROP
iptables -A FORWARD -i ppp0 -m state -&#045;state NEW,INVALID -j DROP

# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
-->
<tscreen><verb>
# ppp0 から出て行くものをマスカレードする
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# ppp0 から入って来るパケットで新規と無効のものを入力とフォワードで禁止する
iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j DROP
iptables -A FORWARD -i ppp0 -m state --state NEW,INVALID -j DROP

# IP フォワーディングを ON にする
echo 1 > /proc/sys/net/ipv4/ip_forward
</verb></tscreen>

<!--
<sect> Differences Between iptables and ipchains<label id="Appendix-A">
-->
<sect>iptables と ipchains の違い<label id="Appendix-A">

<p>
<itemize>
<!--
<item> Firstly, the names of the built-in chains have changed from
lower case to UPPER case, because the INPUT and OUTPUT chains now only
get locally-destined and locally-generated packets.  They used to see
all incoming and all outgoing packets respectively.
-->
<item>まず初めに、組み込み済みチェインの名前を小文字から大文字に変更
しました。その理由は、INPUT と OUTPUT チェインが扱うのは、今では各々、
行き先がローカルのパケットとローカルで生成されたパケット、だけに
なったからです。この 2つのチェインは、全ての入力および全ての出力
パケットをそれぞれ見るために使われます。

<!--
<item> The `-i' flag now means the incoming interface, and only works
in the INPUT and FORWARD chains.  Rules in the FORWARD or OUTPUT
chains that used `-i' should be changed to `-o'.
-->
<item>`-i' オプションは今では入力インターフェイスを意味し、しかも INPUT と
FORWARD チェインでのみ有効です。FORWARD か OUTPUT チェインで `-i' を
使用しているルールは `-o' に変更してください。

<!--
<item> TCP and UDP ports now need to be spelled out with the
-&#045;source-port or -&#045;sport (or -&#045;destination-port/-&#045;dport) options, and
must be placed after the `-p tcp' or `-p udp' options, as this loads
the TCP or UDP extensions respectively.
-->
<item>TCP および UDP のポートは今では、--source-port または --sport
(または --destination-port/--dport) というスペルでオプションを書く必要
があり、TCP または UDP の拡張をそれぞれロードするために、`-p tcp' または
`-p udp' オプションの後に置く必要があります。

<!--
<item> The TCP -y flag is now -&#045;syn, and must be after `-p tcp'.
-->
<item>TCP の -y オプションは今では --syn になり、`-p tcp' の後に置く必要が
あります。

<!--
<item> The DENY target is now DROP, finally.
-->
<item>DENY ターゲットは、結局のところ今では DROP になりました。

<!--
<item> Zeroing single chains while listing them works.
-->
<item>一度にチェインの内容のリストアップとリセットができるようになりました。
<!-- single は Zeroing にかかる副詞と考えました。-->

<!--
<item> Zeroing built-in chains also clears policy counters.
-->
<item>組み込み済みチェインをリセットするとポリシーカウンター(訳注:
ポリシーが適用されたパケットの個数とバイト数)もクリアーされます。

<!--
<item> Listing chains gives you the counters as an atomic snapshot.
-->
<item>チェインの内容のリストアップは、その瞬間のカウンターを表示します。

<!--
<item> REJECT and LOG are now extended targets, meaning they are
separate kernel modules.
-->
<item>REJECT と LOG は今では拡張ターゲットになり、個々にカーネル
モジュールになりました。

<!--
<item> Chain names can be up to 31 characters.
-->
<item>チェイン名は 31文字まで使えるようになりました。

<!--
<item> MASQ is now MASQUERADE and uses a different syntax.  REDIRECT,
while keeping the same name, has also undergone a syntax change.  See
the NAT-HOWTO for more information on how to configure both of these.
-->
<item>MASQ は今では MASQUERADE で、違う書式になりました。REDIRECT は
名前は変わりませんが、これもまた書式が変わりました。両方とも、
設定方法についてのより多くの情報が必要なら、NAT HOWTO を見てください。

<!--
<item> The -o option is no longer used to direct packets to the userspace
device (see -i above).  Packets are now sent to userspace via the QUEUE
target.
-->
<item>-o オプションはもはや、ユーザ空間デバイスにパケットを向ける目的に
使われていません(上記の -i を見てください)。今では、パケットは QUEUE
ターゲットによりユーザ空間に送られます。

<!--
<item> Probably heaps of other things I forgot.
-->
<item>おそらく、この他に私が忘れていることがたくさんあるでしょう。
</itemize>

<!--
<sect> Advice on Packet Filter Design
-->
<sect>パケットフィルター設定のアドバイス

<p>
<!--
Common wisdom in the computer security arena is to block everything,
then open up holes as neccessary.  This is usually phrased `that which
is not explicitly allowed is prohibited'.  I recommend this approach
if security is your maximal concern.
-->
コンピュータのセキュリティ分野での常識は、全てをブロックし、その後に
必要とする穴を空けることです。これは通常「明白でなきもの許すべからず」
と、慣用句で言われます。セキュリティがあなたの最大の関心事なら、この
アプローチをお勧めします。
<!-- この慣用句はテキトーです。-->

<!--
<p>Do not run any services you do not need to, even if you think you
have blocked access to them.
-->
<p>必要でないサービスは動かしてはいけません ― たとえ、あなたがそれら
へのアクセスをブロックしているから大丈夫と思っていても。

<!--
<p>If you are creating a dedicated firewall, start by running nothing,
and blocking all packets, then add services and let packets through as
required.
-->
<p>あなたがファイアーウォール専用機を作っているなら、何も動かさず、全ての
パケットをブロックするところから始めてください。それからサービスを追加し
必要なパケットを通過させるようにしてください。

<!--
<p>I recommend security in depth: combine tcp-wrappers (for
connections to the packet filter itself), proxies (for connections
passing through the packet filter), route verification and packet
filtering.  Route verification is where a packet which comes from an
unexpected interface is dropped: for example, if your internal network
has addresses 10.1.1.0/24, and a packet with that source address comes
in your external interface, it will be dropped.  This can be enabled
for one interface (ppp0) like so:
-->
<p>次のものを組み合わせてセキュリティをより深めることをお勧めします:
TCP Wrappers (パケットフィルター自身への接続に対して)、
プロキシー(パケットフィルターを通り抜ける接続に対して)
(訳注: このパケットフィルターとは広義に Linux ボックスと解釈する
ほうがよいでしょう)、
ルート(経路)検証、そして、パケットフィルタリング。
ルート検証とは予期しないインターフェイスから来るパケットを破棄する
ことです(訳注: カーネルコンフィギュレーションの
CONFIG_IP_ADVANCED_ROUTER 参照)。
例えば、内部ネットワークアドレスが 10.1.1.0/24 であるとして、
外部インターフェイスから入って来るパケットでソースアドレスが
内部ネットワークアドレスになっていれば、それは破棄されます。
これをあるインターフェイス(ppp0)で有効にするためには以下のようにします:
<!-- Route Verification の決まった訳語があれば、教えてください。-->

<tscreen><verb>
# echo 1 > /proc/sys/net/ipv4/conf/ppp0/rp_filter
#
</verb></tscreen>

<!--
Or for all existing and future interfaces like this:
-->
あるいは、全ての存在するそして将来のインターフェイスのためには、
このようにします:

<tscreen><verb>
# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
#     echo 1 > $f
# done
# 
</verb></tscreen>

<!--
Debian does this by default where possible.  If you have asymmetric
routing (ie. you expect packets coming in from strange directions),
you will want to disable this filtering on those interfaces.
-->
Debian では、可能ならデフォルトで上記のように設定します。もし、あなたが
非対称ルーティングを行っているなら(すなわち、変わった方向から
パケットが来るのを期待している)、それらのインターフェイスでは
このフィルタリングを無効にしたいでしょう。

<!--
<p>Logging is useful when setting up a firewall if something isn't
working, but on a production firewall, always combine it with the
`limit' match, to prevent someone from flooding your logs.
-->
<p>ファイアーウォールの作成時ばかりではなく、どこか動かないところが
あってファイアーウォールの設定を調整しているとき、ログを取ることは
役に立ちます。どこかのログがあふれるのを防ぐために、必ず `limit'
マッチと組み合わせましょう。

<!--
<p>I highly recommend connection tracking for secure systems: it
introduces some overhead, as all connections are tracked, but is very
useful for controlling access to your networks.  You may need to load
the `ip_conntrack.o' module if your kernel does not load modules
automatically, and it's not built into the kernel.  If you want to
accurately track complex protocols, you'll need to load the
appropriate helper module (eg. `ip_conntrack_ftp.o').
-->
<p>安全性が求められるシステムではコネクション追跡が非常にお勧めです。
それは若干のオーバーヘッドがありますが、全ての接続が追跡されるので、
あなたのネットワークへのアクセス制御にとても有効です。もし、カーネルが
モジュールを自動的にロードしない場合や、それをカーネルに直に組み込んで
いない場合、`ip_conntrack.o' モジュールをロードする必要があるかもしれ
ません。あなたが実際に複雑なプロトコルを追跡したいなら、しかるべき
ヘルパーモジュール(例えば `ip_conntrack_ftp.o')をロードする必要があり
ます。

<tscreen><verb>
# iptables -N no-conns-from-ppp0
# iptables -A no-conns-from-ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A no-conns-from-ppp0 -m state --state NEW -i ! ppp0 -j ACCEPT
# iptables -A no-conns-from-ppp0 -i ppp0 -m limit -j LOG --log-prefix "Bad packet from ppp0:"
# iptables -A no-conns-from-ppp0 -i ! ppp0 -m limit -j LOG --log-prefix "Bad packet not from ppp0:"
# iptables -A no-conns-from-ppp0 -j DROP

# iptables -A INPUT -j no-conns-from-ppp0
# iptables -A FORWARD -j no-conns-from-ppp0
</verb></tscreen>

<!--
<p>Building a good firewall is beyond the scope of this HOWTO, but my
advice is `always be minimalist'.  See the Security HOWTO for more
information on testing and probing your box.
-->
<p>よいファイアーウォールを構築することは、この HOWTO の範囲を越えて
いますが、私からの助言は「いつも最小限主義者であれ」です。あなたの箱を
テストし抜け穴がないか探るためのより多くの情報が必要なら、
Security HOWTO を見てください。

<sect>日本語訳について

<p>
この文書の原文および関連の HOWTO は、Netfilter Project の<ref id="website"
 name="公式ウェブサイト">にあります。
<newline>
具体的な原文の場所の 1つは、
<url url="http://netfilter.samba.org/unreliable-guides/packet-filtering-HOWTO.linuxdoc.sgml">
です。
<newline>
また、これらの文書は CVS で管理されており、最新版や更新履歴を
<url url="http://cvs.samba.org/cgi-bin/cvsweb/netfilter/HOWTO/">
以下から参照できます。

<p>
この文書を翻訳するにあたり、以下の方々からアドバイスをいただきました。
<newline>
本当にありがとうございました。

<itemize>
<item>千旦裕司さん &lt;ysenda@pop01.odn.ne.jp&gt;
<item>山崎＠Ox さん &lt;hiro@atm.ox.ac.uk&gt;
<item>四亭さん &lt;isao@m05.htmnet.ne.jp&gt;
<item>Konkiti さん &lt;konkiti@lares.dti.ne.jp&gt;
<item>加藤大典さん &lt;daisuke@terra.dti.ne.jp&gt;
<item>武井伸光さん &lt;takei@webmasters.gr.jp&gt;
</itemize>

<p>
日本語訳 初版: 2000年 9月 20日 山森 浩幸 &lt;h-yamamo@db3.so-net.ne.jp&gt;
<newline>
　　　第 2 版: 2001年 8月 13日
<newline>
　　　第 3 版: 2001年 8月 16日
<newline>
　　　第 4 版: 2002年 1月 20日
</article>

