先贴图:
这个图用的cisco的路由器。事实结果是不用做snat。
然而lvs的nat 跟这个模型很相似,有人说lvs nat 是多组的dnat,现在我来证实一下
lvs 是否需要开启iptables snat 来帮助realserver 把数据包做转换。
还是lvs自身来转换数据包结构。
实验所需:
lvs配置的关键项我贴出来,我用的keepalived 配置,方便写而且能进行主机存活监测
[root@localhost ~]# cat /proc/sys/net/ipv4/ip_forward 1 [root@localhost ~]# getenforce Disabled #keepalived 配置 [root@localhost ~]# cat /etc/keepalived/keepalived.conf global_defs { notification_email { sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc 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 关闭默认路由。
[root@localhost ~]# 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
会出现一直卡在哪里不动,我们查看
[root@localhost ~]# 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
[root@localhost ~]# 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 很多东西是相通的。