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 int
nf_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保护吗，所以上面的情况是不会发生的。