Linux系统如何平滑生效NAT-BUGFIX

在《Linux系统如何平滑生效NAT》中，代码有两处问题。这只是目前发现的，没有发现的还有很多很多，这就是我为何不一开始把代码搞复杂的原因。

1.一个bug附带一个优化：

注意以下的代码：

if (!nf_nat_initialized(ct, maniptype)) {                      //NAT还没有设置进conn的情况                      ...                } else                        //NAT已经设置进conn的情况                        pf_debug("Already setup manip %s for ct %p\n",                                 maniptype == IP_NAT_MANIP_SRC ? "SRC" : "DST",                                 ct);

在NAT已经设置进conn的情况下，仅仅打印了一行日志，而判断NAT是否已经设置进conn的nf_nat_initialized实现正是两个bit位，不同的HOOK点判断位不同，而在我的原始实现中，是清除了alloc_null_binding设置的bit位，进而如果是alloc_null_binding将NAT设置到了conn，也算没有匹配到NAT规则，最终继续匹配，这样就达到了“如果开始没有配置任何NAT时已经confirm了数据流，当配置好NAT后能瞬时生效”的目的。
        然而却存在一个问题，那就是当原来的NAT规则改变了的时候，无法瞬时生效新NAT规则的问题。这个问题比较难以解决，我先放置一边，即使不考虑这个这个问题，光上述的代码也有问题。何必在alloc_null_binding之后清除bit位呢？直接把“继续查找的逻辑放在那个else打印日志的位置不就可以了么？因此我还原了$K/net/ipv4/netfilter/nf_nat_standalone.c文件的修改，也就是说nf_nat_rule_find函数不必再修改，而只需要修改nf_nat_fn，在else打印日志的地方添加一个goto即可，goto到if (!nf_nat_initialized(ct, maniptype))判断的下一行，其余的修改保持不变。
        现在可以考虑已经是ESTABLISHED状态的conntrack的新NAT规则及时生效的问题了，刚才之所以说它比较难，是因为这需要让nf_nat_fn函数知道什么时候有一条新的NAT规则代替了旧的，而这种行为对于计算机而言，最终无非落实到的就是一系列的查找与比较操作，这种事情做下来的话，还不如不再区分NEW与ESTABLISHED状态，干脆每一个数据包都执行一次nf_nat_rule_find算了，最终将完全失效Linux NAT实现的有状态语义以及效率。因此这种高度策略化的配置应该由调用者来决定，所以我的修改方案就是增加一个sysctl参数，如果用户管理员想即使生效被改变的NAT，那么就将该参数设置为非0，以此来改变NAT规则的匹配行为：

static unsigned intnf_nat_fn(unsigned int hooknum,          struct sk_buff *skb,          const struct net_device *in,          const struct net_device *out,          int (*okfn)(struct sk_buff *)){       ......        nat = nfct_nat(ct);        if (!nat ) {                /* NAT module was loaded late. */               //原来的实现就是：只要在confirm之后加载的NAT模块，就不管了！                if (/*设置一个开关，平滑过渡模式时打开*/ 0 && nf_ct_is_confirmed(ct))                        return NF_ACCEPT;                nat = nf_ct_ext_add(ct, NF_CT_EXT_NAT, GFP_ATOMIC);                if (nat == NULL) {                        pr_debug("failed to add NAT extension\n");                        return NF_ACCEPT;                }        }        switch (ctinfo) {        case IP_CT_RELATED:        case IP_CT_RELATED+IP_CT_IS_REPLY:                if (ip_hdr(skb)->protocol == IPPROTO_ICMP) {                        if (!nf_nat_icmp_reply_translation(ct, ctinfo,                                                           hooknum, skb))                                return NF_DROP;                        else                                return NF_ACCEPT;                }                /* Fall thru... (Only ICMPs can be IP_CT_IS_REPLY) */       //只要没有返回包到来，能保证一直都是NEW        case IP_CT_NEW:                /* Seen it before?  This can happen for loopback, retrans,                   or local packets.. */                if (!nf_nat_initialized(ct, maniptype)) {retry:renew:                        unsigned int ret;                        if (hooknum == NF_INET_LOCAL_IN)                                /* LOCAL_IN hook doesn't have a chain!  */                                ret = alloc_null_binding(ct, hooknum);                        else                                ret = nf_nat_rule_find(skb, hooknum, in, out,                                                       ct);                        if (ret != NF_ACCEPT)                                return ret;                        //以下新添加的是要点：                        //如果是已经完全经过此BOX的数据包，且从来没有成功被iptables规则NAT，                        //则继续尝试匹配iptables的NAT规则，因为可能在数据包重传期间，有新的                        //iptables规则加入进来。                        if (nf_ct_is_confirmed(ct)) {                                struct net *net = nf_ct_net(ct);                                //如果匹配到了新的规则，则更新tuple在chian中的位置。                                hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);                                hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_REPLY].hnnode);                                //如果不进行这个del and reInsert操作，那么就会出现返回包无法被转换                                //成原始包的情形！                                nf_conntrack_hash_insert(ct);                        }                        //以上没有优化！！优化点在于：只有在非alloc_null_binding调用成功的情况                        //下才会尝试更新tuple的chain位置，否则不做无用功！                } else {                        pf_debug("Already setup manip %s for ct %p, but retry\n",                                 maniptype == IP_NAT_MANIP_SRC ? "SRC" : "DST",                                 ct);                        goto retry;                 }                 break        default:        /* ESTABLISHED */        NF_CT_ASSERT(ctinfo == IP_CT_ESTABLISHED ||                 ctinfo == (IP_CT_ESTABLISHED+IP_CT_IS_REPLY));        //对于ESTABLESHED状态的连接在sysctl参数为1的状态下，强行进行NAT规则查找！        if ((ctinfo == IP_CT_ESTABLISHED && ctinfo != (IP_CT_ESTABLISHED+IP_CT_IS_REPLY)) &&                 nf_nat_slowpath) {                 pf_debug("Already setup manip %s for ct %p, but renew\n",                                 maniptype == IP_NAT_MANIP_SRC ? "SRC" : "DST",                                 ct);                 //换个名字！                 goto renew;         }         ...}

如果想对于已经生效NAT的数据流改变NAT策略的话，请设置sysctl_nf_nat_slowpath为1，持续$max_time后，将其设置回0。这是为何？因为不能破坏Linux NAT的原始逻辑以及不能影响效率！那么max_time该怎么选择呢？当然是所有conntrack超时时间的最长者+10了，因为如果这么长时间没有数据包，conntrack超时被释放，下一个到来的包就是NEW了，如果恰好在这段时间期间有包，直接生效新的NAT，加上5到10秒时间作为用户态程序的时钟校正，故而max_time设置的不多也不少。还有问题！
        conntrack默认最长的时间是TCP的establish状态，5天之久，这也太久了，因此就将所有的conntrack超时时间都缩短，最长的时间缩短为120秒，同时将nf_ct_tcp_be_liberal和nf_ct_tcp_loose两个sysctl参数设置为1，撤销TCP的详细语义。

2.一个bugfix

以上代码的hlist_nulls_del_rcu，nf_conntrack_hash_insert等链表操作涉及到了增和删，一定要有锁保护，但是我的代码中没有，这就是一个明显的BUG，因此需要nf_conntrack_lock锁的保护：

if (nf_ct_is_confirmed(ct)) {    struct net *net = nf_ct_net(ct);    spin_lock_bh(&nf_conntrack_lock);    //如果匹配到了新的规则，则更新tuple在chian中的位置。    hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);    hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_REPLY].hnnode);    //如果不进行这个del and reInsert操作，那么就会出现返回包无法被转换    //成原始包的情形！    nf_conntrack_hash_insert(ct);    spin_unlock_bh(&nf_conntrack_lock);...

本来我还想做的更完美一些的，就是说将delete/insert操作全部pending到一个RCU序列里面，因为我怕在delete和insert之间的空隙，同一流的数据包进入协议栈的conntrack_in，发生了find操作，这样就会认为没有找到tuple，进而重建一个NEW状态的conntrack，所以我想用RCU锁进行保护，保证在没有任何执行绪find这个哈希的时候，才进行delete/insert操作，毕竟find操作真的是RCU锁保护着呢！然而很快我就发现自己杞人忧天多此一举了，如果发生上述的情况，新创建的NEW状态的conntrack在离开协议栈的时候是不会被成功confirm的，因为在confirm的时候会进行一次find，如果已经find到了，就DROP！如果进入confirm的时候，find之前，被delete的node还没有insert进去怎么办？如果是我最初的那个版本，就完蛋了，然而刚刚进行了bugfix，不是有nf_conntrack_lock保护吗，所以上面的情况是不会发生的。