The role of Ip_conntrack module in Linux kernel netfilter example--ftp as an example __linux

Many protocol control information is included in the application layer data, this information directly affects the establishment of the link, such as FTP protocol, FTP is divided into port mode and pass mode, port mode, the first client Connection server 21 ports, Then, when the data is needed, the client sends a control packet to the server, which contains the client-side ports and their own IP addresses, and the server receives its 20 port to connect to the proposed IP and port in the client control pack, in which case If the client uses a private network address behind the NAT, the server will not be able to connect to the client, so the NAT gateway must handle the situation by modifying the control pack that the client sends to the server (if encryption will not be possible to modify, but fortunately FTP is unencrypted) In pass mode, the client connects to the server's 21 port, and if you want to transfer data,client also connect to another random port on the server, which is passed to the client by the control packet sent by the server. If the client or server side of the firewall prohibits any unfamiliar ports, then the data will be blocked by the firewall, whether in port mode or pass mode, the firewall will handle the "second" Data connection path release problem, In Linux is through the RELATED state to release, as mentioned above, just configure a--state related-j accept rules can, but the specific rules how to achieve, Linux connection tracking module is how to deal with the FTP NAT problem, This article details the.
First, we start with the Ip_conntrack hook function:
unsigned int ip_conntrack_in (...)
{
...
Proto = Ip_ct_find_proto ((*PSKB)->nh.iph->protocol); Remove the protocol number from the packet
...//resolve_normal_ct will try to find the connection to which the newly entered package belongs in the established connection, and if it is not found, a new connection is established, and the data associated with the connection is initialized, such as helper
ct = resolve_normal_ct (*PSKB, proto,&set_reply,hooknum,&ctinfo);//The Init_conntrack function called in this is a function that does a lot of things
...
if (ret!= nf_drop && ct->helper) {//If helper then call its help function
ret = ct->helper->help (*PSKB, CT, ctinfo);
...
}
...
}
Init_conntrack has the following logic:
...//Find the connection from the list if it is found that this is a "predictive" connection
expected = List_find (&ip_conntrack_expect_list, EXPECT_CMP,
struct Ip_conntrack_expect *, tuple);
...
if (expected) {
__set_bit (Ips_expected_bit, &conntrack->status); The predicted connection to the, set a flag, in the case of RESOLVE_NORMAL_CT get the existing connection will be judged if this flag, then set the ip_ct_related state, which can be used for the determination of the filter
expected->sibling = Conntrack; The predicted connection has arrived and initialized. Expected->sibling is null at the time of prediction, because it is only a prediction, the connection has not really come, after the Ip_conntrak forecast, Ip_nat will use the forecast results, The helper help is then invoked to modify the application-level and connection-related control data, such as IP address and port information, to determine whether to invoke Ip_nat's helper when traversing all predicted connections to an existing connection, if a prediction is a ip_conntrack_ Expect's sibling field is not Null,ip_nat will skip this forecast because it is already a real connection, and it has been help when it is still a predictive connection.
...
}
...
Each ip_conntrack can have multiple helpers to help handle connection-related information, such as the FTP protocol through the firewall needs to deal with Nat and Vice connection (data connection) problem, so it is necessary to use a helper module to deal with this kind of situation, processing FTP The helper of Nat and the helper of the processing Vice connection is not a helper, the former is the IP_NAT_FTP structure, the latter is the IP_CONNTRACK_FTP structure, although different, but their processing logic and registration logic are the same, so to the back of the said FTP NAT when the unified description. The following is the implementation logic of the Help function for IP_CONNTRACK_FTP registration
static int Help (...)
{
...//Operation SKB, take out all the information we need
Skb_copy_bits (SKB, Dataoff, Ftp_buffer, Skb->len-dataoff);
...
Array[0] = (Ntohl (CT->TUPLEHASH[DIR].TUPLE.SRC.IP) >>) & 0xFF;
ARRAY[1] = (Ntohl (CT->TUPLEHASH[DIR].TUPLE.SRC.IP) >>) & 0xFF;
ARRAY[2] = (Ntohl (CT->TUPLEHASH[DIR].TUPLE.SRC.IP) >> 8) & 0xFF;
ARRAY[3] = Ntohl (CT->TUPLEHASH[DIR].TUPLE.SRC.IP) & 0xFF;
The above array is the IP address that the server needs to connect to
for (i = 0; i < array_size (search); i++) {
if (Search[i].dir!= dir) continue;
Found = Find_pattern (...); /search for search characters in Ftp_buffer, if found, this packet needs help, where there is a number of parameters, each element of the array is a matching key, this is called search, is a ftp_search structure type array
if (found) break;
}
...//If not found, return, indicating that the data for this arrival does not require help
Exp = Ip_conntrack_expect_alloc ();
...//Initialize a ip_conntrack_expect that can be used to describe a connection that will be established
EXP-&GT;EXPECTFN = NULL;
ip_conntrack_expect_related (exp, CT); Ready to add a related connection, if the user configures the related connection in the Iptables rule, the FTP port mode data connection can be unimpeded. Iptables's related connection is "expected" here and then added to the existing connection.
ret = nf_accept;
Out
UNLOCK_BH (&ip_ftp_lock);
return ret;
}
The "expected" connection is eventually added to the linked list of connected links to this "expected" connection in the Ip_conntrack_expect_insert function, and the expected connection is added to a system global list, and if an existing connection needs to limit the "expected" Connection to establish a connection time, you need to start a timer, the timer timeout connection is not yet, will delete the expected connection. This related connection will be used by the NetFilter state module, such as you use--state new/established/... , in the match callback function in the state module, the system takes out the connection that the packet belongs to, then takes out the state of the connection, compares it to the parameter, and returns to the target choice.
The above is the data in the Ip_conntrack module of the flow, out of the ip_conntrack should enter the Ip_nat, or from its hook said:
static unsigned int ip_nat_fn (...)
{
...
ct = Ip_conntrack_get (*PSKB, &ctinfo); Gets the connection, returns null if not obtained
...//If you do not get the existing connection, return accept (note the special case of ICMP redirection), which is determined by subsequent chains, however, Nat always works after Conntrack, so as long as there is a connection, Conntrack will add it to the hash
Switch (ctinfo) {
...
Case IP_CT_NEW://If the first package is a connection, then initialize a series of structures, including two-direction NAT conversion tables, FTP, and so on that need help for the relevant structure of the Protocol and so on
info = &ct->nat.info;
Write_lock (&ip_nat_lock);
if (!) ( Info->initialized & (1 << maniptype)) {
...
ret = Ip_nat_rule_find (PSKB, Hooknum, in, Out, CT, info);
...
return do_bindings (CT, ctinfo, info, hooknum, PSKB);
}
unsigned int do_bindings (...)
{
...
int proto = (*PSKB)->nh.iph->protocol;

...//implement address/port conversion, omitted. The protocol header that modifies the packet based on direction and address/port information in the two-direction conversion table
Helper = info->helper; Info is built when the ip_nat_setup_info is initialized, and it's just taken out
if (helper) {
...//A primary connection can have multiple secondary connections to the related, so walk through these secondary connections below
List_for_each_prev (Cur_item, &ct->sibling_list) {
...//If it is already a established connection, then the work that is going to be done has already been done and will no longer do it.
if (Exp_for_packet (exp, *PSKB)) {//package is reasonable to call the Help function, in the Help function to handle special NAT conversion, such as FTP port mode-related NAT conversion
ret = helper->help (CT, exp, info, Ctinfo, hooknum, PSKB);
...
}
For the IP_NAT_FTP Help module, the execution logic for the aid function is as follows:
static unsigned int help (...)
{
...
Ct_ftp_info = &exp->help.exp_ftp_info;
...
Ftp_data_fixup (Ct_ftp_info, CT, PSKB, Ctinfo, exp);
...
}
Finally Ftp_data_fixup called Mangle[ct_ftp_info->ftptype] (...) function, apparently the last function completes the modification of the packet, and the packet is modified so that the FTP server can successfully connect to the client. Because the client is often behind a firewall with a NAT function, and are the private network address, and in the FTP port mode, if the client will be a private address proposed to the FTP server for the connection, the server is not connected, the proposed IP address in the FTP packet, Therefore, it is necessary to modify the packet, modify the proposed address and port to the NAT address and port, while laying a NAT, for the server to connect the client when the request will be really transferred to the intranet client. Ip_nat_mangle_tcp_packet is a very important function in ip_nat_helper.c, that is, it completes the modification of the application-tier packet.
The total process of ip_conntrack and Ip_nat processing FTP is that the Ip_conntrack module gets the connection information, and then according to the connection information can get a helper, it needs to be explained that a connection can be completely without helper, And most of them have no helper, whether the helper is required depends on the type of connection, and generally touches the application layer to control the data to use the helper, such as the FTP control command is transmitted in the application layer data, the type of connection can be obtained from the packet and the protocol header, Therefore, the Ip_conntrack module requires that the packet not be segmented, which means that the complete IP packet is required. After you get the helper, you start calling the Help function, and then you determine whether the current packet needs help, such as a special command to determine whether it is FTP, which creates a new connection, and, if so, the function "predicts" To an upcoming connection and associate it with the current connection, and then ip_conntrack basically nothing to do, the packet continues to flow through the netfilter, into the NAT, and Nat as Ip_conntrack to determine if help is needed, If so, the helper help function is invoked to determine whether the need for help is generally based on whether to "predict" the incoming connection in the Ip_conntrack module, and if so, call the helper help function of Nat. And the predicted connection parameters are passed in, and the application layer control data are modified according to the information of the predictive connection in the IP_NAT_FTP help function.
The registration of both types of helper is done while the module is initialized, and the binding of the helper to the connection or the NAT occurs when the connection is initialized. IP_NAT_FN is the hook for NAT, which needs to invoke Call_expect for the ip_ct_new package, which ultimately calls the following function to implement the designation of the FTP-related ip_nat_helper structure, which is registered when the module is initialized:
unsigned int ip_nat_setup_info (...)
{
...
Info->helper = List_find (&helpers, helper_cmp, struct ip_nat_helper *, &reply);
Looking for ip_nat_ftp helper, in Ip_nat_ftp init, the ip_conntrack_helper_register will be invoked to register FTP-related information into the kernel, which is contained in the IP_NAT_HELPER structure , where a lot of the static data is used to match the helper, such as creating a new connection, when the data crosses Conntrack and enters the NAT, it calls the Ip_nat_setup_info, in which, as mentioned above, List_find is actually using the current addr, Port and other information and registered helper to compare, once there is a hit of the helper out of the left for later use, Ip_nat_helper most important is the help function.
...
}
The initialization function for the IP_NAT_FTP module is as follows:
static int __init init (void)
{
...
for (i = 0; (I < Max_ports) && Ports[i]; i++) {
Ftp[i].tuple.src.u.tcp.port = htons (Ports[i]);
Ftp[i].tuple.dst.protonum = ipproto_tcp;
Ftp[i].mask.src.u.tcp.port = 0xFFFF;
Ftp[i].mask.dst.protonum = 0xFFFF;
ftp[i].max_expected = 1;
ftp[i].timeout = 0;
Ftp[i].flags = Ip_ct_helper_f_reuse_expect;
Ftp[i].me = ip_conntrack_ftp;
Ftp[i].help = Help;
...
ret = Ip_conntrack_helper_register (&ftp[i]);
...
}
return 0;
}
A similar Ip_conntrack helper is also registered when the module is initialized, and is given the same connection when the connection is initialized.
In short, helper modules are generally helpful for protocols that need to transmit control data in application-level data, because the OS implementation stack does not contain the application layer, but sometimes the application-layer control data must be modified to require an additional help module. General helper changes are control data, not business data, the so-called control data is not related to the business, only affect the connection itself data.