Status of TCP disconnects with Linux Nf_conntrack

The topic is a bit big, but there are some anger!
Our gateway products are currently in the system testing phase, not too smooth, is too bad! All the slack, including me! I'm still looking for a chance to hit the counter, except slack! By the way, scorn the tester, hoping to produce an imagination that the problem he found is not a problem, but because of his ignorance caused! Just yesterday, when the opportunity came, I was so angry!
Many people think I am the next three layer of network experts, for TCP, such as the right to do, but I am the TCP in addition to abusive or abusive! Because it is too complex, as a low-level facility, if too complex, the application layer of complex space is small! Programmers, especially those who program sockets, always use IP and Nic as a black box, while focusing on TCP, they are dismissive of UDP, and will not pay attention to what non-cooperative UDP traffic. This is the essential difference between communication networks and people and programmers, after all, the division of labor is different. But I also started from the study of TCP, at first I can not touch the router and other things, but also do not know what traffic engineering, but later when I understand the IP, I found that IP is how wonderful, can let people instantly orgasm! And TCP, is mess, in the product system testing, a TCP troubleshooting can let a researcher toss an afternoon or even a few days, and these days, testers cool, nothing, can chat, see the news, this is how sad, so people can't let go! I want to put a chair on the test crew! Rotating lift seat will explode, chrysanthemum residue, the ground injury, flowers fall people heartbroken!
Unfortunately, yesterday's events in my angry state, completely extinguished this pattern! This is the way things are.
Client a:128.129.1.2
Gateway Gateway (Connection client): 128.129.1.1
Gateway Intranet port (Connection server): 192.168.220.223
Server: 192.168.30.75
Gateway do NAT redirect conversion, redirect the traffic to the server to the local Apache server, Apache server to perform the forward proxy function (forward proxy is an important concept, please understand deeply). The rules are as follows:
iptables-t nat-a prerouting-d 192.168.30.75-j REDIRECT--to-ports
What a simple rule, yet how painful it is to comprehend.

Testers, strictly speaking is black box testers (not white box), test function even if, do not affect the business can be, but what to grab the bag, the key is to catch the bag also misunderstood us! The problem is as follows:
The establishment of the connection and the transmission of the data, all through the agent, but the removal of the connection is not NAT, directly forward out, resulting in the 192.168.30.75 server directly received a source IP address of 128.129.1.2 packets. What's going on?!
In fact, this is no effect, as long as the application can persist long enough!
I found that this is a server 30.75 active disconnect, that is, it actively sent fin, after the client sent an ACK, but the client has not sent their own side of fin, after two minutes to send the Fin/ack, the connection is only a unilateral disconnection. At this point, it is in the close_wait state before the client sends Fin. Since the current product is based on the previous product built, in the previous product, I have some special reasons for the Conntrack and TCP-related timeout has been reduced to a small enough, For example, I reduced the timeout of TCP's Conntrack establish to 120 seconds (by default, 5 days), so the status timeout was smaller when disconnected, so Conntrack was deleted in two minutes!
At this point the client fin came, because Conntrack has been removed, the gateway will establish a new conntrack for it? This depends on whether there is a setup loose, I certainly set up, that is, no longer with SYN to establish a new conntrack basis, supposedly, the Linux gateway will create a new conntrack, but it carries the FIN flag! This means that Linux does not create a new conntrack! So the packet is forward directly. But it won't do any harm! Because the packet carrying fin has its own control channel timeout period. It will be converted automatically after expiry, which is very different from the establish state! What is this for?
This starts with the TCP/IP design. There is a design is called in-band control, that is, the control channel and the data channel share a network path, the TCP protocol is typical of this design, the other is the IP, such as ICMP is the IP control protocol, however you can not say that IP is not a complete in-band control, although it differs from TCP, That's just because it's stateless!
TCP control channels are distinguished by flags, and the data segments that carry Syn,fin are control segments, and the behavior of Linux conntrack on TCP is based on this control flag, if there is a establish packet-no SYN, no fin, Conntrack is not found, in the case of setting the loose flag, Linux creates a new Conntrack item, and then the control signal, such as the fin segment, is different and Linux is not created. However, this does not affect the results of the terminal, although because Linux does not have a NAT success caused the data will not reach the server correctly, but because of fin already, the terminal will automatically use timeout processing.
But be sure to pay attention to the direction, which may cause a slight problem. If the active fin is intercepted, is there a big problem? No, because the active side of the fin, regardless of whether it will be intercepted, will change the state, while the passive closed end, although not receiving fin, will also exercise time-out retransmission restrictions, although it may be slower.
Persistent hunger! Stay hungry!

Status of TCP disconnects with Linux Nf_conntrack