主な答え:
Conntrack state に取って代わります 、しかし、最近のカーネルでは、2 つの間に違いはありません。State は現在エイリアス化され、conntrack に変換されています カーネルにある場合は iptables で、構文 -m state --state 実際には -m conntrack --ctstate に変換されます 同じモジュールによって処理されます。
ただし、一部の古いカーネルでは、contrack を明確に有効にする必要があります。
考えられる説明:
あなたが引用したルールには、古いカーネルと新しいカーネルの両方に対応する重複が含まれているように思えます.
あるいは、これは Cargo カルト プログラミングの単なるケースかもしれません。
2012 年からの ServerFault に関するこの質問があります:
<ブロック引用>実際の違いは何ですか:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
そして
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
どちらを使用するのが最適ですか?
受け入れられた答えは次のとおりです:
<ブロック引用>どちらも同じカーネル内部構造 (接続追跡サブシステム) を使用します。
xt_conntrack.c のヘッダー :
xt_conntrack - Netfilter module to match connection tracking
information. (Superset of Rusty's minimalistic state match.)
だから私は言います-状態モジュールはより単純です（そしておそらくエラーが発生しにくいでしょう）。カーネルでも長いです。反対側の Conntrack には、より多くのオプションと機能があります[1]。
私の呼び出しは conntrack を使用することです その機能が必要な場合は、それ以外の場合は状態モジュールを使用してください。
netfiltermaillist に関する同様の質問。
[1] -m conntrack --ctstate DNAT -j MASQUERADE"
routing/DNAT fixup のようにかなり便利;-)
他の回答の1つは、iptablesに関するこのドキュメントにつながります .それは言う：
conntrack match は state の拡張バージョンです これにより、パケットをより細かく照合することができます。 state などの「フロントエンド」システムを使用せずに、接続追跡システムで直接利用できる情報を確認できます。
だから私はこれが本当だと思います（さらに別の答えから）：
<ブロック引用>これら 2 つのルールの結果に違いはありません。
質問の下にも興味深いコメントがあることに注意してください:
<ブロック引用>
state conntrack を支持して非推奨です 、カーネルの構築方法に応じて、コンパイルされる場合とされない場合があります。