iptables に REDIRECT ルールを追加した後、tcpdump が異なるリダイレクトポートを表示する

Question

明確に言うと、OP のテストはリモートシステムからではなく、システム 192.168.1.100 からそれ自体に対して実行されており、これが問題の原因です。この場合、NAT ルールが一致しなかったためポートは変更されませんでしたが、リモートシステムから実行した場合は一致したはずです。

以下の図は、パケットに対して実行される操作の順序を示しています。

その理由は、Linux 上で NAT がどのように動作するかにあります。iptablesnat新しい conntrack フローの最初のパケット (したがって NEW 状態) についてのみ、テーブル内のパケットを確認します。

このルールはリモートシステムからの場合は正常に機能します。この場合、最初に確認されるパケットは着信パケットになります。

to port 8000 --> AF_PACKET (tcpdump) --> conntrack --> nat/PREROUTING (iptables REDIRECT): to port 30000
--> routing decision --> ... --> local process receiving on port 30000

同じフロー内の後続のすべてのパケットでは、conntrack がポート変更 (または応答のポートの復帰) を直接処理し、テーブル内の iptables ルールをスキップしますnat(図に書かれているように、natテーブルは接続に対してのみ参照されますNEW)。したがって、(応答パケット部分をスキップして) 次の着信パケットは代わりに次の処理を受けます。

to port 8000 --> AF_PACKET (tcpdump) --> conntrack: to port 30000
--> routing decision --> ... --> local process receiving on port 30000

システム自体のテストの場合、最初のパケットは着信パケットではなく発信パケットです。代わりに、発信loインターフェイスを使用して次の処理が行われます。

local process client curl --> routing decision --> conntrack --> nat/OUTPUT (no rule here)
--> reroute check --> AF_PACKET (tcpdump) --> to port 8000

そして、このパケットはloインターフェース上でループバックされ、接続の最初のパケットではなくなったパケットとして再び表示されるため、上記の 2 番目のケースに従います。つまり、conntrack のみが NAT を処理し、呼び出しませんnat/PREROUTING。ただし、前の手順で NAT を実行するように指示されていません。

to port 8000 --> AF_PACKET (tcpdump) --> conntrack
--> routing decision --> ... -->nolocal process receiving on port8000

ポート 8000 でリッスンしているものが何もないため、OS は TCP RST を返します。

これをローカルシステムで機能させるには、チェーンREDIRECTにルールも追加する必要がありますnat/OUTPUT。

iptables -t nat -I OUTPUT -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --to-port 30000

その他の注意事項

ケースがリモート使用を目的としている場合は、ローカルシステムからテストしないでください。テストによって走査されるルールは同じではありません。これにより、テストが現実を反映しなくなります。

nat/PREROUTING他のシステムが利用できない場合に備えて、ネットワーク名前空間を使用してポケットリモートシステムを作成します。これは、OP のルールのみを持ち、次の操作を実行するシステムで動作するはずですcurl http://192.168.1.100/(DNS は必要ありません)。
```
ip netns add remotesystem
ip link add name vethremote up type veth peer netns remotesystem name eth0
ip address add 192.0.2.1/24 dev vethremote
ip -n remotesystem address add 192.0.2.2/24 dev eth0
ip -n remotesystem link set eth0 up
ip -n remotesystem route add 192.168.1.100 via 192.0.2.1
ip netns exec remotesystem curl http://192.168.1.100:8000/
```
tcpdumpおよびNAT

tcpdumpAF_PACKETこれは、上記の図のステップで発生します。入力の場合は非常に早い段階で、出力の場合は非常に遅い段階で発生します。つまり、リモートシステムの場合は、動作している場合でもポート 30000 をキャプチャすることはありません。ローカルシステムの場合は、nat/OUTPUTルールが追加されると、ポート 30000 をキャプチャします。

NAT を実行するときに表示されるアドレス/ポートを盲目的に信頼しないでくださいtcpdump。これは、ケースとキャプチャが発生する場所によって異なります。

Answer 1