LVS nat 是否需要借助iptables 的snat实现负载均衡

34tg

先贴图：



这个图用的cisco的路由器。事实结果是不用做snat。

然而lvs的nat 跟这个模型很相似，有人说lvs nat 是多组的dnat，现在我来证实一下
lvs 是否需要开启iptables  snat 来帮助realserver 把数据包做转换。
还是lvs自身来转换数据包结构。


实验所需：



lvs配置的关键项我贴出来，我用的keepalived 配置，方便写而且能进行主机存活监测

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

[iyunv@localhost ~]# cat /proc/sys/net/ipv4/ip_forward 1 [iyunv@localhost ~]# getenforce Disabled #keepalived 配置 [iyunv@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  关闭默认路由。

1 2 3 4 5

[iyunv@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

会出现一直卡在哪里不动，我们查看

1 2 3 4 5 6

[iyunv@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

1 2 3 4 5 6

[iyunv@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抓包分析，看到的数据包

1 2 3 4 5 6 7 8

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

整个数据包流向应该是：

1 2 3 4 5 6 7

数据包一开始是  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 很多东西是相通的。