少し前、仕事で IP マスカレード技術の実装の特殊例についての調査を行った。Linuxカーネル 2.2 系を主な調査対象にし、あと隣席の FreeBSD 使いに何点か質問しながら FreeBSD 3.4 の実装も少し見させてもらった（やはりオープンソースというのはありがたい）。
IP マスカレードが最初に実装されたのは確か Linux だったと思うが、（FTP 以外にも）アプリケーション毎に個別対応を行ったモジュールを多数用意していることは、恥ずかしながらそのとき初めて知った。一ゲームソフトのマスカレード越しネットワーク対戦にカーネルレベルで対応するというのもある意味かなり奇異な感じもするが、このフットワークの軽さも Linux の強みなのだろう。
当時既に Linux カーネル 2.4 系のテスト版が公開されていたので、ついでにそのソースもダウンロードして見てみたのだが、マスカレード関係のコードがなくなっている。ありゃ？ と思いながら調べてみると、2.4 系カーネルでは、IP マスカレードやパケットフィルタリング関連の実装がカーネルからは独立し、Netfilter というツールで実現されるという。2.0 系から 2.2 系へのバージョンアップのときも、ファイアウォール設定ツール ipchains の新規導入があったが、今回はそれ以上ではないか。
調査自体には粗方目処がついていたが、興味本位で Netfilter をダウンロードしてソースを眺めてみた。が、構造自体ががらりと変わっていてちょっと挫けてしまった。そこで僕は気合を入れなおし、全身全霊でソースに飛び込み・・・というのはウソで、「ドキュメントないかな」と弱気に方向転換を図った。LDP 本家（Linux Documentation Project）を探したが、Netfilter を中心的に扱ったドキュメントは本文執筆時点ではまだなかった（と思う）。
Netfilter のページに戻ってみると、コアチームの Paul "Rusty" Russell が HOWTO を書いているではないか。でも、"Remarkably Unreliable Guides" ってネーミングだったので余りちゃんと見てなかったのだな。
さて、Rusty's Remarkably Unreliable Guides の元にまとめられた文書を読んでみると、結構表現がくだけていて（Linux 2.4 NAT HOWTO はさほどでもないが）作者のクセを感じさせた。大体本人自身、"The LDP guys no longer return my EMails" なんて書いている。これはしばらく LDP に登録されることもなかろう、僕が翻訳する余地があるのではないか、と思った次第である。
また、NAT 自体について何か技術的なメモをまとめておきたいな、という気持ちが Linux カーネルの調査をしているときに頭をもたげたこともある。
そもそも NAT（Network Address Translator）というのは文字通りネットワークアドレス（IP アドレス）変換技術であって、インターネットの爆発的な普及に伴い懸案となったアドレス資源の枯渇（IP アドレスは32ビットだから最大・・・という記述を雑誌なんかで見たことはあるでしょ？）を一時的に凌ぐための技術である。広い意味での NAT 技術は家庭にも LAN が構築される現状では欠かせないものになっている。
しかし、NAT には幾つか問題がある。技術思想自体が抱える問題については後述するが、その変種やら他の技術との組み合わせやらがいろいろあり、しかもその呼び名がそれぞれ違ったりするせいで理解するのが厄介なこともある。
広義の NAT と狭義の NAT、NAT と IP マスカレードの差異、といったところから始まり、そこにポート、静的、動的、フォワーディング、プロクシといった言葉が加わってくるともう何がなんだか、ということになってしまう。
NAT の公式な仕様（はいはい、RFC は「インターネットの公式仕様文書」じゃないですが）は RFC1631 The IP Network Address Translator (NAT) にある。
ここで LAN 内部でプライベートアドレスを用い、それを外に出るときにルータ、ゲートウェイ装置がグローバルアドレスに変換することで、LAN 内の端末数より IP アドレスの割り当てが少ない場合のインターネット接続を可能にしている（しかし、RFC1631 にはプライベートアドレスでなくローカルアドレスという表現が使われていて・・・あー、ややこし。プライベートアドレスについては、RFC1918 Address Allocation for Private Internets を参照してください）。
そして Linux に「IP マスカレード」が実装されるのだが、これもネットワークアドレス変換技術には違いないが、RFC1631 で定められた NAT とは別物と考えた方がよい。利用可能なグローバルが一個であることを前提としたものなので、単に IP アドレスを変換するだけでは LAN 内の端末を識別することができない。そこで TCP（UDP）のポート番号も変換対象にすることで、１対多の変換を可能にしている。そのため、IP マスカレードを NAPT（Network Address Port Translation）と言ったりもする。
ただ IP マスカレードだと、内部ネットワーク側の端末からしか通信を始められない（外から見れば、一台にしか見えないので）。そこで特定のポート番号宛てのパケットを内部の特定端末に通すよう固定的に設定可能にするのが静的マスカレード、もしくはポートフォワーディングと呼ばれる技術である。これにより利用可能になるアプリケーションも、チャット、ストリーミング、ネットゲーム系に多い。
またこの静的マスカレードにより、プライベートアドレスで構成される LAN 内にも外部にサーバーを公開することが可能になる。ただしダイヤルアップなどではプロバイダから配布される IP アドレスは一定ではないので通常のサーバーと同じようにはいかないのだが、それを動的に解決する方法も Dynamic DNS として既に実現されている。
IPv4 アドレスの枯渇防止に貢献をしている IP マスカレードであるが、問題もある。まずは、IP アドレス、ポート番号を書き換えてしまうこと自体から生じる問題がある。アプリケーションデータ部分に IP アドレス、ポート番号が直で入るようなプロトコルでは不具合が生じる。最も有名なのは FTP における PORT コマンドであるが、Linux ではそうしたアプリケーション毎にモジュールを用意することで対応していて、2.0、2.2 系のカーネルでは、FTP の他に以下のアプリケーションに個別対応している。
また実装の元祖だけあって、Linux の IP マスカレードだけに特化した情報ページである Linux IP Masquerade Resource や、アプリケーション毎の設定を集めた Masq Applications など、ウェブ上に有用なリソースが数多くある。
あと IP マスカレードで問題とされるのは、end-to-end 型の通信モデルが崩れてしまうこともある。IPv6 を推進する人達がこれを理由に挙げることが多い。これには幾分理念的な部分もあるが、マスカレードがネットワーク的な見通しを悪くしていることは確かだ。
IPv6 の実装として素晴らしい成果を上げている KAME プロジェクトの山本和彦さん（Mew の作者でもある）が、「俺は NAT を無くしたいから IPv6 のコードを書いてるんだ」とかつて力強く語られていたことを思い出す。
しかし、反対の方向から見ると、IP マスカレードのおかげで内部ネットワークが隠匿される、と考えることも可能である。たまに「IP マスカレードによりセキュリティが保たれ」みたいな記述を雑誌で見かけてのけぞることがあるが、全くハズレというわけではない。
また、IP アドレスやポート番号を検査するものにパケット・フィルタリングもあって、両者は近いレベルにある技術とも言える。かくして Linux 2.4 において、両機能は Netfilter としてカーネルから独立することになったのである・・・というのは、ファイアウォール設定ツールとしての ipchains からの流れから、ここまで書いてきて思いついた結論に過ぎない（笑）。前述の通り、Netfilter のソースを読んで内部を理解したわけではないので鵜呑みにしないように。
またここまでの既存技術の記述にも筆者の頭の悪さによる勘違いもあると思うので、気付いたら指摘してくださいね。あ、いろいろな NAT 技術について触れた RFC として、RFC2663 IP Network Address Translator (NAT) Terminology and Considerations があります。
さて、そこで Linux 2.4 NAT HOWTO になるのだが、ここでは Russell さんによる SNAT、DNAT という造語が用いられている。よく読めばこれが飽くまで分類の仕方であって NAT 実装の根本を変えるものではないのが分かるのだが、ただでさえ用語がいろいろあるのに 2.4 カーネル正式リリースとなったときに混乱が起きないとも限らない。僕が早めに訳しておくことで少しでも役に立てるかな、というのが翻訳をやろうと思った理由の一つ。
もう一つ自分でやろうと思ったのは、この分野（アドレス変換、フィルタリング）における JF での翻訳の進捗に満足してないことがあった。マスカレード関係でまず参照する Linux IP Masquerade HOWTO の最新版はこの文章を書いている2000年7月にも更新されているが、対応する日本語訳は一年以上更新されてない。また Linux 2.4 NAT HOWTO の Russell さんによる Linux IPCHAINS-HOWTO の翻訳も、一年近く前に予約が入れられたがまだ公開されてないようだ。直にこの状況は解消されるだろうけど。
また JF の活動は翻訳だけにとどまらず、オリジナルの技術文書も取り込んでいる。例えば ipchains にしても、おおつかまさひとさんが簡潔にして的確な ipchains-mini-HOWTO を書かれている。
それに日本語にしたいドキュメントがあるなら、ごちゃごちゃ言わずてめえが自分でやればよいのだ。これまでだってそのポリシーでやってきた。今回もそうしたまでである。
そのときはこの HOWTO 自体 unofficial という意識があったし、僕の理解が浅く、JF に収録される翻訳文書は LDP 関係やカーネル付属文書といった official なもの、という先入観があったので、これがその範疇に入る文書だとは思ってなかった。
しかし、JF で活動されている（というか普段から拙訳のチェックで大変お世話になっている）武井伸光さんから「"完成しました公開してます" では， JF 的にも， 日本での Linux に関する日本語状況的にもあまりうれしくないと思う」という指摘を受けたので、Linux 2.4 NAT HOWTO の日本語訳の当サイトでの公開を一旦停止し、JF に投げる準備に入りたいと思う。
ただ一つ書いておくと、「完成しました公開してます」というのは僕が翻訳をやる場合の大前提である。その後に「どんどん改良してくれい」というのが入れば、プロジェクト杉田玄白の趣意になる（と僕は勝手に解釈している）。前述の通り、僕もその方法論に実践してきたつもりである。それを「あまりうれしくない」といわれるのは少し悲しかった。
ただこうした文書を JF に集積する意義というのは十分に理解できる。というかそうすべきだ。僕自身そこに関われるというのはとても楽しみである。何より自分がやった翻訳文書が JF に収録されるかもしれないなんて一年前には夢にも思わなかった事態である。これが最初で最後だろうが、今この文書を書いている時点での感情は一旦すべてわきに置いて、道筋を教示していただいた武井さんには心から感謝したい。
[後記]：
この文章について何を書こうにも苦々しい思い出しかない。この文章に書かれている「JF での翻訳の進捗」は、その後大幅に改善している。