问题
I am trying to solve the below issue,
I have a iptables rule in my output chain which says that if the packet matches certain criteria, then queue it and send it to userspace using NFQUEUE
The userspace program receives it,and once it recieves it, it checks if the packet is a tcp packet and if yes, it modifies the content of the packet
After Modifying it, it sends out and I am able to see that till now it works properly, I was able to re-calculate the checksum and verify it and update the length of the packet and everything gets properly reflected and I am able to confirm it using wireshark and I am also able to see that the packet is reaching the destination. The packet I am modifying is HTTP GET Packet.
The Intial TCP handshake happens and after the intial handshake, I am sending out the modified HTTP GET Packet and I am getting a response back from the server, but after this, the client for some reason generates a TCP RST packet and sends it to the destination, I am not sure why this happens, Earlier while googling, people had reported it might be due to sequence number disorder, but in my case, since I am modifying the first packet after the TCP Handshake, the sequence number will be the same as that of my last ACK packet belonging to the TCP Handshake.
I am suspecting that some part of the kernel module is caching the length of the HTTP GET request packet, and once I modify it, and update the length, the cached part is not getting updated, and as a reason, the client is sending the TCP RST Packet.
Can some one help me out with the above scenario.
回答1:
The problem with this is that changing the length of a TCP packet which is part of an active flow messes up the sequence number code, which causes whichever side of the connection that notices to reset the connection. See the details in RFC 793 section 3.4
来源：https://stackoverflow.com/questions/30269113/tcp-packet-mangling-using-nfqueue