定位 conntrack TCP RESET 问题#
How connection tracking works at a high level#
The connection tracker first extracts the IP addresses and higher-level protocol information from the packet. “Higher level protocol information” is the transport protocol specific part. A common example are the source and destination port numbers (tcp, udp) or the ICMP id. A more exotic example would be the PPTP call id. These packet fields – the IP addresses and protocol specific information – are the lookup keys used to check the connection tracking table.
In addition to checking if a packet is new or part of a known connection, conntrack also performs protocol specific tests. In case of UDP, it checks if the packet is complete (received packet length matches length specified in the UDP header) and that the UDP checksum is correct. For other protocols, such as TCP, it will also check:
Are TCP flags valid (for example a packet is considered invalid if both RST and SYN flags are set)
When a packet acknowledges data, it checks that the acknowledgment number matches data sent in the other direction.
When a packet contains new data, it checks that this data is within the receive window announced by the peer.
Any failures in these checks cause the packet to be considered invalid. For such packets, conntrack will neither create a new connection tracking entry nor associate it with an existing entry, even if one exists. Conntrack can be configured to log a reason for why a packet was deemed to be invalid:
# sysctl -a | grep nf_log net.netfilter.nf_log.10 = NONE net.netfilter.nf_log.2 = NONE net.netfilter.nf_log_all_netns = 0
The following examples occur with the settings created using “sudo sysctl net.netfilter.nf_log.2=nf_log_ipv4” and “sudo sysctl net.netfilter.nf_conntrack_log_invalid=6“.
nf_ct_proto_6: invalid packet ignored in state ESTABLISHED SRC=10.47.217.34 DST=192.168.0.17 LEN=60 DF SPT=443 DPT=47832 SEQ=389276 ACK=3130 WINDOW=65160 ACK SYN
Runing Out of max conntrack table size#