Hello Simon, On Tue, Mar 19, 2024 at 4:16 AM Simon Horman <horms@xxxxxxxxxx> wrote: > > On Mon, Mar 11, 2024 at 03:05:50PM +0800, Jason Xing wrote: > > From: Jason Xing <kernelxing@xxxxxxxxxxx> > > > > Supposing we set DNAT policy converting a_port to b_port on the > > server at the beginning, the socket is set up by using 4-tuple: > > > > client_ip:client_port <--> server_ip:b_port > > > > Then, some strange skbs from client or gateway, say, out-of-window > > skbs are eventually sent to the server_ip:a_port (not b_port) > > in TCP layer due to netfilter clearing skb->_nfct value in > > nf_conntrack_in() function. Why? Because the tcp_in_window() > > considers the incoming skb as an invalid skb by returning > > NFCT_TCP_INVALID. > > > > At last, the TCP layer process the out-of-window > > skb (client_ip,client_port,server_ip,a_port) and try to look up > > such an socket in tcp_v4_rcv(), as we can see, it will fail for sure > > because the port is a_port not our expected b_port and then send > > back an RST to the client. > > > > The detailed call graphs go like this: > > 1) > > nf_conntrack_in() > > -> nf_conntrack_handle_packet() > > -> nf_conntrack_tcp_packet() > > -> tcp_in_window() // tests if the skb is out-of-window > > -> return -NF_ACCEPT; > > -> skb->_nfct = 0; // if the above line returns a negative value > > 2) > > tcp_v4_rcv() > > -> __inet_lookup_skb() // fails, then jump to no_tcp_socket > > -> tcp_v4_send_reset() > > > > The moment the client receives the RST, it will drop. So the RST > > skb doesn't hurt the client (maybe hurt some gateway which cancels > > the session when filtering the RST without validating > > the sequence because of performance reason). Well, it doesn't > > matter. However, we can see many strange RST in flight. > > > > The key reason why I wrote this patch is that I don't think > > the behaviour is expected because the RFC 793 defines this > > case: > > > > "If the connection is in a synchronized state (ESTABLISHED, > > FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), > > any unacceptable segment (out of window sequence number or > > unacceptible acknowledgment number) must elicit only an empty > > Not for those following along, it appears that RFC 793 does misspell > unacceptable as above. Perhaps spelling was different in 1981 :) Thanks for the check. Yes, it did misspell that word. Should I correct that word in my quotation? > > > acknowledgment segment containing the current send-sequence number > > and an acknowledgment..." > > > > I think, even we have set DNAT policy, it would be better if the > > whole process/behaviour adheres to the original TCP behaviour as > > default. > > > > Suggested-by: Florian Westphal <fw@xxxxxxxxx> > > Signed-off-by: Jason Xing <kernelxing@xxxxxxxxxxx> > > ...
