Linuxの新しいパケットフィルタリング機構「NFTables」 16
ストーリー by hylom
苦労して覚えたiptablesの知識は…… 部門より
苦労して覚えたiptablesの知識は…… 部門より
あるAnonymous Coward 曰く、
Linuxカーネル3.13には、新たなパケットフィルタリング機構「NFTables」がマージされる模様（本家/.）。
NFTablesはsiptablesを置き換えるべく開発されたもので、よりパワフルかつシンプル、改良されたエラーリポート、効率的なパケットフィルタリングルールのハンドリングなどが特徴だという。NFtablesのコードはすでに公開されているので、既存カーネルでもカーネル/カーネルモジュールをコンパイルすれば利用可能になるようだ。
フィルタリング設定や設定確認にはnftコマンドを使用し、たとえば80番ポートへのパケットをdropするには「nft add rule ip filter input tcp dport 80 drop」などとコマンドを実行すればよいとのこと（解説記事）。
siptablesを置き換えるべく開発されたもの (スコア:2, 興味深い)
それはきっとiptablesじゃないかな。
Re: (スコア:0)
おれもそんなんあったっけ？と思ってぐぐっちゃったよ。
同名のサーバソフトウェアがあるらしいので修正しておいてくれると助かるが、さて。
どんどん変わって行くのがLinuxらしさなんだろうか (スコア:1)
Linuxカーネルではないけど、以前、Linuxでネットワークを手動設定するとき、net-toolsのifconfig(8)を使っていた。
マスク部の指定が面倒だったりして(今は改善されてるかも)、iproute2のip(8)に乗り換えた。
引数の指定が色々違って、慣れるのに手間取ったはずだ。
良く言えば活気があるが、開発の大半は昔のまずいコードの書き直し、まずいコマンドの再実装だったりしてそう。
*BSDはifconfig で/25 とか普通にできたし、同じコマンドが高機能化され続けている。
# うーん、言いたいことがはっきりするまで考える気がないので、ここでsubmit(俺やっぱりLinux'erだ)
微妙すぎる… (スコア:1)
疑問点: 1
可読性が落ちているように感じるのだが、誰も指摘しなかったのか？
例えばiptablesで-j CTする場合、iptables -t raw -A PREROUTING -m conntrack --ctstate ESTABLISHED -j CTみたいな感じになるだろう。
一方でntfでは、nft add rule raw prerouting ct state established ctになるのかな？
この時点でも十分読みにくいけど、これで-j CTの後ろに--helperなんてついて伸びていった日にはもう…
nftの方が単なる英単語の羅列のようになってしまって、明らかに可読性が落ちているんだよね。
-j CT程度ですらご覧の有様、もしこれがパラメータの多いhashlimitなんて使った日には、パッと見ではもう何が何だかわからないだろう。
だいたいからして、iptablesでtimeモジュールとhashlimitモジュール、それにconntrackモジュールとmultiportモジュールを同時に使うルールなんてのも珍しくもない。
それにiptablesのように-m conntrack --ctstate ESTABLISHED,RELATEDと繋げずに、estanblishedとrelatedを別々に記述してるのも気になる。
まさかiptablesで言うところのモジュールはひとつしか使えないとか？
しかもstateマッチみたいな定義も一行に列挙できないとか？
まさかねぇ。
疑問点: 2
nftでlogした時に、ログが投げられる先は何処？
iptablesであれば、-j LOGならばsyslogだし、-j ULOGや-j NFLOGならばulogdに投げられる。
それではnftでlogした時には、ログは一体何処に投げられるの？
うちでは特定のパケットをマークして統計取ったりする関係上、全て-j NFLOGで、しかもoutput_MYSQLでMariaDBに丸投げしてるけどさ。
ぶっちゃけた話、-t raw -A PREROUTING -m rpfilter --invert 的なことが起きるくらいでないとログなんて要らね。って人も多いのでは？
そんなわけで「ログも少ないから-j LOGのみで十分」って人も結構居るんじゃないのかな。
つまりnftablesの名前から察するようにデフォルトがNFLOGだと、全ての人がNFLOGとulogdの組み合わせを使うことになるけど、それは明らかにオーバースペックでしょ？
ulogdは、公式のulogd2のgitリポジトリ見てもわかる通り、ドキュメントからしてかなり古いままで更新停止してるしね。
どれがInput pluginで、どれがInterpreter pluginで、どれがOutput pluginなのか？ とか、plugins stacksの順番や定義の書き方なんて、ドキュメントがそんな状態だからソース読めなきゃ書けないでしょ？
ulogd強制したら、素人さん達がulogd.conf書けなくて阿鼻叫喚の地獄絵図になるのは目に見えてる。
だからといってnftablesなのに、デフォルトがNFLOGじゃないってのもってのもねぇ…
そもそもnftablesっていうネーミングからして失敗なんだよな、カーネルから取ってxt_tablesとかにしておけば良かったんだよ。
疑問点: 3
ユーザー定義チェインは？
table filter {
chain input {
table filter hook input priority 0;
ct state established accept
ct state related accept
…
という例文があるから、同じような感じで定義できそうなのはわかる。
しかし次のtable filter hook input priority 0;の一文が気になる。
まさかと思うが、Netlinkの段数分しか定義できないとかいうことじゃないだろうな？
ましてNFLOGがデフォルトだったとして、NFLOGで使う分と合わせて。ということだったりしたら最悪。
# なんかもう色々と微妙すぎてテストする気も起こらない…
Re:微妙すぎる… (スコア:1)
よく想像だけでそんなに書けるねえ。すごい。
# 可読性落ちてるんじゃなくて慣れてないだけじゃね
Re: (スコア:0)
元々iptablesだって読みにくい書きにくいって点では問題ありでしょ。
というわけで、iptablesのコマンド群を生成するスクリプトなり何なり作ったヤツはたくさんいる筈だ。いたら手を挙げろ！
宛部門名 (スコア:0)
本家曰く
>(though it now offers an iptables compatibility layer too)
だそうな。
Re: (スコア:0)
新規インストールするたびにどこかのやり方が根本的に変わってしまっていて、
毎回何か基本的なことを勉強させられるイメージが。
ipchains - iptables - NFTables (スコア:0)
設定の面倒さは変わってない気が、、、
Re:ipchains - iptables - NFTables (スコア:3, 参考になる)
これによってカーネルのコードが綺麗になって、実行効率が良くなって、エラー表示とかもわかりやすくなるというものです。
専用コマンドも準備されてるけど、今までのコマンド互換インターフェイスでいけるので同じと思ってもよし。
これが役に立つのは
- カーネルのソースコードを読み書きする人
- iptables に山ほどフィルターを既述して実行が遅くなって困った人
- iptables や ebtables の謎のエラーメッセージに悩まされてる人
とかかな？
普通のディストリビューションで使えるようになるのは少し先でしょうね。
ルーティング制御 (スコア:0)
NETMARKとiproute2とnetfilter/iptablesを連携させて複雑なルーティング制御をしてたんだけど
iptablesからNFTablesに変わっても大丈夫なのかな？
netfilterのフロントエンドであるiptablesがNFTablesに変わるだけで
iptablesで出来る全ての事は、間違いなくNFTablesで出来るのかな？
どちらにせよ (スコア:0)
テンプレをコピペするので職人よろしく
Re: (スコア:0)
合法ロリ上司にパワハラされるぞ
似てるだけで互換じゃないんでは? (スコア:0)
chainとかtableとかの概念も使えないと互換でなく、コマンド構文が似てますくらいだよね?
Re: (スコア:0)
Nftables quick howto [regit.org]
似てるとは言い難いな
難読って点においては似たり寄ったりだけど
結局firewalld経由で使うから関係ない (スコア:0)
ユーザーにはカーネルレベルでの実装は隠蔽される、といいなあ