先贴图：
这个图用的cisco的路由器。事实结果是不用做snat。
然而lvs的nat 跟这个模型很相似，有人说lvs nat 是多组的dnat，现在我来证实一下
lvs 是否需要开启iptables snat 来帮助realserver 把数据包做转换。
还是lvs自身来转换数据包结构。
实验所需：
lvs配置的关键项我贴出来，我用的keepalived 配置，方便写而且能进行主机存活监测
[[email protected] ~]# cat /proc/sys/net/ipv4/ip_forward
1
[[email protected] ~]# getenforce
Disabled
#keepalived 配置
[[email protected] ~]# cat /etc/keepalived/keepalived.conf
global_defs {
notification_email {
[email protected]
}
notification_email_from [email protected]
router_id LVS_DEVEL
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.2.180
}
}
virtual_server 192.168.2.180 80 {
delay_loop 6
lb_algo rr
lb_kind NAT
nat_mask 255.255.255.0
persistence_timeout 5
protocol TCP
real_server 192.168.156.128 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.156.130 80 {
weight 10
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
上述配置很简单，下面开始验证。
第一步：在web1 web2 关闭默认路由。
[[email protected] ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.156.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1002 0 0 eth0
lvs主机的iptable 规则设置空的（即不开启snat）或者关闭iptables。
用浏览器访问 http://192.168.2.180
会出现一直卡在哪里不动，我们查看
[[email protected] ~]# ipvsadm -lnc IPVS connection entries pro expire state source virtual destination TCP 00:55 SYN_RECV 192.168.2.18:57706 192.168.2.180:80 192.168.156.128:80 TCP 00:52 NONE 192.168.2.18:0 192.168.2.180:80 192.168.156.128:80 TCP 00:55 SYN_RECV 192.168.2.18:57707 192.168.2.180:80 192.168.156.128:80
了解tcp三次握手的同学都知道，这个处于recv的阶段，是destination 没有回复，所以处于这个状态。
我们分析一下数据包的流向。
pc 192.168.2.18
lvs 192.168.2.182 vip 192.168.2.180
realserver 192.168.156.128
数据包开始是 sip:192.168.2.18 dip:192.168.2.180
到达lvs ，lvs 发现是请求的vip，然后按照规则把数据包转换为 sip:192.168.2.18 dip:192.168.156.128
然后readserver 接收到数据包 解封装。最后处理完成，重新把包发回去，此时数据包结构是sip:192.168.156.128 dip:192.168.2.18.问题来了，此时我们的路由表（见上面的route），表项没有到192.168.2.0网段的路由，这时候数据包会发布出去，直接丢弃的。所以出现了 SYN_RECV.
那么我们如果把这个包送能到lvs，是否可以正常访问呢？下面来验证
第二步：在web 1 web2 开启默认路由，路由默认网关指向lvs内网口192.168.156.148；
注意此时lvs 还是没有开启iptables snat
[[email protected] ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.156.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1002 0 0 eth0 default 192.168.156.148 0.0.0.0 UG 0 0 0 eth0
这个时候，还是上述过程到realserver 回数据包的时候，sip:192.168.156.128 dip:192.168.2.18
此时路由表项有默认路由，会直接把这个数据包丢给192.168.156.148（lvs）。
用浏览器访问 http://192.168.2.180
发现此时可以正常访问网站了。
在web1抓包分析，看到的数据包
15:27:31.154624 IP 192.168.2.18.56784 > 192.168.156.128.http: Flags [.], ack 1, win 16425, length 0 15:27:31.156401 IP 192.168.2.18.56784 > 192.168.156.128.http: Flags [P.], seq 1:458, ack 1, win 16425, length 457 15:27:31.156478 IP 192.168.156.128.http > 192.168.2.18.56784: Flags [.], ack 458, win 490, length 0 15:27:31.157290 IP 192.168.156.128.http > 192.168.2.18.56784: Flags [P.], seq 1:149, ack 458, win 490, length 148 15:27:31.157415 IP 192.168.156.128.http > 192.168.2.18.56784: Flags [F.], seq 149, ack 458, win 490, length 0 15:27:31.157832 IP 192.168.2.18.56784 > 192.168.156.128.http: Flags [.], ack 150, win 16388, length 0 15:27:31.158295 IP 192.168.2.18.56784 > 192.168.156.128.http: Flags [F.], seq 458, ack 150, win 16388, length 0 15:27:31.158311 IP 192.168.156.128.http > 192.168.2.18.56784: Flags [.], ack 459, win 490, length 0
整个数据包流向应该是：
数据包一开始是 sip:192.168.2.18 dip:192.168.2.180 到达lvs ，lvs 发现是请求的vip，然后按照规则把数据包转换为 sip:192.168.2.18 dip:192.168.156.128 然 后readserver 接收到数据包 解封装。最后处理完成，重新把包发回去，此时数据包结构是sip:192.168.156.128 dip:192.168.2.18. 数据包到lvs后lvs 把数据包修改为sip:192.168.2.180 dip:192.168.2.18 此时客户机会接受这个数据包的。因为请求数据包ip是对的。
但此时lvs没有开启snat的，也就是这个数据包的转换，不需要借助iptables的，而是lvs自己本身完成的。类似于多组的dnat。
个人总结：很多论坛的资料都是个人观点，缺乏严谨性。cisco和linux 很多东西是相通的。