为了了解 TCP 的工作原理，我尝试伪造自己的 TCP SYN/SYN-ACK/ACK（基于教程：http ://www.thice.nl/creating-ack-get-packets-with-scapy/ ）。
问题是每当我的计算机从服务器接收到 SYN-ACK 时，它都会生成一个 RST 数据包来停止连接过程。
我在 OS X Lion 和 Ubuntu 10.10 Maverick Meerkat 上试过，都重置了连接。我发现了这个： http: //lkml.indiana.edu/hypermail/linux/net/0404.2/0021.html，不知道是不是这个原因。
有谁可以告诉我可能是什么原因？以及如何避免这个问题？
谢谢你。
你引用的文章很清楚地说明了这一点......
由于您没有完成完整的 TCP 握手，您的操作系统可能会尝试控制并开始发送 RST（重置）数据包，为了避免这种情况，我们可以使用 iptables：
iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.20 -j DROP
本质上，问题是scapy在用户空间运行，linux内核会先收到SYN-ACK。在您有机会对scapy.
解决方案（如博客所述）是阻止内核发送 RST 数据包。
我没有非 iptables 的答案，但可以解决重置问题。与其尝试过滤过滤表中的传出重置，不如过滤原始表中来自目标的所有传入数据包。这可以防止来自目标的返回数据包被内核处理，尽管 scapy 仍然可以看到它们。我使用了以下语法：
iptables -t raw -A PREROUTING -p tcp --dport <source port I use for scapy traffic> -j DROP
这个解决方案确实迫使我为我的流量使用相同的源端口；随意使用您自己的 iptables-fu 来识别目标的返回数据包。
其他答案中引用的博客文章并不完全正确。不仅您没有完成三次握手，而且内核的 IP 堆栈不知道发生了连接。当它收到 时SYN-ACK，它会发送 aRST-ACK因为它是意外的。第一个或最后一个接收实际上并没有进入它。接收的堆栈SYN-ACK是问题所在。
使用 IPTables 丢弃出站RST数据包是一种常见且有效的方法，但有时您需要RST从 Scapy 发送一个。一个更复杂但非常可行的方法是降低，使用与主机不同的 MAC 生成和响应 ARP。这使您能够在不受主机干扰的情况下发送和接收任何内容。
显然，这是更多的努力。就个人而言，我只RST在实际需要自己发送时才采用这种方法（而不是丢弃方法） RST。