<!doctype linuxdoctr system>

<!-- This is the Linux NAT HOWTO.
 -->

<!-- $Id: NAT-HOWTO.sgml,v 1.6 2002/02/02 11:03:13 mdk Exp $ -->

<article>

<!-- Title information -->

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

<trans>日本語訳：yomoyomo (<tt>ymgrtq@ma.neweb.ne.jp</tt>)
<tdate>	v1.18j 2002 年 02 月 01 日

<abstract>
<!--
This document describes how to do masquerading, transparent proxying,
port forwarding, and other forms of Network Address Translations with
the 2.4 Linux Kernels.
-->
この文書は、2.4 系 Linux カーネルにおける、IP マスカレード、透過プロクシ、
ポートフォワーディング他の、ネットワークアドレス変換の動作について記述
するものです。原文は
<url url="http://netfilter.filewatcher.org/unreliable-guides/NAT-HOWTO/index.html">
にあります。
</abstract>

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

<!-- Begin the document -->

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

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

<p>
<!--
You are about to delve into the fascinating (and sometimes horrid)
world of NAT: Network Address Translation, and this HOWTO is going to
be your somewhat accurate guide to the 2.4 Linux Kernel and beyond.
-->
あなた方は今まさに NAT（Network Address Translation：
ネットワークアドレス変換）の魅力的な（そして時にぞっとするような）
世界を探求しようとしています。この HOWTO は、2.4 系以降の
Linux カーネルに関する的確な手引書となるでしょう。

<p><!--In Linux 2.4, an infrastructure for mangling packets was
introduced, called `netfilter'.  A layer on top of this provides NAT,
completely reimplemented from previous kernels.
-->
Linux 2.4 において、`netfilter' という名称の、
パケットを料理する基盤が導入されました。これの上部のレイヤーで
NAT 機能が提供され、以前のバージョンのカーネルでの NAT
も完全に再実装されました。

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

<sect><!--Where is the official Web Site and List?-->
公式ウェブサイトやメーリングリストはどこにありますか？

<p><!--There are three official sites:-->
三つの公式サイトがあります：
<itemize>
<item><!--Thanks to <url url="http://netfilter.filewatcher.org/" name="Filewatcher">.
-->
<url url="http://netfilter.filewatcher.org/" name="Filewatcher"> に感謝。
<item><!--Thanks to <url url="http://netfilter.samba.org/" name="The Samba Team and 
SGI">.
-->
<url url="http://netfilter.samba.org/" name="Samba チームと SGI"> に感謝。
<item><!--Thanks to <url url="http://netfilter.gnumonks.org/" name="Harald Welte">.
-->
<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/">
-->
<url url="http://www.netfilter.org/"> や <url url="http://www.iptables.org/">
経由でラウンドロビン DNS を利用して、上に挙げたサイトのすべてに
アクセスできます。

<p><!--For the official netfilter mailing list, see
<url url="http://www.netfilter.org/contact.html#list" name="netfilter List">.
-->
公式な netfilter のメーリングリストに関しては、
<url url="http://lists.samba.org/" name="netfilter List">を参照ください。

<sect1><!--What is Network Address Translation?-->
ネットワークアドレス変換とは何ですか？

<p>
<!--
Normally, packets on a network travel from their source (such as your
home computer) to their destination (such as www.gnumonks.org)
through many different links: about 19 from where I am in Australia.
None of these links really alter your packet: they just send it
onward.
-->
通常、ネットワーク上のパケットは、送信元（例：家にあるコンピュータ）
から宛先（例：www.gnumonks.org）まで、たくさんのいろいろなリンク
（オーストラリアの僕のいるところからだと 19 個くらい）を通って届きます。
こうしたリンクは、パケットの中身を変えたりはしません。
ただ先へ送信するだけです。

<p>
<!--
If one of these links were to do NAT, then they would alter the source
or destinations of the packet as it passes through.  As you can
imagine, this is not how the system was designed to work, and hence
NAT is always something of a crock.  Usually the link doing NAT will
remember how it mangled a packet, and when a reply packet passes
through the other way, it will do the reverse mangling on that reply
packet, so everything works.
-->
これらのリンクのどれかが NAT を行うとすると、パケットが通過するたびに、
それの送信元か宛先を書きかえることになります。お分かりでしょうが、
それはシステムが本来行うのに望ましい動作ではなく、従って NAT
は常にかなりの厄介者なのです。一般に NAT を行うリンクは、
パケットをどのように料理したのかを覚えているので、
反対方向からリプライのパケットが返ってきたときには、
そのパケットに行きと反対の操作を行い、それで全てが上手くいくわけです。
<!--
訳者ノート：mangle という単語を辞書でひくと、「めった切りにする、
押しつぶす」「台無しにする」といった意味が出てきます。ここでは前者に近い
のでしょうが、「めった切り」ではパケット・フラグメントのようですし、
「押しつぶす」ではパケット圧縮みたいなので、この訳文全体において、「料理する」
という意訳をあててます。もっと適切な訳語があればご指摘下さい。
-->

<sect1><!--Why Would I Want To Do NAT?-->
どうして NAT が必要なのですか？

<p><!--In a perfect world, you wouldn't.  Meanwhile, the main reasons are:-->
完全な世界だったら必要ないでしょう。必要な主たる根拠としては：

<descrip>
<!--
<tag/Modem Connections To The Internet/ Most ISPs give you a single IP
address when you dial up to them.  You can send out packets with any
source address you want, but only replies to packets with this source
IP address will return to you.  If you want to use multiple different
machines (such as a home network) to connect to the Internet through
this one link, you'll need NAT.
-->
<tag/インターネットへのモデム接続/ 大抵の ISP は、
ダイヤルアップ時に単一の IP アドレスを付与します。
お好みの送信元アドレスをつけてパケットを送出することも可能ですが、
ISP から付与された IP アドレスを送信元アドレスとするパケットに対してしか
リプライは届きません。もし複数のマシンを（ホームネットワークなどで）
一個のリンクを通してインターネットに接続したいのでしたら、
NAT が必要になります。

