
これPREROUTING
このページでは、テーブルのチェーン内に destinationを にnat
変換するルールがある場合、およびチェーン内のルールはではなく に一致する必要があることを示唆しているようです。1.2.3.4:80
10.1.1.1:8080
INPUT
FORWARD
10.1.1.1:8080
1.2.3.4:80
概説したような操作順序を実装したい場合はどうすればよいでしょうかここつまり、NAT の前にパケットの特性に基づいてフィルタリングをどのように実行するのでしょうか?
PREROUTING
1 つの可能性は、テーブルのチェーンを使用することですraw
。問題は、conntrack がraw/PREROUTING
(注 1 を参照) で使用できないことです。たとえば、非初期 UDP フラグメントは初期フラグメントと関連付けられず、予期しない一致が生成されます。
ジレンマを明確に説明できたかどうか、また回避策があるかどうかを教えてください。
注 1: 間違っていたら訂正してください。 で conntrack を使用しようとしたときraw/PREROUTING
、すべての初期 SYN パケットが " INVALID
" ではなく " NEW
" とマークされました。また、Netfilter フローチャートでは、"conntrack" は の後にあるようですraw/PREROUTING
。
答え1
ルールは必要ありませんraw/PREROUTING
。conntrack
マッチを使用して、元の (変換前の) 宛先/送信元アドレス/ポート番号でパケットをフィルタリングできます。これは、conntrack
以前のマッチの後継ですstate
。(および NAT) に関連するさまざまな追加メタデータをチェックできますconntrack entry
。
いくつか例を挙げます。
# allow any port-forwarded packets
iptables -t filter -A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
# check the original destination address of DNATed packets
iptables -t filter -A FORWARD -p tcp --dport 8080 -m conntrack --ctstate DNAT --ctorigdstport 80 --ctorigdst X.X.X.X --ctdir ORIGINAL -j ACCEPT
iptables -m conntrack --help
詳細については、およびの出力を確認してくださいman iptables-extensions
。
答え2
のNetfilter と一般的なネットワークにおけるパケットフローパケットを見るさまざまなフック間の関係を記述します。以下はその一部です:
だからもし交流したいなら堂々とパケット付き前にnat、論理的な選択はmangle/PREROUTING
:接続トラックフックはすでにパケットを追跡しています。INVALID状態は取得しませんが、ナットまだ起こっていません。
iptablesのナット最初のパケットのみを確認し、残りはすべて直接処理されます接続トラック、依然として同じ場所、つまりmangle/PREROUTING
とルーティング決定の間で発生しています。
もう一つの方法は、アントン・ダニロフの答え: クエリによって接続トラックルックアップテーブルから以前のアドレスを確認します。