7.8. 追跡除外コネクションとrawテーブル

Linux のコネクション追跡における UNTRACKED はかなり特殊なキーワードだ。ごく平たく言えば、 raw テーブルで追跡を除外するようマークされたパケットを、選別するためのものだ。

まさにこの目的のために作られたのが raw テーブルであり、そこでは、netfilter で追跡してほしくないパケットに対して NOTRACK マークを付けることができる。

僕が コネクション ではなく パケット と言っていることにお気づきだろうか。ここで言うマークは、進入してきた各パケットに対して付けられるのだ。もしそうでなかったら、追跡すべきでないパケットかどうかを知るために何らかの追跡が必要、というおかしなことになってしまう。

既に当チャプターで述べてきたように、 conntrack およびステート機構はかなりのリソース食いだ。そのため、コネクション追跡とステート機構が働かないようにしたほうがいい時もある。

ひとつの例が、大量のトラフィックを扱うルータで、ルータ自体への入出トラフィックはファイヤウォールしたいが、他へルーティングするトラフィックはファイヤーウォールしたくない場合だ。この時、 raw テーブルで自分宛のパケットは ACCEPT し、それ以外にはすべて NOTRACK マークを付ければいい。そうすれば、ルータ自身へのトラフィックに対してはステートフルマッチが行え、なお且つ、中継するだけのトラフィックに対する CPU パワーがセーブできるのだ。

NOTRACK が活用できる別の例としては、トラフィックの多い Web サーバで、ステートフルな追跡はしたいが Web トラフィック自体の追跡には CPU パワーを消費したくない場合がある。この時には、ローカルな IPアドレスおよび Webサービスを提供している IPアドレスそのもののポート 80 に対しては追跡をオフにすればよい。その結果、既に明らかにオーバーロード状態になっている Web トラフィックに関してはプロセッシングパワーを節約しながら、それ以外のサービスに対しては依然としてステートフルな追跡が行える。

ただし、 NOTRACK には留意しておかなくてはならない問題点もある。コネクションが NOTRACK されるということは、RELATED なコネクションが察知できないということでもあり、conntrack や nat ヘルパーは軒並み機能しなくなるし、関連のある (related) ICMP エラーも拾えなくなるのだ。つまり、そうしたパケットに対しては個別的に門を開いてやらなければならない。特に FTP や SCTP などといった複雑なプロトコルとなると、手動で面倒を見るのは難行だ。だが、このことに注意しておけば、 NOTRACK を操ることは難しくはない。