又一个Linux的双向stateless NAT


如果看一下iproute2的help,就会发现在route section中有一个nat action,其中via的参数给出了转换的地址。具体的配置就不说了,只提出两点,第一,iproute2的stateless nat需要policy routing的参与,第二,它在2.6内核中被去除了;具体信息可以参见文档。在2.6内核中,内核协议栈将一切的扩展都留给了Netfilter来实现,自己只实现标准的最小集。

为什么要提到2.4内核的nat route呢?既然已经被扫除了,既然在Netfilter中实现NAT具有哲学意义,既然我自己也基于Netfilter实现了一个双向的stateless nat(见  ),那旧事重提又有什么意义呢?我对老婆说,我说出的任何话,做出的任何事,背后都有一套可以自圆其说的理论,不管它多么荒谬,但是可以自圆!因此我现在又想实现一个stateless nat时,也需要一个理论支撑,就是:将NAT塞入路由表中是合理的,因为NAT受影响的就是路由(不管是本地路由还是远程的路由),直接在路由中做掉会更好。由于PRE/POST-ROUTING的中间点就是路由,何不把NAT统一合并在路由中来呢?虽然这不太符合Netfilter的哲学,然而对于实用主义来说,这太好不过了!2.4内核实现的nat route之所以不好,除了哲学原因之外还有代码的原因,那段实现代码太乱了!

如果按照上述的思路来实现nat route,根本不用policy routing,不需要配置ip rule,不需要配置两条规则,它的流程图如下,代码也比较好修改:

可以看出,这个实现使用了递归路由查询这个Linux根本就没有实现的东西。因此需要修改路由插入的部分代码,而我使用了几个flag来识别该条路由是做NAT用的,由于是stateless的双向NAT,因此当你插入一条NAT路由的时候,另外一个方向的就必须自动生成,比如你插入了一条以下的路由:

ip route add dnat x via y

指示所有的目标是x的都要转换成y,那么以下的路由必须自动生成:

ip route add snat y via x

指示所有源地址为y的都要转换为x。当然以下的这一条不应该手工配置,应该用auto标号指名它是自动生成的。

以上的需要说明是snat,原则上snat是在路由之后进行的,否则可能会做无用功,那流程图为何在路由前snat呢?这是为了最小化查询,否则也会做很多无用的查询,将要对所有的数据包都进行是否需要snat的查询,这里用到的一个技巧就是路由查询是基于最长前缀匹配的,如果有需要snat的,那么肯定会有一条明细的32位前缀的snat路由,如果没有,那就说明没有需要snat的。当然上面的流程图还可以优化,因为我们认识到,由于是双向的nat,那么只要有一个dnat,就会有一个snat,反过来也一样,都是成对出现的,基于这点是否能做点优化呢?

  • 1
  • 2
  • 下一页

相关内容