netfilter/iptables FAQ Harald Welte <laforge@gnumonks.org> Version $Revision: 1.24 $, $Date: 2001/08/23 17:53:53 $ 日本語訳: yomoyomo <ymgrtq@ma.neweb.ne.jp> v1.24j 2001 年 9 月 6 日 この文書は、netfilter メーリングリストでみかける、よく聞かれる質問 (Frequently Asked Questions)を集めたものです。 コメント / 追加 / より良い解説を歓迎しますので、 FAQ 管理者にまわしてください。 原文は にあります。 一般的な質問

この節は、メーリングリストで頻繁にみかけてきた、 netfilter に関連する一般的な質問(と netfilter に関係ない質問) を対象とします。 netfilter/iptables はどこから入手できますか?

Netfilter と IPtables は、Linux 2.4.x 系カーネルに統合されます。 ないしはミラーサイトから、 新しいカーネルを入手してください。

ユーザ空間のツールである 'iptables' は、 、 といったミラーにある netfilter ホームページから入手可能です。 netfilter の Linux 2.2 系へバックポートしたものはありますか?

いえ、現在のところありません。しかし、始めたいと思うなら、 ネットワーク・スタックのインタフェースはきれいにできてますので、 それほど難しいということはないはずです。

この方面で何か動きがありましたら、我々に知らせてください。 ICQ conntrack/NAT ヘルパー・モジュールはありますか?

Linux 2.2 のマシンでの IP マスカレードに慣れているなら、 クライアントどうしで直接 ICQ 通信するのには、ずっと ip_masq_icq モジュールを使ってきたことでしょう。 (訳注:ここで触れられている ip_masq_icq モジュールは、 より入手可能)。

しかし、誰もこのモジュールを netfilter 用に再実装しませんでした。 というのも、ICQ プロトコルはひどく汚いんです:) でも、 それが利用できるようになるのも、時間の問題だと私は思ってます。

Rusty(訳注: netfilter の主要開発者である Rusty Russell のこと) はかつて、あるプロトコルのモジュールを netfilter ディストリビューションに組み込むには、フリーなクライアントと フリーなサーバが少なくとも一つずつ存在しなければならない、と言いました。 ICQ に関して言えば、フリーなクライアントの方しか存在しませんので、 この基準には適合しません。(ここでフリーというのは自由のことで、 無料ビール(free beer)のフリーではありません。つまり、RMS の定義通り、 ということです) ip_masq_vdolive や ip_masq_quake などのモジュール群はどこに行ったのですか?

その必要がなくなったものもありますし、まだ netfilter に移植されてないものもあります。netfilter は、 UDP についても完全なコネクションの追跡を行いますし、また パケットの流れをできる限り妨げないようにするポリシーがありますので、 「やってみたら動く」というものもあります。 patch-o-matic とは一体何ですか? またそれを私はどのように使えばよいのですか?

2.4.x 系カーネルは安定版リリースですので、我々が現在開発中のものを、 リリース版のカーネルに持ちこむことはできません。我々のコードはすべて、 まず netfilter patch-o-matic において開発され、試験されます。 netfilter の最先端の機能を使いたいなら、patch-o-matic からパッチを一つ以上あてなくてはならないかもしれません。 最新の iptables パッケージ(もちろん CVS のソースでも大丈夫です) を netfilter ホームページからダウンロードすれば、patch-o-matic を使うことができます。

patch-o-matic は、すっきりしたユーザ・インタフェースを持っています。 make patch-o-matic と入力するだけです。カーネル・ツリーが /usr/src/linux にない場合は、iptables パッケージのトップ・ディレクトリで make KERNEL_DIR={your-kernel-dir} patch-o-matic としてください。patch-o-matic は、パッチ毎に、インストールされている カーネル・ソースにそのパッチが適合するかどうかをチェックします。 パッチが適合すれば、このパッチに関するより詳しい情報を表示するか、 パッチを適用するか、スキップして次のパッチに行くか…などの選択ができる、 小さなプロンプトが表示されます。 ipnatctl と、それに関する詳細な情報はどこにありますか?

ipnatctl は、2.3.x カーネルの頃、netfilter のごく初期の開発版において、 ユーザ空間から NAT ルールを設定するのに使われていました。 もう必要なくなったので、入手もできなくなりました。 ipatctl の機能はすべて、iptables 自身により提供されています。 Netfilter ホームページにある NAT HOWTO を参照ください (訳注: NAT HOWTO の日本語訳は、 にあります)。 ビルドの過程で起こる問題

iptables-1.1.1 が、カーネルが 2.4.0-test4 以上のとき、 コンパイルできないんです。

これは既知の問題です。どのパッチを適用するか検出するメカニズムが 壊れているのです。"make" のかわりに "make build" を試してください。

より良い解決法は、iptables を 1.1.2 以降にアップグレードすることです。 iptables 1.1.0 が最近のカーネル(2.3.99-pre8 以降) でコンパイルできないんです。

