主页 / server / 问题 / 1097421
Accepted
tiger_groove
Asked: 2022-03-31 12:52:17 +0800 CST

在 iptables 中添加 REDIRECT 规则后，Tcpdump 显示不同的重定向端口

  • 772

我正在尝试将客户端流量定向到正在侦听的 kubernetes 集群 NodePort 192.168.1.100.30000。

客户需要发出请求，192.168.1.100.8000所以我在 iptables 中添加了以下 REDIRECT 规则：

iptables -t nat -I PREROUTING -p tcp --dst 192.168.1.100 --dport 8000 -j REDIRECT --to-port 30000

然后我发出一个 curl，192.168.1.100:8000但是，在 tcpdump 中我看到了一个不同的端口：

# tcpdump -i lo -nnvvv host 192.168.1.100 and port 8000
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
[Interface: lo] 20:39:22.685968 IP (tos 0x0, ttl 64, id 20590, offset 0, flags [DF], proto TCP (6), length 40)
[Interface: lo]     192.168.1.100.8000 > 192.168.1.100.49816: Flags [R.], cksum 0xacda (correct), seq 0, ack 3840205844, win 0, length 0
[Interface: lo] 20:39:37.519256 IP (tos 0x0, ttl 64, id 34221, offset 0, flags [DF], proto TCP (6), length 40)

我希望 tcpdump 显示类似

192.168.1.100.8000 > 192.168.1.100.30000

但是，它显示并导致连接被拒绝错误，因为没有进程列在192.168.1.100.49816.

192.168.1.100.8000 > 192.168.1.100.49816

我正在使用测试环境，所以我无法访问远程设备，这就是我curl用来测试 iptables REDIRECT 路径的原因。

添加 REDIRECT 规则是否会导致 tcpdump 将流量重定向到指定端口以外的其他端口？

编辑：

在@AB 建议后添加了以下 OUTPUT 规则：

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

并且 curl 确实继续进行，OUTPUT 链的数据包计数确实增加了（虽然 PREROUTING REDIRECT 链数据包没有增加）：

2       10   600 REDIRECT   tcp  --  *      *       0.0.0.0/0            192.168.1.100         tcp dpt:8000 redir ports 30000

但是，收到以下错误：

# curl -vk https://192.168.1.100:8000/v1/api
* About to connect() to 192.168.1.100 port 8000 (#0)
*   Trying 192.168.1.100...
* Connected to 192.168.1.100 (192.168.1.100) port 8000 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* NSS error -12263 (SSL_ERROR_RX_RECORD_TOO_LONG)
* SSL received a record that exceeded the maximum permissible length.
* Closing connection 0
curl: (35) SSL received a record that exceeded the maximum permissible length.

另外，尝试添加一个远程系统网络，这次 PREROUTING REDIRECT CHAIN 数据包计数在执行后增加remotesystem curl ...（但 OUTPUT CHAIN 不增加）：

2       34  2040 REDIRECT   tcp  --  *      *       0.0.0.0/0            172.16.128.1         tcp dpt:8000 redir ports 30000

错误：

# ip netns exec remotesystem curl -vk https://192.168.1.100:8000/v1/api
* About to connect() to 192.168.1.100 port 8000 (#0)
*   Trying 192.168.1.100...
* Connection timed out
* Failed connect to 192.168.1.100:8000; Connection timed out
* Closing connection 0
curl: (7) Failed connect to 192.168.1.100:8000; Connection timed out
tcpdump iptables

1 个回答

  1. Best Answer

    需要说明的是：OP 的测试是从系统 192.168.1.100 到它自己完成的，而不是从远程系统完成的，这就是问题的原因。在这种情况下，端口没有更改，因为没有匹配的 NAT 规则，而如果从远程系统完成，它会匹配。

    下面的示意图显示了如何对数据包执行操作顺序：

    Netfilter 和通用网络中的数据包流

    原因是 NAT 在 Linux 上的工作方式：iptables仅在表中看到nat新 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 处理端口更改（或回复的端口反转），并将跳过nat表中的任何 iptables 规则（如示意图中所述：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，它重新出现为一个不再是连接中的第一个数据包的数据包，因此遵循上面的第二种情况：单独的 conntrack 负责 NAT 并且不调用nat/PREROUTING. 除非在之前的步骤中没有指示进行任何 NAT：

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

    由于端口 8000 上没有任何监听，操作系统会发回 TCP RST。

    为了在本地系统上工作，REDIRECT还必须在nat/OUTPUT链中放入一条规则：

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

    补充说明

    • 如果该案例用于远程使用，请不要从本地系统进行测试：测试遍历的规则不一样。这使得测试无法反映现实。

      只需使用网络命名空间来创建一个袖珍远程系统，以防没有其他系统可用。应该与仅具有 OPnat/PREROUTING规则并执行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

      tcpdump发生在AF_PACKET上面示意图中的步骤：入口非常早，出口非常晚。这意味着对于远程系统案例，即使它正在工作，它也永远不会捕获端口 30000。对于本地系统情况，一旦nat/OUTPUT添加规则，它将捕获端口 30000。

      只是不要盲目相信tcpdump在进行 NAT 时显示的地址/端口：这取决于情况和捕获发生的位置。

    • 4

相关问题