1.Linux实现的NAT概述以及问题所在
Linux的NAT基于ip_conntrack。iptables设置的nat规则仅仅对一个流的第一个数据包有效。当然xtables-addons实现的rawnat除外!即便是rawnat,它也必须设置两条规则。真正好的设计是,有个选项可以自定义nat的行为,而不是依赖配置者的能力,否则就可能酿成大祸,在我自身的产品研发以及实施过程中,就曾经碰到了这种情况,同样的用户场景,有些人可以完全HOLD住,有些人则完全不知所措,这正像孬种的语文老师提供给你一本字典,而好的语文老师教你遣词造句一样,经典文章和粗口同样都使用同样的文字!我认为好的设计就应该让人不容易出错,就像对的不那么舍我其谁,起码不会错!关于NAT的Linux实现概览我就不说了(不必了解详情,概览即可),可以看源码,如果这都不知道,就别往下看了。现在试想一个场景:
1).Linux box起初什么NAT都没有配置;
2).Linux box或者后面的机器访问一个server,使用的源地址是内网的不可公网路由的地址;
3).数据正常发出,可是别指望会返回任何东西(除了毫无用处的ICMP!);
4).Linux box的ip_conntrack记录了一个syn_sent状态的conntrack记录,期待返回,并且给与了一个X的过期时间;
5).客户端因为没有得到回复,不断重连,不断touch Linux box那脆弱的syn-sent状态的conntrack记录,导致其永不过期;
6).此时即便设置了iptables的nat规则,由于conntrack不再过期,就永远都匹配不到新建流的第一个数据包;
7).上述的过程僵持了下来,数据访问永远不通!
2.问题分析以及好的设计
看一下上述的过程,其实很简单,只要双方有一方让一点,就解决了,比如客户端在尝试N次重连不成功后,指数退避,那就总能touch到Linunx box的conntrack到最长过期时间,从而解锁,或者反过来,Linux box的conntrack发现已经在一个初始状态停留的总时间超过了一个阀值,那么当即释放,也能解决,然而这也不是好的设计,因为这依赖双方对对方行为的足够理解,需要二者联动!这种思想在以太网以及WIFI的CSMA/CD,CSMA/CA中获得了巨大成功,但是并不能用于第七层的数据通信,因为第七层太乱了!那么怎么办?我认为好的设计应该是算法本身的平滑!Linux在实现NAT的时候其实偷了一个懒,那就是:如果你第一个包没有匹配到NAT规则,则之后的包我会自动帮你创建一个NAT规则,那就是把你NAT成你自身,相当于不NAT,为了代码的统一,给你创造一个NULL NAT!姑且不分析深层次的理论,这种强制行为本身就是不合理的,我现在不NAT并不是我不想,而是根本就没有我想要的规则,即我匹配不上任何规则!但是按照应用程序的逻辑,虽然路不通,我还是要继续尝试,等待我能匹配到的那条规则,在它到来之前,我会一直尝试,也许我也可能自己放弃,但是那也是我的自由!
因此,我做的新版NAT的逻辑就在于,只要数据包没有到达ESTABLISH状态,即它是NEW的话,那么就一直都有NAT的机会,但是如果它收到了返回包,即变成了ESTABLISH状态,那么就不管了(这也是我偷的一个懒,你要知道,一大群女人在家里叽叽喳喳是什么滋味)。
3.对Linux内核代码的修改
也许说得不是很恰当,其实我并不需要修改什么内核,我修改的只是Netfilter代码,曾几何时,Netfilter由于其太过强大,合并到了内核。一共就修改了两个文件,不多,但是很精!我从来不回避大段大段的写代码,但是我觉得那是迫不得已才做的,如果有现成的,直接用就是了,能做到对既有代码最少的修改达到最大的效果也是一种能力,我认为,大段大段地写代码和大段大段地整理数学式子根本就不是档次,后者我是赞同的。代码只是一种想法的实现,你要先有想法,然后再实现,只要你有了想法,发现有人替你实现了,那么就直接用!1).修改$K/net/ipv4/netfilter/nf_nat_rule.c的nf_nat_rule_find函数:
2).修改$K/net/ipv4/netfilter/nf_nat_standalone.c的nf_nat_fn函数
就这样就改完了,这就不是个事儿!但是我的测试程序比较简单,很可能经不起推敲!
4.测试逻辑
1).socket2).reuseaddr
3).bind secondary IP address
4);while true;do connect server; if success;then break;fi; done
5).read and write
在上述第5步期间键入iptables规则,将secondary IP转换成primary IP,结果成功。