iptables の内部構造が変わってます。iptables を 1.1.1 以降にアップグレードしてください。 iptables-1.2.1a の patch-o-matic であてたパッチに、カーネルが 2.4.4 以降だと動かないものがあります。

iptables-1.2.2 リリース版か、netfilter CVS を利用してください。 ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP がコンパイルできません。

おそらく ip_nat_setup_info という名前の関数をコンパイルする際に問題が起きるのでしょう。

1.2.2 以前の iptables を使用しているなら、'dropped-table' パッチと 'ftp-fixes' パッチをあてる必要があります。

1.2.2 より後の iptables か、最近の CVS のソースを利用されている場合は、 'dropped-table' パッチをあてないでください。 このパッチは BALANCE, NETMAP, irc-nat, SAME, talk-nat との互換性がありません。 私は Alan Cox による 2.4.x-acXX シリーズのカーネルを使っているのですが、 問題が発生します。

netfilter コア・チームは、Linus のカーネル・ツリーの元で開発 をしていますので、-ac シリーズは、ご自身の責任の元でご利用ください。 実行時の問題 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb

このメッセージは、マルチキャスト・パケットが NAT テーブルを通る際に NAT のコードにより出力されるもので、今のところコネクション追跡部が マルチキャスト・パケットをうまく処理できないのが原因です。 マルチキャストが何であるか分からないか、 またはマルチキャストをまったく必要としないなら、 以下のようにしてください: iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

syslog かコンソールに以下のメッセージが表示されます: NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

このメッセージは、NAT のコードにより表示されます。 NAT を行うには、有効なコネクション追跡情報がないといけないので、 パケットを破棄しているのです。コネクション追跡部が conntrack 情報を決定できなかったパケットすべてに対し、このメッセージが表示されます。

考えられる理由としては: conntrack データベース中のエントリ数が上限に達した 逆向きの組が決定できなかった(マルチキャスト、ブロードキャスト) kmem_cache_alloc に失敗(メモリ不足) 確立されてないコネクションのリプライ マルチキャスト・パケット(一つ前の質問を参照してください) 短すぎる ICMP パケット ICMP パケットがフラグメントされている ICMP パケットのチェックサム値が間違っている

こうしたパケットのもっと詳細なログを取りたいなら(つまり、 リモート・プローブやスキャニング・パケットだと疑うなら)、 以下のルールを利用してください: iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID

そうです、パケットはフィルタ・テーブルに到達する前に、NAT のコードによって破棄されてしまうので、このルールを mangle テーブルに設定しなくてはなりません。 netfilter を、Linux をブリッジにするコードと組み合わせて使う ことができないんです

つまり、完全な透過型ファイアウォールを構築したいわけですね? 素晴らしい考えですね! 残念ですが、ブリッジのコードは、netfilter を含む普通のネットワーク・スタックを迂回してしまうのです。

しかし、既存のブリッジのコードを代替するものを書いている人がいます。 をご覧ください。

ブリッジング・ファイアウォールのサポートは、 非常に実験的とみなされていることにご注意ください。 IRC モジュールが、DCC RESUME を処理できません

そうですね、それは半分本当のことです。NAT モジュールだけでは 処理できません。NAT 抜きでファイアウォールを利用すれば、 それはうまくいきます。 複数のアドレスに対する SNAT は、どのように動作するのですか?

netfilter は、できる限りパケットに手を加えないように努めます。 ですので、我々のところにリブートしたてのマシンがあり、 SNAT ボックスの背後にいる誰かがローカル・ポート 1234 番でコネクションを開いた場合、netfilter ボックスは IP アドレスだけに手を加え、ポート番号はそのままにしておきます。

SNAT 用の IP アドレスが一個しかない場合、誰かが同じ送信元ポート番号 で別のコネクションを開くと同時に、netfilter は IP アドレスとポート番号の両方に手を加えなくてはならなくなります。

しかし、使用可能な IP アドレスが一個以上あるなら、 この場合も IP 部に手を加えるだけですみます。 ip_conntrack: maximum limit of XXX entries exceeded

このメッセージが syslog の中にあるのに気付いたら、ご利用の環境下では、 どうやら conntrack データベースが十分な数のエントリを持ってないようです。 デフォルトでは、コネクション追跡部の処理できる同時接続数には、 ある一定の上限があります。 この数は、ご利用のシステムのメモリ・サイズの上限に依ります (メモリが 64MB でしたら 4096 個、128MB でしたら 8192 個 ...)。

追跡するコネクションの数の上限を増やすことは簡単にできますが、 追跡するコネクション数ひとつあたり、swap できないカーネル・メモリを約 350 バイト食うことをお忘れなく!

上限を例えば 8192 に増やすには、以下のように入力してください: echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max 2.2.x 系カーネルのときに 'ipchains -L -M' でやったように、 追跡されている / マスカレードされているコネクションをすべて リストアップする方法はありますか?

proc ファイルシステム中に、/proc/net/ip_conntrack という名前のファイルがあります。以下のようにすれば、 このファイルを出力して表示できます。 cat /proc/net/ip_conntrack 有効なすべての IP テーブルを一覧する方法はありますか?

