如果看一下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，反过来也一样，都是成对出现的，基于这点是否能做点优化呢？
提到了递归查询，不得不多说一点，既然已经引入了SNAT，DNAT标志，那么能否再引入一个 Recursion标志用于指示常规的递归路由呢？我觉得是可以的，这样实现的递归路由更加简单了，一切都在插入时决定，由于NAT是递归的一种，那么可以如下定义：
#define RTN_ RECU RTN_SNAT|RTN_DNAT|RTN_XXX
递归路由的插入算法流程如下：
2.4内核还在的nat route如今不在了，想实现一个还要重新编译内核，不过还好，还是实现了！这种nat route不需要Netfilter支持，不需要在内核中引入其它的map，在非路由查找层面不需要对每一个数据包进行匹配，完全是一条路由表项，可以借助于内核中的各种路由查找算法来优化。不过Cisco的官方CCIE教程中说，使用递归路由查找需要权衡，并且明确指名，递归查询无疑会消耗更多的CPU！
为什么要提到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，反过来也一样，都是成对出现的，基于这点是否能做点优化呢？
提到了递归查询，不得不多说一点，既然已经引入了SNAT，DNAT标志，那么能否再引入一个 Recursion标志用于指示常规的递归路由呢？我觉得是可以的，这样实现的递归路由更加简单了，一切都在插入时决定，由于NAT是递归的一种，那么可以如下定义：
#define RTN_ RECU RTN_SNAT|RTN_DNAT|RTN_XXX
递归路由的插入算法流程如下：
2.4内核还在的nat route如今不在了，想实现一个还要重新编译内核，不过还好，还是实现了！这种nat route不需要Netfilter支持，不需要在内核中引入其它的map，在非路由查找层面不需要对每一个数据包进行匹配，完全是一条路由表项，可以借助于内核中的各种路由查找算法来优化。不过Cisco的官方CCIE教程中说，使用递归路由查找需要权衡，并且明确指名，递归查询无疑会消耗更多的CPU！
然而这个基于递归路由查询实现的NAT是多么的简单又多么的对称，虽然将NAT塞入路由表比较有争议，但是试试看之后，结果还是不错的。Linux本来就是逐渐试出来的，根本就没有什么背后的哲学，和学院派的BSD相比，Linux的特点和优势不就是不拘一格么？
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1268862
