Linux NAT网络连接权威指南
【1】准备工作，写在前面
1.1)检查服务(cmd>>services.msc,我用的是VM)
附：Netfilter与ip_conntrack
Netfilter
Linux的协议栈仅仅实现了基本的协议操作，对应TCP/IP标准，Linux的协议栈仅仅实现了一个最小集。其余的所有扩展几乎(并非所有!还有一部分由net
schedule实现)均由Netfilter来实现，包括：IP Firewall，IP NAT，IPSec，IPVS等。
ip_conntrack
ip_conntrack是NAT实现的重中之重，Linux的NAT完全依赖ip_conntrack，依附于ip_conntrack之上。
基本数据结构：
值得注意的是，两个方向的五元组节点在confirm之后统一处在一个哈希表中，并不区别对待，只要使用一个五元组作为键查找到不管哪个方向的五元组节点，都可以找到ip_conntrack结构体本身。五元组节点除了包含五元组信息之外，还包含方向信息。
NAT流程
NAT如何依附于ip_conntrack之上的呢?如上图所示，NAT修改了ip_conntrack中的反方向的五元组，对正方向的五元组并没有影响，正是这个特点使得在Linux实现NAT的时候可以使用一种非常巧妙的方法。
NAT的流程如下所示：
注意：由于仅仅一个流的第一个包会创建ip_conntrack结构体，因此也是第一个包会去匹配你用ipptables配置的NAT规则，这是个局限性
实现技巧
在2.6的早期内核中，NAT的数据，包括要转换到的IP地址等数据都是保存在CT的extension中的，叫做ip_nat_info，而该
info可以从CT中取出来，在到达nf_nat_fn的时候执行NAT的时候使用里面的ip_nat_info_manip来做NAT的依据。但是在后期的版本中，使用了一种更加高效得方式，需要转换到的IP地址不再保存在ip_nat_info中，而是直接使用上述流程图中的计算方法得到，即获取反向五元组，取逆，按结果执行。这么做是有依据的，因为在NAT规则匹配成功后，会直接修改掉反方向五元组的tuple，因为NAT规则匹配成功肯定是针对正方向五元组的，毕竟只有第一个包才会去匹配NAT规则，无来怎能有回呢?所以根据NAT规则修改的既然是反方向五元组，那么标准取逆后得到就是NAT后的正方向五元组了，在这个过程中，正方向的五元组一直保存不变!对于反方向回来的包，它的反向就是正方向，由于正方向从来没有被改过，取逆后即成为原始的反方向的五元组，返回包的五元组得以还原!正因为如此，Linux
NAT对方向才如此敏感：匹配规则的正方向的数据包，修改的是反方向的五元组!注意正向，正方向以及反向，反方向并不是同一个意思，正向和反向是针对当前的方向来讲的，正方向和反方向是针对数据流的发起方到接收方的方向来讲的。
可以从这个实现看出Linux内核的发展，在2.6的早期版本中，实际上在NAT规则匹配成功后也是去修改反方向五元组，但是那时怎么就不是通过反向五元组取逆来作为地址转换依据的呢?实际上那时一定可以这么做!事实证明，Linux内核中布满的逐步逐步被认识被发现的技巧。这也正体现了网络社区开发的“90%特性”，即甚至90%的可用性即可，不要求100%的完美。