LVS nat 是否需要借助iptables 的snat实现负载均衡
先贴图：http://s3.运维网.com/wyfs02/M01/71/63/wKioL1XNqkfRseXAAADBVngbyOg956.jpg
这个图用的cisco的路由器。事实结果是不用做snat。
然而lvs的nat 跟这个模型很相似，有人说lvs nat 是多组的dnat，现在我来证实一下
lvs 是否需要开启iptablessnat 来帮助realserver 把数据包做转换。
还是lvs自身来转换数据包结构。
实验所需：
http://s3.运维网.com/wyfs02/M01/71/66/wKiom1XNnm-z7HL8AACf9X1U3ZA388.jpg
lvs配置的关键项我贴出来，我用的keepalived 配置，方便写而且能进行主机存活监测
# cat /proc/sys/net/ipv4/ip_forward
1
# getenforce
Disabled
#keepalived 配置
# 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
}
}
}
上述配置很简单，下面开始验证。
第一步：在web1web2关闭默认路由。
# 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
会出现一直卡在哪里不动，我们查看
# ipvsadm -lnc
IPVS connection entries
pro expire state source virtual destination
TCP 00:55SYN_RECV 192.168.2.18:57706 192.168.2.180:80 192.168.156.128:80
TCP 00:52NONE 192.168.2.18:0 192.168.2.180:80 192.168.156.128:80
TCP 00:55SYN_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.182vip 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
# 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 , 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 , 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 , 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 , 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 很多东西是相通的。
页:
[1]