有効なすべての IP テーブルは、以下のようにしてリスト表示されます。 cat /proc/net/ip_tables_names iptables-1.2 の iptables-save や iptables-restore で Segmentation Fault が出るようになりました

既知のバグです。できるだけ速やかに、最新の CVS のソースか、 1.2.1 以降の iptables にアップグレードしてください。 iptables -L とすると、ルールの表示に大変時間がかかります

これは iptables が IP アドレス毎に DNS 検索を行っているためです。 各ルール 2 つのアドレスから構成されますので、最悪の場合、 ルール毎に 2 回 DNS 検索が入ります。

問題となるのは、プライベート IP アドレス(10.x.x.x や 192.168.x.x など) を使っている場合で、DNS はホスト名を解決できず、タイムアウトします。 こうしたタイムアウトの合計が、ご利用のルールセットによっては、 とても長い時間になるかもしれません。

DNS の逆引きを行わないようにするには、-n (numeric)オプションを入れて、 iptables をお使いください。 LOG ターゲットによるコンソールへのログ出力を止めさせるには どうすればよいですか?

syslogd を適切に設定しなくてはなりません - LOG ターゲットは、プライオリティ値 warning(4) で、ファシリティ値 kern のロギングを行います。 ファシリティ値とプライオリティ値についての詳細は、 syslogd.conf の man ページを参照してください。

デフォルトでは、プライオリティ値が debug(7) より重要なカーネルのメッセージがすべてコンソールに送られます。 この値を 7 から 4 まで上げれば、コンソール上に LOG メッセージが表示されることはありません。

こうすると、他の重要なメッセージもコンソールに表示されなく なるかも知れません。気をつけてください (syslog ファイルには影響しません)。 squid と iptables を使って透過型プロキシを構築するには どうすればよいでしょう?

まず第一に、当然ながら、適切な DNAT か REDIRECT のルールが必要となります。 squid が NAT ボックス自身の上で動くなら、REDIRECT のみ使ってください。 例えば: iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128

その後、squid を正しく設定しなくてはなりません。 我々がここで提供できる情報は限られていますので、 更に詳しい情報については、squid のドキュメントを参照ください。

Squid 2.3 での squid.conf に、以下のような設定が必要です: http_port 3128 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on Squid 2.4 になると、さらに設定行が必要になります: httpd_accel_single_host off LOG ターゲットはどのように使うのですか? LOG と DROP を両方使うことはできますか?

LOG ターゲットは、いわゆる「終了しないターゲット」です。 つまりそれは、パケットがルールに適合しても、そこで終了しません。 LOG ターゲットを利用すると、パケットはロギングされ、 ルール適合の検索が次のルールに引き継がれます。

では、ログを取り、同時に破棄するにはどうすればよいのでしょう? 最も簡単なのは、二つのルールを含むチェインをあつらえることです: iptables -N logdrop iptables -A logdrop -j LOG iptables -A logdrop -j DROP

今後パケットをログに記録してから破棄したい場合は、 "-j logdrop" を使うだけですみます。 netfilter の開発に関する質問 ユーザ空間からの QUEUE ターゲットの使い方が分からないんです

libipq というライブラリが、ユーザ空間でのパケット操作のために提供 されています。これに関するドキュメントは、現在 man ページの形式で存在します。iptables の開発コンポーネントをビルドし、 インストールする必要があります: make install-devel インストールしたら libipq(3) を参照ください。

libipq 用の Perl バインディングである、Perlipq にも興味があるかもしれません。そのバインディング自身が、 ライブラリの利用の一例になります。

その他のコード例として: netfilter CVS にある、testsuite/tools/intercept.c ipqmpd( 参照) netfilter-tools の一部である、nfqtest( 参照) 私はコードに貢献したいのですが、何をすれば良いか分かりません

netfilter コアチームは、望まれる変更や新機能の全てを一覧にした、 TODO リストを管理しています。このリストは anonymous CVS 経由で入手可能で、説明書は netfilter ホームページにあります。 あるいは、CVSweb を使って、 から取得可能です。 バグを修正したり、拡張部分を書きました。どうすればそれを寄贈できますか?

それを公開したい場合は、netfilter-devel メーリングリストまで送ってください。 購読に関する説明書は、 にあります。 パッチを送る正しいやり方は、以下のようなものです: Subject は、[PATCH] で始める メッセージ本体に直接含め、MIME 化しない。 diff 以外に、cvs-checkin/Changelog エントリをつける ルート・ディレクトリからの `diff -u old new' 形式にする (つまり、他のディレクトリにいても、 -p1 オプションでパッチを適用できるように) 日本語訳について

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

本日本語訳について、誤訳・誤記の指摘をして下さった つぎの方々に感謝します(50音順)。 office さん <office@office.ac> 小林雅典さん <zap03216@nifty.ne.jp> 中野武雄さん <nakano@apm.seikei.ac.jp> 水原文さん <mizuhara@acm.org> 森本淳さん <morimoto@xantia.citroen.org> 山森浩幸さん <h-yamamo@db3.so-net.ne.jp>