☰

Conntrack と動的 ipset/iptables ルール

tag-icon • tag-icon networking iptables ipset ip-conntrack
Conntrack と動的 ipset/iptables ルール

conntrack モジュールの基本的な概念が理解できません。

まず、私のシステム (Ubuntu 18.04) では有効になっていることを確認し、modinfonf_conntrack に関する情報を表示し、/proc/modulesファイルには nf_conntrack が「ライブ」であることが示されています。

次に、次のテスト設定を行います。

マシン A (192.168.1.2) <-----> ルーター マシン (192.168.1.1 および 192.168.2.1) <----> マシン B (192.168.2.2)

ルーターマシンには次の iptables ルールがあります。
iptables -t filter -A FORWARD -m set --match-set BlackListPort dst -j DROP

BlackListPort は ipset テーブルです。
ここで、マシン A (1.2) からマシン B (2.2) への SSH 接続を確立します。動作を確認した後、ポート 22 (SSH のデフォルト) を BlackListPort テーブルに追加します。

その ipset テーブルからポート 22 を削除するまで、SSH 接続はフリーズ/ハングします。

さて、問題は: 私のシステムには conntrack が存在するのに、なぜ SSH ブロックが成功するのでしょうか? SSH 接続はポート 22 が ipset に追加される前に確立されたため、conntrack はすべてのパケットをスキップして SSH が機能するようにする必要があります。

答え1

ポート 22 が ipset に追加される前に SSH 接続が確立されたため、conntrack はすべてのパケットをスキップして SSH が機能するようにする必要があります。

これは正しくありません。

追跡対象の接続に属しているかどうかに関係なく、すべてのパケットはフィルター ルールを通じて処理されます。

関連するルール チェーンの先頭近くに次のようなものを配置することは、iptables ルールの非常に一般的な最適化です (FORWARDこの例では):

iptables -t filter -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

古いディストリビューションでは、代わりに次のバージョンが表示される場合があります。

iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

( conntrackmatch が match よりも優先されるようになったのは理解していますstate。カーネルのバージョンによっては、この点についてうるさく言われることもあると思います。)

これにより、既存の接続に属するパケット（接続追跡情報が存在する場合）が通過できるようになります。しかし、重要なのは、あなた制御できる正確にはどこでそのルールを設定するか、まったく使用するかを決定します。したがって、ファイアウォール ルールで接続状態を必要に応じて考慮するように設定できます (または考慮しないように設定できます)。

関連情報