このiptablesスニペットを別のスーパーユーザーの回答で見ました。
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ポイントは、確立された接続の一部として送信されるパケットを常に許可することです。私が疑問に思っているのは、上の2行です。
INPUT
チェーンの場合、両方を書く意味は何ですか-m conntrack --ctstate RELATED,ESTABLISHED
および-m state --state RELATED,ESTABLISHED
。両方とも同じことをする必要があるようです?
これら2つの違いの説明はすばらしいでしょう。
主な答え:
Conntrack
はstate
に取って代わるものですが、最近のカーネルでは、この2つの間に違いはありません。カーネルにState
は現在エイリアスがあり、iptablesでconntrack
に変換されているため、構文-m state --state
は実際には-m conntrack --ctstate
に変換され、同じモジュールで処理されます。
ただし、一部の古いカーネルでは、contrackを具体的に有効にする必要があります。
可能な説明:
あなたが引用したルールには重複が含まれているかのようで、古いカーネルと新しいカーネルの両方に対応しています。
または、これは 貨物カルトプログラミング の場合にすぎません。
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
を使用し、それ以外の場合は状態モジュールを使用することです。[1]
-m conntrack --ctstate DNAT -j MASQUERADE" routing/DNAT fixup
のようにかなり便利です;-)
他の答えの1つがこれにつながります iptables
に関するドキュメント 。それは言う:
conntrack
一致はstate
一致の拡張バージョンであり、これにより、より詳細な方法でパケットを一致させることができます。state
一致などの「フロントエンド」システムなしで、接続追跡システムで直接利用できる情報を確認できます。
だから私はこれが真実だと思います(そこにさらに別の答えから):
これら2つのルールの結果に違いはありません。
質問の下に興味深いコメントもあることに注意してください:
state
はconntrack
のために廃止され、カーネルの構築方法に応じてコンパイルされる場合とされない場合があります。