不要なRST TCP Scapyを含むパケット
TCPがどのように機能するかを理解するために、私は自分のTCP SYN/SYN-ACK/ACK（チュートリアルに基づく： http://www.thice.nl/creating-ack-get-packets-with-scapy/ ）。
問題は、コンピューターがサーバーからSYN-ACKを受信するたびに、接続プロセスを停止するRSTパケットを生成することです。
OS XLionとUbuntu10.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を送信します。
解決策（ブログで言及されているように）は、カーネルがRSTパケットを送信しないようにファイアウォールで保護することです。
Iptables以外の回答はありませんが、リセットの問題を修正することはできます。フィルタテーブルで発信リセットをフィルタリングしようとする代わりに、rawテーブルでターゲットからのすべての着信パケットをフィルタリングします。これにより、scapyは引き続きパケットを認識しますが、ターゲットからの戻りパケットがカーネルによって処理されることさえありません。次の構文を使用しました。
iptables -t raw -A PREROUTING -p tcp --dport <source port I use for scapy traffic> -j DROP
このソリューションでは、トラフィックに同じ送信元ポートを使用する必要があります。独自のiptables-fuを使用して、ターゲットのリターンパケットを識別してください。
他の回答で引用されているブログ記事は完全に正しいわけではありません。 3ウェイハンドシェイクを完了していないだけでなく、カーネルのIPスタックが接続が発生していることを認識していないということです。 SYN-ACKを受信すると、予期しないためRST-ACKを送信します。最初または最後に受け取ることは、実際には入りません。スタック受信SYN-ACKが問題です。
IPTablesを使用してアウトバウンドRSTパケットをドロップすることは一般的で有効なアプローチですが、ScapyからRSTを送信する必要がある場合もあります。より複雑ですが非常に実行可能なアプローチは、ホストとは異なるMACを使用してARPを生成し、応答することです。これにより、ホストからの干渉なしに何でも送受信できるようになります。
明らかに、これはより多くの努力です。個人的には、実際にRSTを自分で送信する必要がある場合にのみ、このアプローチを採用します（RSTドロップアプローチとは対照的です）。