Linuxカーネルは動きの速いプロジェクトですが、いくつかの変更の進捗はまだ驚くほど遅いことがあります。カーネル・データを置き換える 2008年に始まりましたが、本番システムのほとんどのファイアウォール・シナリオではまだ使用されていません。しかし、8月19日に リリースされたことで注目されたように、この変化は近づいているかもしれません。
、2009 年初めに Patrick McHardy によってリリースされました。当時、カーネルには iptables という形で同様の機能を持つパケットフィルタリングサブシステムがありましたが、広く使用されている一方で、変更を提案するきっかけとなった多くの問題がありました。IPv4用、IPv6用、ARP用などです。これらの各サブシステムは基本的に完全に分離されており、重複するコードがたくさんあります。その上、iptablesはプロトコルに関連する情報を過剰に内蔵しており、APIが使いにくいので、ルールセット全体を置き換えることなくルールの1つを更新するのは困難です。
nftablesの中核となるアイデアは、これらのメカニズムをすべて捨てて、ユーザー空間から開発・設定できるシンプルな仮想マシンに置き換えることです。管理者はまだ特定のパケットヘッダーフィールドなどを含むルールを書くことができますが、ユーザー空間のツールはそれらのルールをより低レベルなフェッチと比較の操作に変換し、その結果をカーネルにロードします。これにより、パケットフィルタリングエンジンはより小さく、より柔軟になり、おそらく性能も向上するでしょう。全体として、多くのユーザーが移行できるようになれば、それは有益なことでしょう。
nftablesは立ち上げ当初はちょっとした波紋を呼びましたが、その後苦境に陥り、脚光を浴びることはありませんでした。しかし、2013年にPablo Neira Ayusoが、コードをできるだけ早くメインラインに取り込むというアイデアでプロジェクトを nftables、これに成功し、2014年の初めにnftablesが3.13カーネルに入りました。
それ以来、nftables がユーザにとって移行したくなるような魅力的なものになるよう、不足している機能を補う努力が続けられてきました。フィルタリングルールを記述する言語は、アドレスマッピング、効率的な処理、大規模なルールチェーン、多数のプロトコルのサポートなど、多くの機能を備えています。もちろん、ドキュメントも含まれており、nftables 1.0.0、その仕組みに関する多くの情報が掲載されています。
もちろん、すべての人が iptables から移行するには、1 つの大きな障害があります。多くの場合、複雑なフィルタリング設定の多くは新しいスキームでより効果的に表現できるため、ファイアウォールルールを書き換えることが最善の策かもしれません。nftables の開発者は、iptables ファイアウォールを nftables の記述に変換するスクリプトを開発しており、これは助けになるはずですが、それでも移行は大きな変化です。変更です。
nftablesは、しばらくの間Linuxディストリビューションでサポートされており、利用できるようにするための取り組みが進められています。この場合、ユーザはそもそもiptablesのルールに触れていない可能性があるので、運が良ければ、根本的なメカニズムが変わったことに全く気づかないでしょう。
この変化はいつ起こるのでしょうか？、iptablesは「時代遅れのツール」であり、その時代は終わりつつあると宣言されました。2019年のDebian 10の「buster」リリースでは、nftablesへの切り替えがデフォルトとなっていますが、Ubuntuはバージョン21.04まで追従しませんでした。2019年のDebian 10の「バスター」リリースはnftablesに切り替わり、Ubuntuはバージョン21.04まで追従しませんでした。ほぼすべてのディストリビューションにnftablesが同梱されていますが、多くのディストリビューションはデフォルトでは使用していません。
nftables 1.0.0のリリースは、挫折した人たちが移行についてもっと真剣に考える時期が来たという兆候と見ることができます。iptables のサポートがすぐに削除されることはないでしょうが、iptables の保守に対する熱意が衰え続けることは十分に予測できます。nftables に新機能が登場し、ユーザは最終的にそれを利用するために移行する必要があります。 わずか 13年ですが、この移行はようやく終わりを迎えようとしているようです。
しかし、もう1つ興味深い問題があります。2018年にBPFの開発者は、BPF VM上で動作するパケットフィルタリングメカニズムであるしましたが、当時は眉唾ものでした。bpfは過去に大きな勢いを得ており、VMを最適化し、安全に動作させるために多くの作業を行いました。論理的な戦略としては、パケットフィルタリング作業だけに特化した別のVMを維持するよりも、bpfを使用することでしょう。そうすることで、コードの束を取り除き、BPFにメンテナンスを集中させることができます。
bpfilterコードは含まれ、新しいスキームへのファイアウォールルールの変更を容易にするために設計された「ユーザーモードblobs」メカニズムをもたらしました。しかし、このコードの開発はそれ以来停止しています。2021年、net/bpfilterコードは2回だけ修正されました。コードは削除されませんでしたが、その時点では存続していました。それ以来、埃をかぶった蜘蛛の巣は厚くなるばかりで、bpfilterは現在活発な開発分野ではないと言うのが妥当なようで、nftablesをすぐに置き換えることはなさそうです。
この判断が "正しい "かどうかはわかりません。もしかしたら、nftablesで使われている特殊化された仮想マシンの方が、汎用のBPFよりもこの特殊なドメインの問題に対するより良い解決策なのかもしれません。あるいは、単にnftablesの背後にいる開発者たちが活動を続け、プロジェクトを前進させているという理由で、nftablesが勝ったのかもしれません。カーネル開発を成功させる鍵の1つは、単純に継続性です。これはパケットフィルタリングのようなクリティカルなサブシステムには特に当てはまり、開発者が長期にわたって参加していることを知ることは非常に心強いことです。
