Linux Kernel netfilter ip_conntrack module function example-Nat and redirect

Ip_conntrack is used to modify the application layer protocol control package, and iptables's redirect target also uses ip_conntrack. In addition, the State module of iptables is also used. ip_conntrack is used to show the importance of ip_conntrack, ip_conntrack is very important to implement Nat. It can be said that redirect target and modification to FTP, for example, are implemented to implement Nat for the server to connect to the client. For example, the so-called redirect is a built-in Nat rule that Nat the matchs-compliant package to a specific port on the local machine. This is the same as the NAT table of iptables. The difference is that, the NAT table is configured with an explicit Nat, while redirect and ip_nat_ftp are implicit Nat. They all rely on the original ip_conntrack. Therefore, the original link stream information is not lost and can still be obtained. In fact, the kernel matches the NAT rule through the original link stream. If the original link stream information is discarded, how can this problem be solved! If the original link is a-> B, and then whether it is an explicit Nat, implicit redirect, or nat_ftp, change a-> B to A-> C, a-> B can still be obtained. The kernel obtains the information "to convert to a-> C" from the stream information of a-> B.
The following logic is available in init_conntrack:
Conntrack = kmem_cache_alloc (ip_conntrack_cachu, gfp_atomic );
Conntrack-> ct_general.destroy = destroy_conntrack;
Conntrack-> tuplehash [ip_ct_dir_original]. tuple = * tuple; // initialize the tuple and record the connection address port information. The tuple will not be changed after Nat. This is the original stream
Conntrack-> tuplehash [ip_ct_dir_original]. ctrack = conntrack;
Conntrack-> tuplehash [ip_ct_dir_reply]. tuple = repl_tuple; // repl_tuple is the same as tuple during initialization. After Nat, it is changed to the address and port information after Nat. This is the modified stream, repl indicates replace.
Conntrack-> tuplehash [ip_ct_dir_reply]. ctrack = conntrack;
Tuple contains the original stream information. After the subsequent NAT table is searched, the NAT information of conntrack is initialized in alloc_null_binding, therefore, the NAT information and the original stream information are unified into the conntrack. Resolve_normal_ct is used by the ip_conntrack module. The last sentence is as follows:
SKB-> nfct = & H-> ctrack-> Infos [* ctinfo];
The connection information will be set to SKB for later Nat or redirect use. In Nat, call ip_conntrack_get to obtain this conntrack. Ip_conntrack_alter_reply will be called in ip_nat_setup_info, and the latter will change the value of conntrack-> tuplehash [ip_ct_dir_reply]. tuple to a new value after Nat. For redirect target, netfilter provides a getsockopt interface to obtain information about the original stream. This interface is so_original_dst, and finally calls getorigdst. The getorigdst has the following logic:
Struct inet_opt * Inet = inet_sk (SK );
Struct ip_conntrack_tuple_hash * h;
Struct ip_conntrack_tuple tuple;
Ip_ct_tuple_u_blank (& tuple );
Tuple. SRC. IP = iNet-> rcv_saddr; // source IP address of the original stream
Tuple. SRC. U. tcp. Port = iNet-> sport; // source port of the original stream
Tuple. dst. IP = iNet-> daddr; // the IP address after the local redirection
Tuple. dst. U. tcp. Port = iNet-> dport; // The locally redirected port.
...
H = ip_conntrack_find_get (& tuple, null); // find the same tuple field of ip_conntrack_tuple_hash in the existing link and return the ip_conntrack_tuple_hash struct.
...
Ip_conntrack_tuple_hash is defined as follows:
Struct ip_conntrack_tuple_hash
{
Struct list_head list;
Struct ip_conntrack_tuple tuple;
Struct ip_conntrack * ctrack;
};
Now let's take a look at how ip_conntrack_find_get finds H. In redirect target, the data must enter the local machine, and enter the nf_ip_local_in chain. In nf_ip_local_in_ops, the hook function is ip_confirm, And the _ ip_conntrack_confirm ,__ ip_conntrack_confirm has the following logic:
Unsigned int hash, repl_hash;
...
Hash = hash_conntrack (& CT-> tuplehash [ip_ct_dir_original]. tuple );
Repl_hash = hash_conntrack (& CT-> tuplehash [ip_ct_dir_reply]. tuple );
...
List_prepend (& ip_conntrack_hash [hash], & CT-> tuplehash [ip_ct_dir_original]);
List_prepend (& ip_conntrack_hash [repl_hash], & CT-> tuplehash [ip_ct_dir_reply]);
The hash of the modified contrack information in the last two rows is added to the ip_conntrack_hash table. When getorigdst calls ip_conntrack_find_get, the information used is the modified contrack information, therefore, we can certainly find & CT-> tuplehash [ip_ct_dir_reply], while tuplehash [ip_ct_dir_reply] And tuplehash [partition] are unified to conntrack. Therefore, the second half of getorigdst is:
Sin. sin_port = H-> ctrack-> tuplehash [ip_ct_dir_original]. tuple. dst. U. tcp. port;
Sin. sin_addr.s_addr = H-> ctrack-> tuplehash [ip_ct_dir_original]. tuple. dst. IP;
You can get the original stream information.
Finally, let's look at the Redirect hook function:
Static unsigned int redirect_target (...)
{
...
Ct = ip_conntrack_get (* pskb, & ctinfo );
...
Indev = (struct in_device *) (* pskb)-> Dev-> ip_ptr;
Newdst = indev-> ifa_list-> ifa_local;
Newrange = (struct ip_nat_multi_range)
{1, {Mr-> range [0]. Flags | ip_nat_range_map_ips,
Newdst, newdst,
Mr-> range [0]. Min, Mr-> range [0]. Max }}});
Return ip_nat_setup_info (CT, & newrange, hooknum); // redirect to local address translation
}
The _ ip_conntrack_confirm function is called not only by operations on the nf_ip_local_in chain, but also on the postrouting chain. This is the hook function ip_refrag in ip_conntrack_out_ops, the new converted stream information cannot be added to the conntrack.
Come on!