第 1 部分：一般解释，如果您已阅读问题，则无需阅读。
第一个（数据包如何到达攻击者）：
受害者将源 IP 为“192.168.1.3”和源 MAC 为“00:00:00:00:00:03”的数据包发送到目标 IP“DEST”和目标 MAC“00:00:00:00:00:01” . 其中“DEST”是一些外部 IP，如“47.32.1.6”路由器接收数据包，因为 MAC 指向我（作为攻击者），它会将数据包转发到我的接口。
受害者将源 IP 为“192.168.1.3”和源 MAC 为“00:00:00:00:00:03”的数据包发送到目标 IP“47.32.1.6”。受害者找不到到这个地址的直接路由（因为它不在他的子网中），所以它通过默认路由将数据包发送到“192.168.1.1”（即到默认网关，在这种情况下为路由器）。然而，由于我们在以太网上，受害者需要一个 MAC 地址来发送数据包。您提到路由器的 MAC 地址为“00:00:00:00:00:00”，但攻击者已经毒化了受害者的 ARP 表。而不是条目
192.168.1.1 00:00:00:00:00:00
受害者的 ARP 表中有以下条目：
192.168.1.1 00:00:00:00:00:01
（您可以通过在受害者的 PC 上打开命令行并在启动 Ettercap 之前和之后运行命令“arp -a”来检查这一点）。
这意味着，每当受害者尝试向路由器或外部网络发送数据包时，该数据包都会到达攻击者，直到您“重新 ARP”受害者。
第二个（数据包如何到达其真实目的地）：
现在 Ettercap 获取数据包并将源 IP 识别为受害者的 IP（即“192.168.1.3”），将目标 IP 识别为路由器（第二个受害者），然后发送此数据包以将数据包转发到真实主机并允许流式传输：
在中毒开始之前，攻击者确保他的 ARP 表包含正确的条目，如下所示：
192.168.1.1 00:00:00:00:00:00 (the router)
192.168.1.3 00:00:00:00:00:02 (the victim)
现在，在第一部分，我们停在外部数据包到达攻击者 PC 的位置，但当然，我们需要确保数据包到达其“真实”目的地。否则，受害者永远不会得到真正的回应，因此会很快注意到有什么不对劲。因此，攻击者希望将数据包转发到其真正的目的地：默认网关（路由器）。这是可能的，因为攻击者知道路由器的真实 MAC 地址。它实际上从受害者那里收到以下数据包：
源 IP：192.168.1.3
源 MAC：00:00:00:00:00:03
目标 IP：47.32.1.6
目标 MAC：00:00:00:00:00:01
目标 IP 被转换为攻击者的MAC地址，是因为受害者会在其路由表中查找目标IP（路由打印），发现它应该将此数据包发送到默认网关。因此它发出一个 ARP 请求（或查看他的 ARP 表，arp -a），并注意到数据包应该发送到的 MAC 地址是 '00:00:00:00:00:01'
这里重要的是攻击者看到这是一个实际上不是给他的数据包。本来是为他准备的数据包看起来像这样：
源 IP：192.168.1.3
源 MAC：00:00:00:00:00:03
目标 IP：192.168.1.2
目标 MAC：00:00:00:00:00:01
因此，每当攻击者接收到一个数据包时，他都会检查源 IP 和目标 IP，并使用他未中毒的 ARP 表将其转发，在本例中为“00:00:00:00:00:00”（路由器）。
第 2 部分：所提问题的摘要
起初，这个问题对我来说并不完全清楚。然而，在 CS 在聊天中更仔细地解释之后，问题归结为：在一个设置中，Ettercap 处于活动状态，并且在端口 8080 上侦听的自定义应用程序正在主动转发流量（到受害者），并且端口转发主动将来自端口 80 的流量重定向到端口 8080（自定义应用程序），为什么这些数据包（最初用于端口 80 的数据包）只到达受害者一次？
有人可能会认为会发生以下情况： - 数据包从端口 80 进入，实际上是为受害者准备的，但由于 ARP 中毒攻击而被重定向到攻击者 - Iptables 将此数据包重定向到端口 8080 - Ettercap 将数据包转发给受害者- 为转发数据包而明确构建的自定义应用程序也将数据包转发给受害者
但是，受害者只收到一次数据包。为什么？
第 3 部分：最终答案
Ettercap 只会转发具有以下特征的流量：
- 数据包的dest mac地址与攻击者的mac地址相同
- dest ip与攻击者的ip地址不同
现在，问题是，通过使用 iptables REDIRECT 命令，会发生以下情况：
- 目标端口已更改（在此特定情况下从 80 更改为 8080）
- 目标 IP 更改为运行 iptables 的设备的主 IP 地址。
- 因为这是一个 PREROUTING 规则，以上发生在数据包到达 Ettercap 之前
正是“目标 IP 更改”回答了为什么数据包没有被转发两次的问题。想象以下来自受害者的用于外部 Web 服务器的数据包：
源 IP：192.168.1.3
源 MAC：00:00:00:00:00:03
目标 IP：47.32.1.6
:80
目标 MAC：00:00:00:00:00:01
如果这个数据包到达 Ettercap，那么转发条件就已经满足：数据包的目的 MAC 是攻击者的 MAC，但目的 IP 不是。
现在，这个数据包没有以那种形式到达，iptables REDIRECT 命令将其转换为以下形式：
源 IP：192.168.1.3
源 MAC：00:00:00:00:00:03
目标 IP：192.168.1.2
:8080
目标 MAC：00:00:00:00:00:01
这样做是因为 192.168.1.2 是执行重定向命令的设备的主 IP 地址。因此，这个数据包将被 Ettercap 忽略。
第 4 部分：最终见解
现在，如果您启用 SSL 解析，上述情况实际上是相同的。要启用 SSL 剖析，需要在 etter.conf 中取消注释以下行：
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
您可能会注意到，这与问题中提到的 iptables 命令几乎完全相同。因此，同样适用：ettercap 不会转发从端口 443 传入的数据包。发生的情况如下：
- 来自受害者的流量进来，应该是去 https 服务器
- 因为是被iptables重定向的，所以ettercap不会再转发了（因为目的IP变了）。这意味着所有 SSL 流量都停留在攻击者的电脑上。
- 然后，Ettercap 创建了一个带有假证书的假服务器。它开始与真正的 ssl 服务器通信以提供 HTML/JS，但客户端直接与 ettercap 对话。不再转发数据包。
这与问题中解释的情况相同，除了 SSL 解析器不转发流量，而 TS 创建的应用程序仍然转发。