<p><!--This is by far the most common use of NAT today, commonly known as
`masquerading' in the Linux world.  I call this SNAT, because you
change the <bf>source</bf> address of the first packet.
-->
これが今日 NAT の利用法として最も一般的なもので、Linux 界では「IP
マスカレード」として知られています。これは最初に送出されるパケットの
<bf>送信元</bf>アドレスを変換するものなので、
僕はこれを SNAT と呼んでいます。

<!--
<tag/Multiple Servers/ Sometimes you want to change where packets
heading into your network will go.  Frequently this is because (as
above), you have only one IP address, but you want people to be able
to get into the boxes behind the one with the `real' IP address.  If
you rewrite the destination of incoming packets, you can manage this.
This type of NAT was called port-forwarding under previous versions of
Linux.
-->
<tag/複数のサーバ/ あなたが管理しているネットワーク宛てのパケットについて、
その行き先を変更したいことがあります。これは大抵（上記の通り）一個しか IP
アドレスを持ってないからで、それでもその「本当の」IP アドレスを持つ NAT
ボックスの背後にある端末にまで入れるようにしたいのです。
入ってくるパケットの宛先を書き換えれば、これを実現することができます。
この種の NAT は、Linux の以前のバージョンではポートフォワーディング
と呼ばれていました。

<p><!--A common variation of this is load-sharing, where the mapping
ranges over a set of machines, fanning packets out to them.  If you're
doing this on a serious scale, you may want to look at

<url url="http://linuxvirtualserver.org/" name="Linux Virtual Server">.
-->
これの一般的なバリエーションとして負荷分散があり、これはいくつかのマシン群
に対してマッピングを施し、パケットをそれらのマシンに振り分けます。
もしあなたがこれをかなりの規模で行っているなら、
以下のページを見る必要があるかもしれません。

<url url="http://linuxvirtualserver.org/" name="Linux Virtual Server">

<!--
<tag/Transparent Proxying/ Sometimes you want to pretend that each
packet which passes through your Linux box is destined for a program
on the Linux box itself.  This is used to make transparent proxies: a
proxy is a program which stands between your network and the outside
world, shuffling communication between the two.  The transparent part
is because your network won't even know it's talking to a proxy,
unless of course, the proxy doesn't work.
-->
<tag/透過プロクシ/ Linux ボックスを通過するパケットが、その Linux
ボックス自身に向けたパケットであるかのように見せかけたいときがあります。
これは透過プロクシを構築することで実現されます　−プロクシは、
内部ネットワークと外界の間に立つプログラムで、分けられた二つのネットワーク
を繋いで通信できるようにします。透過と呼ばれるのは、内部ネットワークは
プロクシと通信していることにさえ気付かないからです。もちろん、
プロクシがちゃんと動作していれば、の話ですが。

<p><!--Squid can be configured to work this way, and it is called
redirection or transparent proxying under previous Linux versions.
-->
Squid はこのように動作するように設定可能で、Linux の以前のバージョンでは
リダイレクションとか透過プロクシとか呼ばれています。
</descrip>

<sect><!--The Two Types of NAT-->
NAT の二つのタイプ

<p><!--I divide NAT into two different types: <bf>Source NAT</bf> (SNAT)
and <bf>Destination NAT</bf> (DNAT).
-->
僕は NAT を二つのタイプに分けています　−<bf>送信元 (Source) NAT</bf>（SNAT）と
<bf>宛先 (Destination) NAT</bf>（DNAT）です。

<p><!--Source NAT is when you alter the source address of the first
packet: i.e. you are changing where the connection is coming from.
Source NAT is always done post-routing, just before the packet goes
out onto the wire.  Masquerading is a specialized form of SNAT.
-->
送信元 NAT とは、最初のパケットの送信元アドレスを変換するもので、
つまりはコネクションの送信元を書き換えるのです。送信元 NAT
は常にルーティングの後、パケットが回線にのる直前に行われます。
IP マスカレードは、SNAT を特化させたものです。

<p><!--Destination NAT is when you alter the destination address of the
first packet: i.e. you are changing where the connection is going to.
Destination NAT is always done before routing, when the packet first
comes off the wire.  Port forwarding, load sharing, and transparent
proxying are all forms of DNAT.
-->
宛先 NAT とは、最初のパケットの宛先 IP アドレスを変換するもので、つまりは
コネクションの行き先を書き換えるのです。宛先 NAT は常にルーティングの前、
パケットを回線から取り出したときに行われます。ポートフォワーディング、
負荷分散、そして透過プロクシは、全て DNAT に含まれます。

<sect><!--Quick Translation From 2.0 and 2.2 Kernels-->
2.0、2.2系カーネルからの手っ取り早い移行

<p><!--Sorry to those of you still shell-shocked from the 2.0 (ipfwadm) to
2.2 (ipchains) transition.  There's good and bad news.
-->
2.0 系（ipfwadm）から 2.2 系（ipchains）への移行の後遺症を未だ抱えている方
には申し訳ありませんが、良いニュースと悪いニュースがあります。

<p><!--Firstly, you can simply use ipchains and ipfwadm as before.  To do
this, you need to insmod the `ipchains.o' or `ipfwadm.o' kernel
modules found in the latest netfilter distribution.  These are
mutually exclusive (you have been warned), and should not be combined
with any other netfilter modules.
-->
まず第一に、これまで通り ipchains と ipfwadm をそのまま使えます。
そうするには、最新の netfilter ディストリビューションの中の、ipchains.o
もしくは ipfwadm.o カーネルモジュールを組み込む必要があります。
これら二つのモジュールは（知っての通り）互いに排他的なので、
他のいかなる netfilter モジュールとも一緒に使うべきではありません。

<p><!--Once one of these modules is installed, you can use ipchains and
ipfwadm as normal, with the following differences:
-->
一旦モジュールが組み込まれれば、これまで通り ipchains や ipfwadm を利用
できますが、以下の相違点があります：

<itemize>
<item><!--Setting the masquerading timeouts with ipchains -M -S, or
	ipfwadm -M -s does nothing.  Since the timeouts are longer for
	the new NAT infrastructure, this should not matter.
