keepalived vip ping不通_【干货分享】OpenStack LVS负载均衡为什么不通？

背

景

介

绍

OpenStack环境Neutron 的安全组会向虚拟机默认添加 anti-spoof 的规则，将保证虚拟机只能发出／接收以本机Port为原地址或目的地址(IP、MAC)的流量，提高了云的安全性。但是LVS等需要绑定VIP的场景，默认流量是被拦截的。需要做allow pairs设置才能放通流量。

业务拓扑

● Director Server分发器

VIP：xx.xx.xx.241

内网IP 主xx.xx.xx.5

备xx.xx.xx.7

Keepalived配置文件路径 /etc/keepalived/keepalived.conf

● 真实服务器RS关闭ARP，并添加lo:0 IP为VIP

内网(专网)IP xx.xx.xx.8 xx.xx.xx.10

xx.xx.xx.11 xx.xx.xx.13

以上六台虚拟机都对VIP做过allowed_address_pairs(仅对VIP做的，后面会详述)。

问题现象

配置了LVS的DR模式，配置完成后Client ping VIP可以通，但是发送HTTP请求，没有反应。抓包发现，Director收到了Client的报文，但是RS没有收到HTTP请求，只有VRRP报文。

排除过程

4.1怀疑是LVS配置问题

Client能ping通VIP，CURL VIP没响应，LVS 处在SYN_RECV状态，抓包发现，LB端有进来的VIP报文，RS没有。问题应该是LB端发不出去，或RS收不到报文。

结果

反复检查keepalived和RS配置，没有问题。同样的配置在非openstack上跑，可以跑通。排除配置问题。

4.2 怀疑是宿主机防火墙问题

4.2.1 怀疑是宿主机本地防火墙规则问题

在查看宿主机防火墙cat /etc/sysconfig/firewalld的时候，发现有一条规则影响业务，注掉并重启防火墙就可以跑通业务。

重启宿主机iptables后：

结果

其实并不是这个问题，是重启防火墙之后，启用了本地防火墙规则，把原先Neutron的防火墙规则冲掉了，iptables几乎都空了，所以业务感觉通了。等Neutron同步规则后，还是会不通。

4.2.2怀疑是虚机防火墙问题

一开始出现不通的时候， iptables -F清空虚机里面的iptables规则，发现并没有实质作用

还是必须重启宿主机的iptables。

虚机iptables规则：

结果

其实虚机的iptables已经几乎没有规则了，也并没有影响业务的条目。重启宿主机iptables通，实则还是上一个问题，把宿主机本地Neutron的iptables规则给冲了。

4.2.3怀疑是Neutron安全组问题

后期排查主要是在Neutron安全组方向。必现的场景是，在删除增加后端或者重启Neutron-openvswitch-agent的时候，业务就不通了。

● 尝试分别对LVS节点(xx.xx.xx.5、xx.xx.xx.7)和RS节点(xx.xx.xx.8、xx.xx.xx.10、xx.xx.xx.11、xx.xx.xx.13)做了allow_pairs，但是业务不通。

Dump宿主机防火墙的时候，发现如下规则：

这些条目出现的原因是对Port和VIP做了allow_pairs绑定。会生成对应条目的iptables。由Chain ID追溯，是Neutron-openvswi-FORWARD规则，属于虚机Port转发链规则，问题应该就是出在这边。

● 尝试对LVS的Port加了80端口的放通规则后，业务通了：

结果

确实是安全组导致iptables把流量给drop了，有多个办法可以规避这个问题：

● 在iptables对应子链加规则放行。但是在界面更新或’neutron-openvswitch-agent’重启的时候，Neutron重新下发规则，会刷掉本地手动加的规则，不可以完全保证业务不通。

● 把端口的port-curity-enable设置成false，但是安全组不再生效

● 写脚本探测iptables重载，再添加规则。但是规则没有添加的瞬间，也会出现业务短时间断的情况。

● 在’neutron-openvswitch-agent’里添加规则放行，但是需要修改Agent，太麻烦。

● 在安全组设置这个规则，但是没找到相应的入口。

解决方案

5.1 LVS DR模式模型原理

DR模式的工作过程

● Client 发送Request包到LB服务器的VIP上

● 负载均衡服务器根据VIP选择对应的RS。然后修改报文目的MAC为RS的MAC地址，将Client的请求发给RS

● 被选择的RS把应答包直接传给Client

5.2 问题根本原因

上面的DR模式过程可以看出，LVS转发过程中不修改IP，只修改DST MAC，Source IP没变。而由上面的截图可以看出，allow_pairs在iptables里是用一组IP和MAC的组合规则来放通流量。所以只绑定VIP为allow_pairs，实际是VIP和自己网卡的MAC的规则，而目的MAC在经过LVS的时候已经被修改成后端MAC了，流量自然就过不去。而VRRP报文能出去的原因是IP和MAC都是本机的，在iptables里。

5.3 解决办法

● 负载均衡器设置

1. 一种办法，因为Client的CIP是任意的，负载均衡器需要转发Source IP为CIP的报文，所以可以让allow_pairs绑定IP为0.0.0.0/0，让所有的IP可以从Director出去。原理是放开了基于本机MAC的所有IP报文。如：neutron port-update port_id --allowed-address-pairs type=dict list=true ip_address=0.0.0.0/02. 另一种办法，负载均衡器修改的目的MAC是后端服务器的，可以把后端服务器的MAC都加到allow_pairs。如果MAC不确定的情况，直接设成0:0:0:0:0:0，放开所有的MAC。如：neutron port-update port_id --allowed-address-pairs type=dict list=true ip_address=$VIP mac_address=$RSMAC● 后端设置因为RS需要转发Source IP为VIP的报文，所以应该对RS对应PORT 做放开VIP的allow_pairs。如：neutron port-update port_id --allowed-address-pairs type=dict list=true ip_address=$VIP

添加后的iptables会出现如下的规则：

问题解决

5.4 可能出现的安全问题

因为上述规则实际上是放开了对应虚机的流量限制，DR模式可以让任意IP或者MAC能访问VIP，流量从LVS节点透传过来，这个对虚机和应用的安全性会有一定的隐患，这里有几条安全建议：

1.搭建前端硬件防火墙

2.虚机操作日志记录，权限管理

3.虚机安装安全软件

4.虚机arp_announce设置成2(总是使用最合适的网卡来响应)

5.虚机iptables设置，只允许VRRP和对应TCP+PORT的规则

6.更换NAT/TUNNEL/FULLNAT，可以做内外网隔离的模式

总结

LVS的特点是需要在Port添加VIP，内部去进行地址的转换，再发给后端。单纯在iptables层去修改问题，还是会被Neutron刷新。可以在安全组里面去修改，也可以在Neutron命令行设置，才能保证设置持久化，不会出现iptables被刷新的问题。

OpenStack的网络环境iptables规则比较复杂，出现问题的时候，应该在iptables找到自己的IP:Port，NIC Dev ID, 子Chain ID，向上追溯属于哪条链、哪个表，再结合网络拓扑和业务场景去规划和设置确定问题在哪。

单纯考虑到VIP是不够的。类似问题解决办法不是一成不变的，除了刚才提到的，还有多种办法，可以关闭Port安全组，也可以在安全组添加条目，或者修改agent代码关闭Port的firewall或者添加accept条目等等，方法有很多，需要权衡利弊根据需求选择。

End

往期推荐

【干货分享】| 深度解析python之生成器

【干货分享】| 大云弹性计算产品BC-EC全面支持跨版本升级

【干货分享】| 为啥热迁移总是断网呢？