linux内核netfilter之ip_conntrack模块的作用举例--nat和REDIRECT为例

修改应用层协议控制包使用了ip_conntrack，iptables的REDIRECT target也使用了ip_conntrack，另外包括iptables的state模块也是如此，使用ip_conntrack，可见ip_conntrack的重要性，ip_conntrack的一个无比重要的作用是实现nat，可以说REDIRECT target和对诸如ftp的修改以实现server回连client最终都落实到了nat上，比如，所谓的REDIRECT就是内置一个nat规则，将符合matchs的包nat到本机的特定端口，这个和iptables的nat表原理是一样的，不同的是，nat表的配置是显式的nat，而REDIRECT和ip_nat_ftp是隐式的nat而已。它们都是nat，都依赖于原始的ip_conntrack，因此原始的链接流信息并没有丢失，还是可以得到的，事实上，内核就是通过原始的链接流来匹配nat规则的，如果丢弃了原始链接流信息，何谈匹配！如果一个原始链接是a->b，而后不管是显式的nat还是隐式的REDIRECT以及nat_ftp，将a->b改为了a->c，a->b还是可以得到的，内核正是从a->b的流信息中取得了“要转换为a->c”这个信息的。
     在init_conntrack中有以下逻辑：
conntrack = kmem_cache_alloc(ip_conntrack_cachep, GFP_ATOMIC);
conntrack->ct_general.destroy = destroy_conntrack;
conntrack->tuplehash[IP_CT_DIR_ORIGINAL].tuple = *tuple;  //初始化tuple，记录连接地址端口信息，该tuple在nat后不会被改掉，此谓原始流
conntrack->tuplehash[IP_CT_DIR_ORIGINAL].ctrack = conntrack;
conntrack->tuplehash[IP_CT_DIR_REPLY].tuple = repl_tuple; //repl_tuple初始化成和tuple一样的，在nat之后就会被改成nat后的地址，端口信息，此谓修改后的流，repl是replace的意思.
conntrack->tuplehash[IP_CT_DIR_REPLY].ctrack = conntrack;
tuple中就包含了原始流的信息，在随后的nat表的查找后，在alloc_null_binding中初始化conntrack的nat信息，由此就将nat信息和原始流信息统一到了conntrack中了。resolve_normal_ct是ip_conntrack模块使用的，其最后一句：
skb->nfct = &h->ctrack->infos[*ctinfo];
会将连接信息设置到skb中，以备后面的nat或者REDIRECT使用，在nat中，调用ip_conntrack_get取得这个conntrack。在ip_nat_setup_info中会调用ip_conntrack_alter_reply，后者会改变conntrack->tuplehash[IP_CT_DIR_REPLY].tuple的值为一个新的nat后的值。对于REDIRECT target，netfilter提供了一个getsockopt接口可以取得原始流的信息，该接口就是SO_ORIGINAL_DST，最终调用getorigdst，在getorigdst中有以下逻辑：
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;   //原始流的源ip
tuple.src.u.tcp.port = inet->sport; //原始流的源端口
tuple.dst.ip = inet->daddr;   //本机重定向后的ip
tuple.dst.u.tcp.port = inet->dport; //本机重定向后的端口
...
h = ip_conntrack_find_get(&tuple, NULL);  //在既有链接中寻找一个ip_conntrack_tuple_hash的tuple字段和参数tuple一样的，返回ip_conntrack_tuple_hash结构体
...
ip_conntrack_tuple_hash的定义如下：
struct ip_conntrack_tuple_hash
{
    struct list_head list;
    struct ip_conntrack_tuple tuple;
    struct ip_conntrack *ctrack;
};
现在看一下ip_conntrack_find_get如何找到h，在REDIRECT target中，数据肯定要进入本机，而进入本机就要进入NF_IP_LOCAL_IN链，在NF_IP_LOCAL_IN链上注册有一个ip_conntrack_local_in_ops，其HOOK函数为ip_confirm，最终要调用到__ip_conntrack_confirm，__ip_conntrack_confirm有以下逻辑：
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]);
最后的两行将修改后的contrack信息的hash加入了ip_conntrack_hash表，在getorigdst调用ip_conntrack_find_get的时候，所使用的信息就是修改后的contrack信息，因此最终肯定能找到&ct->tuplehash[IP_CT_DIR_REPLY]，而tuplehash[IP_CT_DIR_REPLY]和tuplehash[IP_CT_DIR_ORIGINAL]二者统一到了conntrack中，因此getorigdst的后半段：
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;
将可以得到原始流的信息。
     最后看看redirect的HOOK函数：
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); //重定向到本机的地址转换
}
__ip_conntrack_confirm函数不仅仅由NF_IP_LOCAL_IN链上的operations调用，在POSTROUTING链上也有调用，这就是ip_conntrack_out_ops中的HOOK函数ip_refrag，因此不管怎样，只要发生了地址转换，总逃不过将新的转换后的流信息加入到conntrack中。
作罢！