-->
ipchains -M -S や ipfwadm -M -s でマスカレードのタイムアウトを設定しても意味
がありません。というのも、これらのタイムアウト時間は新しい NAT の内部で用い
られているタイムアウトより長いので、これらのタイムアウト時間は適用されること
がありません。

<item><!-- The init_seq, delta and previous_delta fields in the verbose
	masquerade listing are always zero.
-->
冗長なマスカレードリストにおける、init_seq, delta, そして previous_delta
フィールドが常に 0。

<item><!-- Zeroing and listing the counters at the same time `-Z -L' does
        not work any more: the counters will not be zeroed.
-->
`-Z -L' で、カウンタのゼロ化とリスト表示を同時に行うことはできません
　−カウンタが 0 にならないからです。

<item><!-- The backward compatibility layer doesn't scale very well for
	large numbers of connections: don't use it for your corporate
	gateway!
-->
下位互換性レイヤは、多数のコネクションにあまりうまく追従できません。
あなたの会社のゲートウェイには、それを利用しないでください！
</itemize>

<!--
Hackers may also notice:
-->
ハッカーの人達は以下のことにも注意してください：

<itemize>
<item><!-- You can now bind to ports 61000-65095 even if you're
	masquerading.  The masquerading code used to assume anything
	in this range was fair game, so programs couldn't use it.
-->
現在は、IP マスカレードをしていても、61000-65095 番ポートを bind 可能です。
以前の IP マスカレードは、この範囲のポートを占有することは正当と考えて作られ
ていたので、他のプログラムが使うことはできませんでした。

<item><!-- The (undocumented) `getsockname' hack, which transparent proxy
	programs could use to find out the real destinations of
	connections no longer works.
-->
（ドキュメント化されてなかった）`getsockname' をハックして透過プロクシに用い、
コネクションの本当の宛先がどこであるか知るということはもうできなくなりました。

<item><!-- The (undocumented) bind-to-foreign-address hack is also not
	implemented; this was used to complete the illusion of
	transparent proxying.
-->
（ドキュメント化されてなかった）未知のアドレスへの bind のハッキングもできま
せん。この手法は透過プロクシの錯覚を完璧にするのに用いられました。
</itemize>

<sect1><!-- I just want masquerading!  Help!-->
僕は IP マスカレードを使いたいだけなんです！　助けて！

