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中。
作罢!

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页