如果你man一下iptables，会发现：
SNAT
This target is only valid in the nat table, in the POSTROUTING chain. ...
然而我认为在INPUT上做SNAT有时还是有必要的。下面说一下原因。
SNAT用于隐藏下行网络，当然，数据已经到达了目的地，也就没有什么好隐藏的了，这是INPUT不做SNAT的原因之一？SNAT的另一个作用就是使上行链路只需要寻址到SNAT后的源地址，而不必为寻址到原始地址而增加路由项，如果数据的上行链路就在本机，那么也没有这个需求，因为管理员可以随意的增加路由项，这难道是INPUT不做SNAT的原因之一？毕竟都是网络层以及以下层的事情，这是网管的职责所在，所有这些需求都可以通过其它配置来解决，因此INPUT上作SNAT没有意义？
可是考虑一下和应用层相关的情况。最简单的例子就是sshd服务器的一个配置：
AllowUsers wangran@192.168.0.0/16
这意味着除了192.168.0.0/16这个网段之外，都无法登录ssh服务器，我们可以在网络层临时开放一个口子出来吗？如果不在INPUT上作SNAT，这个口子很难开，然而如果允许这么做，那么我就可以做如下的rule：
iptables -t nat -A OUTPUT -s 172.16.1.21/32 -p tcp --dport 22 -j SNAT --to-source 192.168.0.111
如此一来172.16.1.21这个特殊的地址也就能登上ssh服务器了，万一这是个临时有特殊权限的地址，一时间又找不到懂得ssh配置的人，网管需要的就是上面的rule。
SNAT
This target is only valid in the nat table, in the POSTROUTING chain. ...
然而我认为在INPUT上做SNAT有时还是有必要的。下面说一下原因。
SNAT用于隐藏下行网络，当然，数据已经到达了目的地，也就没有什么好隐藏的了，这是INPUT不做SNAT的原因之一？SNAT的另一个作用就是使上行链路只需要寻址到SNAT后的源地址，而不必为寻址到原始地址而增加路由项，如果数据的上行链路就在本机，那么也没有这个需求，因为管理员可以随意的增加路由项，这难道是INPUT不做SNAT的原因之一？毕竟都是网络层以及以下层的事情，这是网管的职责所在，所有这些需求都可以通过其它配置来解决，因此INPUT上作SNAT没有意义？
可是考虑一下和应用层相关的情况。最简单的例子就是sshd服务器的一个配置：
AllowUsers wangran@192.168.0.0/16
这意味着除了192.168.0.0/16这个网段之外，都无法登录ssh服务器，我们可以在网络层临时开放一个口子出来吗？如果不在INPUT上作SNAT，这个口子很难开，然而如果允许这么做，那么我就可以做如下的rule：
iptables -t nat -A OUTPUT -s 172.16.1.21/32 -p tcp --dport 22 -j SNAT --to-source 192.168.0.111
如此一来172.16.1.21这个特殊的地址也就能登上ssh服务器了，万一这是个临时有特殊权限的地址，一时间又找不到懂得ssh配置的人，网管需要的就是上面的rule。
这里仅仅用ssh举个例子，实际上网管基本都知道ssh的配置。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1268968
