LVS对***服务的负载均衡
之前有一个小需求，需要对已经存在的两台***设备做负载均衡，认证加密方式为PPTP，以为只要想其他应用服务一样只需要针对端口1723进行负载均衡即可，操作之后才发现根本不是一回事。
简单拓扑：
http://s3.运维网.com/wyfs02/M02/53/9D/wKiom1RsQ9PgfAAoAAD6EGgrVBA875.jpg
不适用LVS直接用客户端链接***没有任何问题，但当使用LVS之后，客户端连接时一直停留在认证阶段：
http://s3.运维网.com/wyfs02/M02/53/9D/wKiom1RsRCTikrD5AAA9qLm4_Cg847.jpg
然后出现如下错误：
http://s3.运维网.com/wyfs02/M02/53/9B/wKioL1RsRLLRzd18AAEWa5mhLbs755.jpg
于是抓了下包，才发现原因：
http://s3.运维网.com/wyfs02/M00/53/9D/wKiom1RsRHWDe1upAAa8TPXOi6E234.jpg
图2
http://s3.运维网.com/wyfs02/M00/53/9D/wKiom1RsRRGTITZYAAcFo6BQFOg417.jpg
图2
分析：
LVS属于四层上的负载均衡，因此测试中出现数据交换中断的原因是： client与***服务器之间的数据交换在完成初步的PPTP握手链接之后便不再使用TCP协议，而是使用GRE和PPP协议取而代之，LVS服务器作为中转设备，其不能正常识别并分解此类数据包故不能进行转发，造成client发送的数据在LVS服务器处中断。
结论：
【以PPTP认证协议为例】
初始阶段，即PPTP握手链接阶段的数据包格式如下：
http://s3.运维网.com/wyfs02/M00/53/9B/wKioL1RsRnuz4nHKAABWdLyJ91A648.jpg
握手链接结束之后，便开始PPP的认证链接，此时的数据包以及之后的所有交换的数据包格式如下：
http://s3.运维网.com/wyfs02/M01/53/9B/wKioL1RsRpXRIsYSAABP1ti_5Uk772.jpg
由于LVS是四层上的负载均衡，因此这种方式不能实现对常规***服务进行负载均衡。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
LVS 还有一种判断是否进行数据转发的方式：netfilter标记。
比如： 我们有两个应用：一个是80 一个是443，传统方式会依次添加虚拟主机,例如：
ipvsadm -A -t192.168.5.222:80 -s rr
ipvsadm -A -t192.168.5.222:443 -s rr
然后针对每个虚拟主机添加相应的Real Server
而是用标记的方式似乎会简单一些，我们先是用netfilter对这些数据包进行打标签：
iptables -t mangle -A PREROUTING -p tcp -d 192.168.5.222 --dport 80 -j MARK --set-mark 60
iptables -t mangle -A PREROUTING -p tcp -d 192.168.5.222 --dport 443 -j MARK --set-mark 60
然后添加虚拟主机：
ipvsadm-A -f 60 -s rr
这样就可以了
鉴于以上基础，结合PPTP认证方式，我们似乎可以是用这种LVS的鉴别方式来进行负载均衡，操作如下：
１、首先对相应的数据进行打标签：
iptables -t mangle -A PREROUTING -d 192.168.5.222 -j MARK --set-mark 99
既然pptp认证方式不再使用TCP协议，但ip协议肯定会在，所以直接对发往VIP的数据进行打标签
2、添加虚拟主机和Real Server：
ipvsadm -A -f 99 -s wlc
ipvsadm -A -f 99 -r 192.168.5.248 -g -p 60
举得理论上应该是可以的，但试验了多次还是失败，抓包看了下，发现一直不能进行用户的认证，看来需要对PPTP等一些加密认证的协议多一些了解才行。
页:
[1]