<p><!--This is what most people want.  If you have a dynamically allocated
IP PPP dialup (if you don't know, this is you), you simply want to
tell your box that all packets coming from your internal network
should be made to look like they are coming from the PPP dialup box.
-->
これこそ大部分の人が求めるものでしょう。もし PPP ダイヤルアップで動的に
IP アドレスを割り当てられているのでしたら（分からないとしても、
あなたのはそうなっています）、内部ネットワークからの全てのパケットが、
PPP ダイヤルアップボックスからのパケットであるかのようにしたいのです。

<tscreen><verb>
# Load the NAT module (this pulls in all the others).
modprobe iptable_nat

# In the NAT table (-t nat), Append a rule (-A) after routing
# (POSTROUTING) for all packets going out ppp0 (-o ppp0) which says to
# MASQUERADE the connection (-j MASQUERADE).
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
</verb></tscreen>

<!--
Note that you are not doing any packet filtering here: for that, see
the Packet Filtering HOWTO: `Mixing NAT and Packet Filtering'.
-->
ここでは全くパケットをフィルタリングしてないことに注意してください。
パケットフィルタリングに関しては、Packet Filtering HOWTO の中の、
「Mixing NAT and Packet Filtering（NAT
とパケットフィルタリングの混合）」を参照してください。

<sect1><!-- What about ipmasqadm?-->
ipmasqadm はどうしたの？

<p><!--This is a much more niche userbase, so I didn't worry about
backward compatibility as much.  You can simply use `iptables -t nat'
to do port forwarding.  So for example, in Linux 2.2 you might have
done:
-->
これはずっと範囲の狭いユーザベースのためのものなので、
他の機能と同じほどには下位互換性を気にかけていませんでした。
ポートフォワーディングをやるなら、`iptables -t nat' でだってできます。
ですから例えば Linux カーネル 2.2 系でやってきた：

<tscreen><verb>
# Linux 2.2
# Forward TCP packets going to port 8080 on 1.2.3.4 to 192.168.1.1's port 80
ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80
</verb></tscreen>

<!--
Now you would do:
-->
の代わりに今なら：

<tscreen><verb>
# Linux 2.4
# Append a rule before routing (-A PREROUTING) to the NAT table (-t nat) that
# TCP packets (-p tcp) going to 1.2.3.4 (-d 1.2.3.4) port 8080 (--dport 8080)
# have their destination mapped (-j DNAT) to 192.168.1.1, port 80
# (--to 192.168.1.1:80).
iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 8080 \
        -j DNAT --to 192.168.1.1:80
</verb></tscreen>

<sect><!--Controlling What To NAT-->
何に NAT を行うかを制御する

<p><!--You need to create NAT rules which tell the kernel what connections
to change, and how to change them.  To do this, we use the very
versatile <tt>iptables</tt> tool, and tell it to alter the NAT table by
specifying the `-t nat' option.
-->
NAT を行うには、どのコネクションに変換をかけ、どのように変換を行うかについて
カーネルに指示する NAT ルールをつくる必要があります。この行うため、とても
融通が利く <tt>iptables</tt> ツールを利用し、`-t nat' オプションを指定
することで、NAT テーブルを変更するよう指示します。

<p><!--The table of NAT rules contains three lists called `chains': each
rule is examined in order until one matches.  The two chains are
called PREROUTING (for Destination NAT, as packets first come in), and
POSTROUTING (for Source NAT, as packets leave).  The third (OUTPUT)
will be ignored here.
-->
NAT ルールのテーブルは、`chains' と呼ばれる三種類のリストからなります。
いずれのルールについても、どれかが適合するまで順に調べられます。二種類の
chain には、PREROUTING（パケットを受信するたびに、宛先 NAT を行うのに利用）、
そして POSTROUTING（パケットを送信するたびに、送信元 NAT を行うのに利用）
があります。三番目のリスト(OUTPUT)はここでは無視されます。

<p><!--The following diagram would illustrate it quite well if I had any
artistic talent:
-->
僕にいくらかでもアーティスティックな才能があったら、下図は三種類の chain
を説明するものになるんですがね：

<tscreen><verb>
      _____                                     _____
     /     \                                   /     \
   PREROUTING -->[Routing ]----------------->POSTROUTING----->
     \D-NAT/     [Decision]                    \S-NAT/
                     |                            ^
                     |                            |  
                     |                            |
                     |                            |
                     |                            |
                     |                            |
                     |                            |
                     --------> Local Process ------
</verb></tscreen>

<!--
At each of the points above, when a packet passes we look up what
connection it is associated with.  If it's a new connection, we look
up the corresponding chain in the NAT table to see what to do with it.
The answer it gives will apply to all future packets on that
connection.
-->
上図のどのポイントにおいても、パケットが通過すると、関連するコネクション
を調べることになります。もしそれが新しいコネクションならば、
それにどういう処理を行うか知るために、NAT テーブルの中の関連するチェイン
を調べることになります。そこから得られる答えが、当該コネクション上の以後
全てのパケットに適用されます。

<sect1><!--Simple Selection using iptables-->
iptables を利用した単純な選択

<p><!--<tt>iptables</tt> takes a number of standard options as listed
below.  All the double-dash options can be abbreviated, as long as
<tt>iptables</tt> can still tell them apart from the other possible
options.  If your kernel has iptables support as a module, you'll need
to load the ip_tables.o module first: `insmod ip_tables'.
-->
<tt>iptables</tt> は、以下に列挙するたくさんの標準的なオプションを利用
します。iptables が別の利用可能なオプションと区別可能であるうちは、
二重ダッシュ '--' で始まるオプションにはすべて略語指定が使えます。
もしあなたのマシンのカーネルがモジュールとして <tt>iptables</tt>
をサポートしているなら、まず `insmod ip_tables' で ip_tables.o
モジュールをロードする必要があります。

<p><!--The most important option here is the table selection option, `-t'.
For all NAT operations, you will want to use `-t nat' for the NAT
table.  The second most important option to use is `-A' to append a
new rule at the end of the chain (e.g. `-A POSTROUTING'), or `-I' to
insert one at the beginning (e.g. `-I PREROUTING').
-->
ここで最も重要なオプションは、テーブル選択オプションである `-t' です。
あらゆる NAT の動作に関して、NAT テーブルに `-t nat' を使うことになる
でしょう。二番目に重要なオプションは、チェインの最後に新たなルールを追加する
`-A' オプション（例：`-A POSTROUTING'）か、チェインの最初にルールを挿入する
`-I'オプション（例：`-I PREROUTING'）です。

<p><!--You can specify the source (`-s' or `&#045;&#045;source') and destination
(`-d' or `&#045;&#045;destination') of the packets you want to NAT.  These
options can be followed by a single IP address (e.g. 192.168.1.1), a
name (e.g. www.gnumonks.org), or a network address
(e.g. 192.168.1.0/24 or 192.168.1.0/255.255.255.0).
-->
NAT を行いたいパケットの送信元（`-s' か `--source'）や宛先（`-d' か
`--destination'）も指定可能です。これらのオプションには、単一の IP アドレス
（例：192.168.1.1）、名前（例：www.gnumonks.org）、もしくはネットワーク
アドレス（例：192.168.1.0/24 や 192.168.1.0/255.255.255.0）が後に続きます。

<p><!--You can specify the incoming (`-i' or `&#045;&#045;in-interface') or outgoing
(`-o' or `&#045;&#045;out-interface') interface to match, but which you can
specify depends on which chain you are putting the rule into: at
PREROUTING you can only select incoming interface, and at POSTROUTING
you can only select outgoing interface.  If you use the
wrong one, <tt>iptables</tt> will give an error.
-->
適合する受信インタフェース（`-i' か `--in-interface'）か送信インタフェース
（`-o' か `--out-interface'）を指定することも可能ですが、指定可能かどうかは、
ルールを加えようとするチェインに依存します　―PREROUTING では受信インタ
フェースのみ選択可能ですし、POSTROUTING では送信インタフェース
のみ選択可能です。もしこれを間違うと、<tt>iptables</tt> はエラーを出します。

<sect1><!--Finer Points Of Selecting What Packets To Mangle-->
どのパケットを料理するか選択する賢いポイント

<p><!--I said above that you can specify a source and destination address.
If you omit the source address option, then any source address will
do.  If you omit the destination address option, then any destination
address will do.
-->
送信元アドレスや宛先アドレスを指定可能であると前に書きました。送信元アドレス
オプションを省略した場合、あらゆる送信元アドレスについて適用されます。
宛先アドレスオプションを省略した場合、あらゆる宛先アドレスについて適用
されます。

<p><!--You can also indicate a specific protocol (`-p' or `&#045;&#045;protocol'),
such as TCP or UDP; only packets of this protocol will match the rule.
The main reason for doing this is that specifying a protocol of tcp or
udp then allows extra options: specifically the `&#045;&#045;source-port' and
`&#045;&#045;destination-port' options (abbreviated as `&#045;&#045;sport' and `&#045;&#045;dport').
-->
TCP や UDP などの特定のプロトコルは、`-p' か `--protocol' で指定可能で、
そのプロトコルのパケットのみに対してルールが適用されます。
こうする主な理由は、TCP や UDP といったプロトコルを指定することで、
そのプロトコルに対しオプションを追加できることにあります　−具体的には、
`--source-port' や `--destination-port' オプション（`--sport' や
`--dport' と省略可能）です。

<p><!--These options allow you to specify that only packets with a certain
source and destination port will match the rule.  This is useful for
redirecting web requests (TCP port 80 or 8080) and leaving other
packets alone.
-->
これらのオプションにより、特定の送信元、宛先ポート番号を持ったパケットのみ
をルールに適合させることが可能になります。これはウェブリクエスト（TCP ポート
番号80番や8080番）をリダイレクトして、他のパケットを無視するのに使えます。

<p><!--These options must follow the `-p' option (which has a side-effect
of loading the shared library extension for that protocol).  You can
use port numbers, or a name from the /etc/services file.
-->
これらのオプションは、`-p' オプション（そのプロトコルに関する共有ライブラリ
拡張をロードする副作用がある）の後に続かなくてはなりません。ポート番号か、
/etc/services ファイルに記述された名前を使用可能です。

<p><!--All the different qualities you can select a packet by are detailed
in painful detail in the manual page (<tt>man iptables</tt>).
-->
パケットに選択できるあらゆる性質が、マニュアル（<tt>man iptables</tt>）
にいやになるほど詳細に記述されています。

<sect><!--Saying How To Mangle The Packets-->
パケットの料理法の解説

<p><!--So now we know how to select the packets we want to mangle.  To
complete our rule, we need to tell the kernel exactly what we want it
to do to the packets.
-->
ここまでくれば、料理するべきパケットを選別する方法は分かっています。ルール
を完全なものにするため、パケットに対してやるべきことを正確にカーネルに指示
する必要があります。

<sect1><!--Source NAT-->
送信元 NAT

<p><!--You want to do Source NAT; change the source address of connections
to something different.  This is done in the POSTROUTING chain, just
before it is finally sent out; this is an important detail, since it
means that anything else on the Linux box itself (routing, packet
filtering) will see the packet unchanged.  It also means that the `-o'
(outgoing interface) option can be used.
-->
送信元 NAT を行うということは、送信元アドレスを何か別のものに変換するという
ことです。これは POSTROUTING チェインのもとで、最終的にパケットが送信される
直前に行われます　−これは重要な点で、というのも Linux ボックス自身の上で
行われる他のどんな操作（ルーティング、パケットフィルタリング）も、パケットは
書き換えないということを意味するからです。それはまた、`-o'
（送信インタフェース）オプションで実現可能であるということでもあります。

<p><!--Source NAT is specified using `-j SNAT', and the `&#045;&#045;to-source'
option specifies an IP address, a range of IP addresses, and an
optional port or range of ports (for UDP and TCP protocols only).
-->
送信元 NAT は、`-j SNAT' を使って指定し、`--to-source' オプションにより、
特定の IP アドレス、IP アドレスの範囲、そして（UDP, TCP プロトコルの場合
のみ）特定のポート番号やポート番号の範囲を指定します。

<tscreen><verb>
## Change source addresses to 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

## Change source addresses to 1.2.3.4, ports 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
</verb></tscreen>

<sect2><!--Masquerading-->
IP マスカレード

<p><!--There is a specialized case of Source NAT called masquerading: it
should only be used for dynamically-assigned IP addresses, such as
standard dialups (for static IP addresses, use SNAT above).
-->
IP マスカレードと呼ばれる送信元 NAT の特殊なケースがあります。これは、
標準的なダイヤルアップ接続などの、IP アドレスが動的に割り当てられる場合
にのみ利用すべきものです（静的に IP アドレスが割り当てられるなら、上記の SNAT
を使ってください）。

<p><!--You don't need to put in the source address explicitly with
masquerading: it will use the source address of the interface the
packet is going out from.  But more importantly, if the link goes
down, the connections (which are now lost anyway) are forgotten,
meaning fewer glitches when connection comes back up with a new IP
address.
-->
IP マスカレードをやるのに、送信元アドレスを明示的に指定する必要はありません。
IP マスカレードは、パケットが出て行くインタフェースの送信元アドレスを利用
します。ですがもっと重要なのは、そのリンクが落ちた場合に、（切られてしまった）
そのコネクションが忘れられてしまっても、新たに IP アドレスが割り当てられて
コネクションが復帰したときに、ほとんど誤動作が起きないということです。

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

<sect1><!--Destination NAT-->
宛先 NAT

<p><!--This is done in the PREROUTING chain, just as the packet comes in;
this means that anything else on the Linux box itself (routing, packet
filtering) will see the packet going to its `real' destination.  It
also means that the `-i' (incoming interface) option can be used.
-->
これは PREROUTING チェインのもとで、パケットが入ってきたその時に行われます
　−これは、Linux ボックス自身の上で行われる他のどんな操作（ルーティング、
パケットフィルタリング）も、パケットはその「本当の」宛先を指しているところで
行うからです。それは `-i'（受信インタフェース）オプションで実現可能であると
いうことでもあります。

<p><!--Destination NAT is specified using `-j DNAT', and the
`&#045;&#045;to-destination' option specifies an IP address, a range of IP
addresses, and an optional port or range of ports (for UDP and TCP
protocols only).
-->
宛先 NAT は、`-j DNAT' を使って指定し、`--to-destination' オプションにより、
特定の IP アドレス、IP アドレスの範囲、そして（UDP, TCP プロトコルの場合のみ）
特定のポート番号やポート番号の範囲を指定します。

<tscreen><verb>
## Change destination addresses to 5.6.7.8
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8

## Change destination addresses to 5.6.7.8, 5.6.7.9 or 5.6.7.10.
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8-5.6.7.10

## Change destination addresses of web traffic to 5.6.7.8, port 8080.
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \
	-j DNAT --to 5.6.7.8:8080
</verb></tscreen>

<sect2><!--Redirection-->
リダイレクション

<p><!--There is a specialized case of Destination NAT called redirection:
it is a simple convenience which is exactly equivalent to doing DNAT
to the address of the incoming interface.
-->
リダイレクションと呼ばれる宛先 NAT の特殊なケースがあります　−受信
インタフェースのアドレスへの DNAT を行うのと全く同じ効果があり、
簡単便利なものです。

<tscreen><verb>
## Send incoming port-80 web traffic to our squid (transparent) proxy
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
	-j REDIRECT --to-port 3128
</verb></tscreen>

<!--Note that squid needs to be configured to know it's a transparent proxy!
-->
squid が透過型プロキシとして動作するよう設定する必要があるのに注意すること！

<sect1><!--Mappings In Depth-->
突っ込んだマッピング

<p><!--There are some subtleties to NAT which most people will never have
to deal with.  They are documented here for the curious.
-->
ほとんどの人には全く関係ない、巧妙なテクニックが NAT にはいくつかあります。
ここでは好奇心の強い人のためにドキュメント化しておきます。

<sect2><!--Selection Of Multiple Addresses in a Range-->
ある範囲の複数のアドレスからの選択

<p><!--If a range of IP addresses is given, the IP address to use is
chosen based on the least currently used IP for connections the
machine knows about.  This gives primitive load-balancing.
-->
ある範囲の IP アドレスが与えられ、使用する IP アドレスを、そのマシンが通信
したうち最も最近利用された IP アドレスをもとに選択します。これにより原始的
な負荷調整が行えます。

<sect2><!--Creating Null NAT Mappings-->
NAT 不使用マッピングの生成

<p><!--You can use the `-j ACCEPT' target to let a connection through
without any NAT taking place.
-->
全く NAT を用いないコネクションを張らせる指定として `-j ACCEPT' があります。

<sect2><!--Standard NAT Behavior-->
標準的な NAT の動作

<p><!--The default behavior is to alter the connection as little as
possible, within the constraints of the rule given by the user.  This
means we won't remap ports unless we have to.
-->
デフォルトでは、ユーザによって与えられたルールの制約内で、コネクションの
変更を出来る限り小さくするべきです。つまり、その必要がなければ、ポート番号
を再マッピングしてはならないということです。

<sect2><!--Implicit Source Port Mapping-->
暗黙の送信元ポートマッピング

<p><!--Even when no NAT is requested for a connection, source port
translation may occur implicitly, if another connection has been
mapped over the new one.  Consider the case of masquerading, which
is rather common:
-->
たとえあるコネクションに NAT が設定されていなくても、
先に張られた別のコネクションがその新たなコネクションにアドレス
が重なるようにマッピングされている場合には、
送信元ポート変換が暗黙のうちに行われることがあります。
IP マスカレードのケースを考えると、これはかなり一般的なことです：

<enum>
<item><!-- A web connection is established by a box 192.1.1.1 from port
   1024 to www.netscape.com port 80.
-->
IP アドレス 192.1.1.1 の端末によって、ウェブコネクションがポート1024
番から www.netscape.com のポート80番に確立されているとします。

<item><!-- This is masqueraded by the masquerading box to use its source
   IP address (1.2.3.4).
-->
この接続はマスカレードボックスの送信元 IP アドレス（1.2.3.4）
を使用してマスカレードされています。

<item><!-- The masquerading box tries to make a web connection to
   www.netscape.com port 80 from 1.2.3.4 (its external interface
   address) port 1024.
-->
次にマスカレードボックス自身が、（外部インタフェースの IP アドレスである）
1.2.3.4 のポート 1024 番から、www.netscape.com のポート
80 番にウェブコネクションを確立しようとしたとします。

<item><!-- The NAT code will alter the source port of the second
   connection to 1025, so that the two don't clash.
-->
この時 NAT のコードは、二番目のコネクションの送信元ポート番号を
1025 番に変えるので、二つは衝突しません。
</enum>

<p><!--When this implicit source mapping occurs, ports are divided into
three classes:
-->
この暗黙の送信元マッピングに関して、ポートは三つのクラスに分けられます：

<itemize>
<item><!-- Ports below 512-->
512番以下のポート
<item><!-- Ports between 512 and 1023-->
512〜1023番のポート
<item><!-- Ports 1024 and above.-->
1024番以上のポート
</itemize>

<!--
A port will never be implicitly mapped into a different class.
-->
元のポートと異なるクラスのポートに暗黙のうちにマッピングされることは
決してありません。

<sect2><!--What Happens When NAT Fails-->
NAT が失敗すると何が起こるか

<p><!--If there is no way to uniquely map a connection as the user
requests, it will be dropped.  This also applies to packets which
could not be classified as part of any connection, because they are
malformed, or the box is out of memory, etc.
-->
ユーザが要求するコネクションを一意にマップすることができない場合、
その接続要求は廃棄されます。また、パケットが正しく構成されていなかったり、
NAT ボックスのメモリが不足しているなどの理由で、どのコネクションの一部とも
分類できなかったパケットも同様に破棄されます。

<sect2><!--Multiple Mappings, Overlap and Clashes-->
複数のマッピング、重複、そして衝突

<p><!--You can have NAT rules which map packets onto the same range; the
NAT code is clever enough to avoid clashes.  Hence having two rules
which map the source address 192.168.1.1 and 192.168.1.2 respectively
onto 1.2.3.4 is fine.
-->
様々なアドレスを属性にしているパケットに対して、ある一つのアドレス
をマッピングする NAT ルールを設定することは可能です　−NAT
のコードは衝突を回避するように周到に書かれています。従って、
送信元アドレスとして 192.168.1.1 と 192.168.1.2 の両方に対して
1.2.3.4 をマップしても大丈夫です。

<p><!--Furthermore, you can map over real, used IP addresses, as long as
those addresses pass through the mapping box as well.  So if you have
an assigned network (1.2.3.0/24), but have one internal network using
those addresses and one using the Private Internet Addresses
192.168.1.0/24, you can simply NAT the 192.168.1.0/24 source addresses
onto the 1.2.3.0 network, without fear of clashing:
-->
更にはマッピングするマシンを通過しないと到達できないアドレスでさえあれば、
実際に使用されてる IP アドレスの上に重ねてマッピングすることも同様に可能です。
つまりインターネット用のアドレス (1.2.3.0/24) が割り当てられてはいるが、
実際の内部ネットワークはこれらのアドレスと同時に 192.168.1.0/24
のとプライベート・インターネット・アドレスを使っていたとしても、
192.168.1.0/24 のソースアドレスを 1.2.3.0 のネットワークに単純に
マッピングするだけで、衝突の恐れなしに NAT 可能です：

<tscreen><verb>
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
	-j SNAT --to 1.2.3.0/24
</verb></tscreen>

<p><!--The same logic applies to addresses used by the NAT box itself:
this is how masquerading works (by sharing the interface address
between masqueraded packets and `real' packets coming from the box
itself).
-->
同じ理屈が、NAT ボックス自身により使用されるアドレスにもあてはまります
　−これこそが （マスカレードされるパケットと、ボックス自身から来る「本当の」
パケットの間でインタフェースのアドレスを共有することによる）IP マスカレード
の動作なのです。

<p><!--Moreover, you can map the same packets onto many different targets,
and they will be shared.  For example, if you don't want to map
anything over 1.2.3.5, you could do:
-->
その上、同じパケットを幾つもの異なるターゲットにマップ可能で、そのマッピング
は共有されます。例えば、IP アドレス 1.2.3.5 にマッピングをしたくない場合は、
以下のようにすれば可能です：

<tscreen><verb>
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
	-j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254
</verb></tscreen>

<sect2><!--Altering the Destination of Locally-Generated Connections-->
ローカルに生成されたコネクションの宛先の変更

<p><!--The NAT code allows you to insert DNAT rules in the OUTPUT chain,
but this is not fully supported in 2.4 (it can be, but it requires a
new configuration option, some testing, and a fair bit of coding, so
unless someone contracts Rusty to write it, I wouldn't expect it
soon).
-->
NAT のコードは、OUTPUT チェインの中に DNAT ルールを挿入することを許可
しますが、カーネル 2.4 では完全にはサポートされていません
(可能ではあるのですが、新しい設定オプション、ある程度のテスト、
そしてかなりのコーディングが必要になります。
それは誰かが Rusty にそうしたものを書くと請け負ってくれない場合の話ですが、
僕としては、すぐにそうなるとは期待していません)。

<p><!--The current limitation is that you can only change the destination
to the local machine (e.g. `j DNAT &#045;&#045;to 127.0.0.1'), not to any other
machine, otherwise the replies won't be translated correctly.
-->
現在ある制限は、宛先をローカルマシンにしか変更できないことで
(例:`j DNAT --to 127.0.0.1')、他のどのマシンにも変更できず、
そうでないとリプライが正しく転送されないのです。

<sect><!--Special Protocols-->
特殊なプロトコル

<p><!--Some protocols do not like being NAT'ed.  For each of these
protocols, two extensions must be written; one for the connection
tracking of the protocol, and one for the actual NAT.
-->
NAT には適さないプロトコルも存在します。こうしたプロトコルについては、
二つの拡張がなされなくてはなりません　−そのプロトコルのコネクションの追跡
に関する拡張と、NAT そのものの拡張です。

<p><!--Inside the netfilter distribution, there are currently modules for
ftp: ip_conntrack_ftp.o and ip_nat_ftp.o.  If you insmod these into
your kernel (or you compile them in permanently), then doing any kind
of NAT on ftp connections should work.  If you don't, then you can
only use passive ftp, and even that might not work reliably if you're
doing more than simple Source NAT.
-->
netfilter ディストリビューションの中には、
現在 FTP 用のモジュール　−ip_conntrack_ftp.o と ip_nat_ftp.o
があります。これらのモジュールをカーネルに組み込めば
（さもなくばモジュールではなくカーネル自体に組み込めば）、
FTP コネクションに対してどの種類の NAT も使う事ができます。
もしモジュールを組み込まなければ、パッシブモードでしか FTP
を利用できませんし、単純な送信元 NAT 以外に何かしようとしても、
確実に動作してくれないかもしれません。

<sect><!--Caveats on NAT-->
NAT に関する注意

<p><!--If you are doing NAT on a connection, all packets passing
<bf>both</bf> ways (in and out of the network) must pass through the
NAT'ed box, otherwise it won't work reliably.  In particular, the
connection tracking code reassembles fragments, which means that not
only will connection tracking not be reliable, but your packets may
not get through at all, as fragments will be withheld.
-->
一本のコネクション上で NAT を行う場合、<bf>両</bf>方向（ネットワークの中へ
／ネットワークの外へ）の全てのパケットが、NAT ボックスを通過しなければならず、
そうでないと確実には動作しません。特に、コネクション追跡を行うコードが断片化
されたパケットの再構成も行っているため、コネクション追跡が不確実になるだけ
ではなく、断片化されたパケットが全て留まってしまい再構成されず、パケット
が全く通らなくなってしまうかもしれません。

<sect><!--Source NAT and Routing-->
送信元 NAT とルーティング

<p><!--If you are doing SNAT, you will want to make sure that every
machine the SNAT'ed packets goes to will send replies back to the NAT
box.  For example, if you are mapping some outgoing packets onto the
source address 1.2.3.4, then the outside router must know that it is
to send reply packets (which will have <bf>destination</bf> 1.2.3.4)
back to this box.  This can be done in the following ways:
-->
SNAT を行う場合、SNAT されたパケットの宛先になるどのマシンも、
そのリプライを NAT ボックスにちゃんと送り返すようにしたいはずです。
例えば、特定の送信パケットに対して、送信元アドレスを 1.2.3.4
にマッピングする設定を行う場合は、NAT ボックスの外側にあるルータが、
リプライ・パケット（<bf>宛先</bf>が 1.2.3.4）を、この NAT
ボックスに送り返すようにしなくてはなりません。
これは以下のような方法で実現されます：

<enum>
<item><!-- If you are doing SNAT onto the box's own address (for which
       routing and everything already works), you don't need to do
       anything.-->
（ルーティングなど諸々が既に稼動している）NAT ボックス自身のアドレスに
SNAT マッピングしているなら、あなたは何もする必要はありません。

<item><!-- If you are doing SNAT onto an unused address on the local LAN
       (for example, you're mapping onto 1.2.3.99, a free IP on your
       1.2.3.0/24 network), your NAT box will need to respond to ARP
       requests for that address as well as its own: the easiest way
       to do this is create an IP alias, e.g.:-->
ローカル LAN 上で利用されていないアドレスに SNAT マッピングするなら
（例えば、1.2.3.0/24 ネットワーク上で、空き IP アドレスである
1.2.3.99 にマッピングする）、NAT ボックスは、自分自身のアドレスに対する
ARP リクエストに加え、そのマッピングしたアドレスに対する ARP
リクエストにもレスポンスを返す必要が出てきます。これを行うには、
以下の例のように IP alias を作成するのが最も簡単な方法です。
<tscreen><verb>
# ip address add 1.2.3.99 dev eth0
</verb></tscreen>

<item><!-- If you are doing SNAT onto a completely different address, you
       will have to ensure that the machines the SNAT packets will hit
       will route this address back to the NAT box.  This is already
       achieved if the NAT box is their default gateway, otherwise you
       will need to advertise a route (if running a routing protocol)
       or manually add routes to each machine involved.-->
全く異なるアドレスに SNAT マッピングするなら、SNAT
されたパケットを受信するマシンが、パケットを NAT
ボックスにルーティングをすることになります。これは、NAT
ボックスがデフォルト・ゲートウェイに設定されていれば
そのままでうまくいきますが、そうでなければ
（ルーティング・プロトコルを動かしている場合）経路を広告するか、
さもなくば関連するマシン毎に経路を手動で追加してやる必要があります。
</enum>

<sect><!--Destination NAT Onto the Same Network-->
同一ネットワーク上での宛先 NAT

<p><!--If you are doing portforwarding back onto the same network, you
need to make sure that both future packets and reply packets pass
through the NAT box (so they can be altered).  The NAT code will now
(since 2.4.0-test6), block the outgoing ICMP redirect which is
produced when the NAT'ed packet heads out the same interface it came
in on, but the receiving server will still try to reply directly to
the client (which won't recognize the reply).
-->
同一ネットワーク内の通信でポートフォワーディングする場合、
出て行くパケットと戻ってくるパケットの両方がちゃんと
NAT ボックスを通過する（よってそれらパケットは内容に変更が加えられる）
ようにする必要があります。NAT のコードは現在（2.4.0-test6 以降）、
NAT されたパケットが入ってきたのと同じインタフェース
に出て行く際に送信される ICMP リダイレクトをブロックしますが、
受信するサーバは、（リプライを認識できない）クライアントに直接
リプライしようとし続けます。

<p><!--The classic case is that internal staff try to access your `public'
web server, which is actually DNAT'ed from the public address
(1.2.3.4) to an internal machine (192.168.1.1), like so:
-->
その典型的な例は、内部にある端末があなたのところのネットワークで
「外部に公開している」ウェブ・サーバーにアクセスしようとする場合で、
実際には以下のような設定により、パブリック・アドレス（1.2.3.4）
から内部のマシン（192.168.1.1）に DNAT されてしまいます。
<tscreen><verb>
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
	-p tcp --dport 80 -j DNAT --to 192.168.1.1
</verb></tscreen>

<p><!--One way is to run an internal DNS server which knows the real
(internal) IP address of your public web site, and forward all other
requests to an external DNS server.  This means that the logging on
your web server will show the internal IP addresses correctly.
-->
やり方の一つとして、公開用ウェブ・サイトの本当の（内部での）
IP アドレスを知っている内部用 DNS サーバを動かし、
それ以外の名前解決要求は全て外部用 DNS サーバに転送
するようにする方法があります。
つまり、ウェブ・サーバのログを取ってみれば、内部にある端末の
IP アドレスが正しく記録されているのが分かるでしょう
（訳注：内部にある端末からウェブ・サーバへのパケットが、
IP アドレス変換されることなく、NAT ボックスを経由せずに、
直接サーバへ届くことをいっている）。

<p><!--The other way is to have the NAT box also map the source IP address
to its own for these connections, fooling the server into replying
through it.  In this example, we would do the following (assuming the
internal IP address of the NAT box is 192.168.1.250):
-->
別のやり方としては、そうしたコネクションに関しては送信元
IP アドレスも NAT ボックス自身の IP アドレスにマップする
ように設定して、サーバをだまして NAT ボックスにリプライ
を返させるようにする方法があります。この例では、
以下のように設定することになります（NAT ボックスの内側の
IP アドレスを、192.168.1.250 と仮定します）：
<tscreen><verb>
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
	-p tcp --dport 80 -j SNAT --to 192.168.1.250
</verb></tscreen>

<!--
Because the <bf>PREROUTING</bf> rule gets run first, the packets will
already be destined for the internal web server: we can tell which
ones are internally sourced by the source IP addresses.
-->
<bf>PREROUTING</bf> ルールが最初に実行されるので、
上記ルールが実行される時には既に、パケットの宛先は内側にある
ウェブ・サーバに向けられています。どのパケットが内側から送出
されているかは、送信元 IP アドレスにより識別可能です。

<sect><!--Thanks-->
謝辞

<p><!--Thanks first to WatchGuard, and David Bonn, who believed in the
netfilter idea enough to support me while I worked on it.
-->
僕が netfilter に取り組んでいる間、netfilter のアイデアを信用してくれて僕を
サポートしてくれた、WatchGuard 社と David Bonn にまず感謝します。

<p><!--And to everyone else who put up with my ranting as I learnt about
the ugliness of NAT, especially those who read my diary.
-->
そして NAT の醜さについて知るたびに僕がわめき散らすのに我慢してくれたみん
な、特に僕の日記の読者に感謝します。

<p>Rusty.

<!-- 以下、訳者による謝辞 -->

<p><bf>訳者謝辞</bf>

<p>本日本語訳について、以下の方々が誤訳・誤記の指摘をして下さいました。
心から感謝します。

<itemize>
<item>office さん（office@office.ac）
<item>Shiro Kawai さん（shiro@lava.net）
<item>克さん（YRA05647@nifty.ne.jp）
<item>武井伸光さん（takei@webmasters.gr.jp）
<item>山森浩幸さん（h-yamamo@db3.so-net.ne.jp）
<item>水原文さん（mizuhara@acm.org）
</itemize>

</article>
