解決策 1:
Netfilter と conntrack の紹介プレゼンテーション
まず、Netfilter と一般的なネットワークのパケット フローに関する必須の図:
Netfilter は、ネットワーク スタックの残りの部分に挿入されるパケット フィルタリング フレームワークです (「ルーティング決定」およびその他の白い丸いエッジのボックス パーツによって表されます)。 Netfilter は、他のサブシステムと「クライアント」にフックと API を提供します。これらのパーツの中には conntrack があります (接続トラッカー) と iptables (または nftables )。 Netfilter と conntrack の分離 かなり曖昧です。 conntrack を検討してください Netfilter の統合部分として。
パケットが通過するさまざまなステップを説明する図では、ある時点 (raw/PREROUTING と mangle/PREROUTING の間、または raw/OUTPUT と mangle/OUTPUT の間) で、パケットが conntrack を通過することがわかります。 .
この時点で、conntrack 独自のルックアップ テーブル (カーネル メモリに保持されているミニ ルックアップ データベース) を検索します:
- このパケットの特性が見つからない場合 (および raw テーブルで UNTRACKED と宣言されていない場合)、新しい conntrack 双方向 タプル エントリ (プロトコル、次に特定のファミリおよびプロトコル情報:最初の送信元とポート、最初の宛先とポート、返信の送信元とポート、返信の送信先とポート (NAT やエコーなどの奇妙なプロトコルが含まれていない限り、これらの最後の 2 つは通常逆です) ICMP のエコー要求に一致する応答))) フローを記述し、状態 NEW で作成されます。
- 前のエントリと (任意の方向で) 一致し、このフローの状態と互換性がある場合、フローの状態は変更される可能性があります (例:以前にそうでなかった場合、NEW から ESTABLISHED に変更)。
- 何らかの特定の理由により、既存のフローに特徴があるにも関わらず、パケットが既存のフローと一致しない場合 (例:再送信が正常に開始された後に受信された遅い TCP パケットで、シーケンスと SACK に関してウィンドウから外れている場合)値) パケットは INVALID とタグ付けされます。
- RELATED のようなケースは他にもいくつかあります。これは、フロー自体の一部ではなく、他の既存の (データベース内の) フローに関連付けることができる新しいフローに関連するパケットに関するものです。 2 つの例は、パケットの受信 (例:UDP ポートに到達できません)、またはカーネル モジュール
nf_conntrack_ftp
のような特別なプロトコル ヘルパーによって作成される ICMP エラーです。 conntrack へのプラグインです。 サブシステムは、パケットがコマンド フロー (ポート 21) で実行される FTP コマンド PASV/EPSV または PORT/EPRT に関連付けられた個別のデータ フローの一部であることを検出します。
質問への対処
以上のことから、2 つの箇条書きに対する回答は次のとおりです。
-
メインのネットワーク名前空間 conntrack モジュール (関連するプロトコル固有のサブモジュールを含む) がロードされるとすぐに、接続の追跡を開始します。非初期ネットワーク名前空間 (コンテナ...) の場合、他のサブシステムがそれを参照する必要があります (OP の iptables など)。 の conntrack モジュールまたはコマンド
conntrack
を 1 回使用する 後述)。これがデフォルトであり、パケットは明確に UNTRACKED としてマークされる必要があります 前に コントラック サブシステムは、このパケットが追跡されないようにします。 Linux では、トラッキングが不要になるケースはごくわずかですが、その場合はもちろん、ステートフル ファイアウォールとステートフル/ダイナミック NAT は使用できなくなります (そもそも UNTRACKED の使用が必要になる可能性のあるステレス NAT は引き続き使用できます)。完了しましたが、iptables を使用していません . tc または nftables できる)。 conntrack を回避するには この種の iptables で、いくつかのパケットを処理します ルールを使用できます (例:ポート 80/tcp):iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack
-
パケットが filter/INPUT を通過し、このルールに到達すると:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables の特定のカーネル モジュール
xt_conntrack
conntrack をクエリします サブシステム (さまざまな関連するカーネル モジュールnf_conntrack*
によって処理されます) )、検索データベース内のこのパケットの状態について尋ねます。答えがRELATED
の場合 またはESTABLISHED
パケットが一致し、ACCEPT 判定に進みます。実際には、最初にルックアップが行われたときに、結果はすでにパケットにキャッシュされています (通常は conntrack によって) ) したがって、これは安価な「ルックアップ」です。したがって、これは以前に受け入れられたフローを処理するための一般的なルールです。これらのフローは、-m conntrack --ctstate NEW
を明示的に言及するルールで最初に受け入れることができます。 または、それについて言及せずに 後に配置した単純なルール この一般的なルール (ただし、INVALID 状態に注意してください。通常、そうする前に削除する必要があります)。 -
箇条書きの追加:着信パケットと発信パケットの処理は、PREROUTING と OUTPUT の間で非常に対称的です (対称に見えなくても):conntrack PREROUTING と OUTPUT のインターフェイス (および NAT を考慮して他のいくつかの場所) conntrack と連携しています iptables を横断する状態 NEW の最初のパケットを除く の nat テーブル)。これは、あなたが IPFW について書いた説明とは少し異なる場合があります。アプリケーションを実行しているサーバーが発信フローも制限している場合、おそらくこれと同じ汎用的な iptables が必要です。 filter/OUTPUT と filter/INPUT の両方でルールを使用して、既に受け入れられている着信トラフィックの発信応答パケットが通過できるようにします。
追加情報
conntrack を操作するための専用ツールがあります conntrack-tools からのサブシステムのルックアップ テーブル。
-
conntrack
:conntrack によって処理されるルックアップ テーブルの内容をクエリ、削除、または更新します。 .いくつかの例
追跡されたすべてのエントリ (追加のフィルタなしでは大きくなる可能性があります) を次のように一覧表示できます:
conntrack -L
システムが NAT を実行している場合 (例:プライベート LAN の前にあるルーター、または VM とコンテナーを実行している) は、
--any-nat
を使用できます。 、--src-nat
または--dst-nat
respのみを表示します。すべての NAT、すべての送信元 NAT (マスカレード)、またはすべての宛先 NAT (通常は転送ポートの場合):conntrack のリアルタイム監視 イベント:
conntrack -E
-
conntrackd
:2 つの主な目的が (conntrack) フロー アカウンティングと統計、または高可用性ステートフル ファイアウォール クラスタ状態の同期であるデーモン。
解決策 2:
接続追跡は Netfilter の別の機能であり、IPTables では構成されません。
写真では、2 つの conntrack
があります。 INPUT パスのステップと OUTPUT パスのステップ。これらの手順では、個々のパケットを接続追跡テーブルで追跡される既存の接続に関連付けるか、テーブルに新しい接続追跡エントリを作成します。
Conntrack 機能は Linux カーネル モジュールであり、多くの場合、デフォルト設定でカーネルに含まれています。
Conntrack の動作は、net.netfilter.nf_conntrack
を調整することで調整できます sysctl 値。
あなたの2番目の選択肢は何が起こるかです。状態情報は Conntrack 関数によって記録され、IPTables ルールは Conntrack テーブルで情報を参照するだけです。