mdash;》包离开防火墙,到达web服务器.——》web服务器试图回复这个包. 来自同一个网络的一台机子,它会把回复包直接发送到请求包的源地址也就是 192.168.10.7.——》回复包到达C客户机,但C它会很困惑, 这个包不是来自它请求的那台防火墙.这样,它就会把这个包扔掉而去继续等待 “真正”的回复包. 这就是问题所在~~
针对这个问题有两个解决办法:
第一、
这些包都要进入防火墙, 它们都去往需要做DNAT才能到达的那个地址, 我们只要对这些包做SNAT操作即可.
比如,我们来考虑上面的例子,如果对那些进入防火墙 是去往地址为web IP、端口为80的包做SNAT操作,那么这些包就好象是从LAN_IP来的了,也就是说,这些包的源地址被改为LAN_IP了.
这样,web服务器就会把回复包发给防火墙,而防火墙会再对包做 Un-DNAT操作,并把包发送到客户机.
解决问题的规则如下:
iptables -t nat -A POSTROUTING -p tcp -d 192.168.10.8 --dport 80 -j SNAT --to-source 192.168.10.1
要记住,按运行的顺序POSTROUTING链是所有链中 一个,因此包到达这条链时,已经被做过DNAT操作了, 我们在规则里要基于内网的地址web_IP(包的目的地)来匹配包.
警告:我们刚才写的这条规则会对日志产生很大影响,这种影响应该说是很不好的. 来自 Internet包在防火墙内先后经过了DNAT和SNAT处理,才能到达web服务器(上面的例子), web服务器就认为包是防火墙发来的,而不知道真正的源头是其他的IP.这样,当它记录服务情况时,所有访问记录的源地址都是防火墙的IP而不是真正的访问源.
我们如果想根据这些记录来了解访问情况就不可能了.因此上面提供的“简单办法”并不是一个明智的选择,但它确实可以解决“能够访问”的问题,只是没有考虑到日志而已.
其他的服务也有类似的问题.比如,你在LAN内建立了SMTP服务器,那你就要设置防火墙以便能转发SMTP的数据流.这样你就创建了一个开放的SMTP中继服务器,随之而来的就是日志的问题了. 一定要注意,这里所说的问题是针对没有建立DMZ或类似结构的网络,并且内网的用户访问的是服务器的外网地址而言的.
(译者注: 如果建立了DMZ,或者服务器和客户机又被分在不同的子网里,那就不需要这么麻烦了. 所有访问的源头都不在服务器所在的网里, 就没必要做SNAT去改变包的源地址了,从而记录也就不是问题了.如果内网客户是直接访问服务器的内网地址那就更没事了)
第二、>>>>阅读全文 本文出自 “网人linux社区” 博客,请务必保留此出处http://netren.blog.51cto.com/3240427/592171
|