TCP disconnection status and Linuxnf_conntrack

TCP disconnection status and Linuxnf_conntrack
The question is a little big, but it is inevitable that there will be some anger!
Our gateway products are currently in the system testing phase, which is not smooth, but not smooth! Slack in all aspects, including me! In addition to slack, I am still looking for a chance to attack! By the way, we despise the tester and hope to create an imagination that the problem he discovers is not a problem, but a result of his ignorance! Just yesterday, when the opportunity came, I was so angry!
Many people think that I am an expert on the lower layer network and have no right to contact TCP or other users, but I have no permission to abuse or abuse TCP! Because it is too complex, as a low-level facility, if it is too complex, the complex space of the application layer will be reduced! Programmers, especially socket programmers, always regard IP addresses and network cards as a black box, and focus on TCP. They are dismissive of UDP and will not focus on non-cooperative UDP traffic. This is the essential difference between communication networks and programmers. After all, the division of labor is different. However, I started from studying TCP. At first, I could not touch something like a router, but I did not know what traffic engineering was. But when I understood the IP address, I found that what a wonderful IP address is, can bring people an instant climax! TCP, however, is a mess. During product system testing, a difficult problem with TCP can make a R & D Engineer toss around for a few days or even a few days. In the past few days, the tester was so cool, there is nothing to worry about. You can chat and watch the news! TMD wants to give the tester a chair! Rotating and lifting the seat will definitely blow up, the chrysanthemum will be broken, and the flowers will be broken!
It is a pity that yesterday's events completely destroyed this pattern when I was angry! This is the case.
Client A: 128.129.1.2
Internet gateway port (Client connection): 128.129.1.1
Gateway network port (connection server): 192.168.220.223
Server: 192.168.30.75
NAT redirect conversion is performed on the gateway to redirect traffic from the Access Server to the local apache server. The apache server implements the forward proxy function (Forward proxy is an important concept. Please understand it in depth ). The rules are as follows:
Iptables-t nat-a prerouting-d 192.168.30.75-j REDIRECT -- to-ports 80
What a simple rule, but how painful it is to comprehend.

Testers, strictly speaking, are black box testers (non-white box testers). Even if the test function is used, we can capture packets without affecting the business. The key is to capture packets and misunderstand us! The problem is as follows:
The connection establishment and data transmission have all gone through the proxy, but the connection is not removed by NAT and direct forward. As a result, the 192.168.30.75 server directly receives the packet with the source IP address 128.129.1.2. What's going on ?!
In fact, this has no effect, as long as the application can stick to it for a long enough time!
I found that this is the active disconnection of server 30.75, that is, it actively sent FIN, and then the client sent ACK, but the client did not send its own FIN, it took two minutes to send the FIN/ACK message. At this time, the connection was only unilaterally disconnected. At this time, the client is in the CLOSE_WAIT status before sending the FIN. Because the current product is built based on the previous product, in the previous product, I reduced the timeout of conntrack and TCP for some special reasons, for example, I reduced the establish timeout of TCP conntrack to 120 seconds (the default value is 5 days), so the timeout Status During disconnection is smaller, so within two minutes, conntrack has long been deleted!
At this time, the FIN of the client comes. Since the conntrack has been deleted, will the gateway create a new conntrack for it? It depends on whether loose is set. Of course I have set it, that is, it is no longer based on syn to create a new conntrack. It is reasonable to say that the Linux gateway will create a new conntrack, however, it carries the fin flag! This means that Linux will not create a new conntrack! Therefore, the data packet is directly forwarded. But this will not have any impact! Because data packets carrying fin have their own control channel timeout period. It will be automatically converted after expiration, which is completely different from the establish status! Why?
In this way, let's start with the TCP/IP design. There is a design scheme called in-band control, that is, the control channel and Data Channel share a network path. TCP is a typical design, and the other is IP, for example, ICMP is the IP Control Protocol. However, you cannot say that IP is not completely in-band control. Although it is different from TCP, it is only caused by its stateless status!
The TCP Control CHannel uses a flag to distinguish between data segments carrying SYN and FIN. the Linux conntrack's TCP behavior is based on this control mark, if an establish packet comes-no syn, no fin, and no conntrack found, Linux creates a new conntrack item for Linux when setting the loose flag, and then for the control signal, for example, the fin segment is different, and Linux will not be created. However, this does not affect the result of the terminal. Although the Linux system does not have a successful NAT, the data will not arrive at the server correctly, but because of the fin, the timeout will be automatically processed by the timeout.
However, you must pay attention to the direction, which may cause some problems. If an active FIN is intercepted, is there a major problem? No, because the end that actively sends a FIN changes its status no matter whether it is intercepted or not, and the end that passively closes does not receive the FIN, it will also exercise the right of timeout retransmission restriction, although it may be slower.
Sustained hunger! Stay hungry!