服务端的问题解决了,客户端呢?因为客户端要连接同一个服务端,因此使用bridge就不太好,毕竟普通网桥对于一个目的地有一个学习的过程,学习完成后,就会仅放开一个端口而阻塞别的,达不到负载均衡的目的,也就无法使用多处理器,另外使用bonding由于配置过于复杂,效果也不明显,也只好作罢。我的方式是使用“基于数据包的路由负载均衡”来实现,怎么实现呢?当然是使用万能的iptables了,这里使用了iptables的u32这个match,使用IP数据报的ID字段来做均衡字段,凡是奇数的定为一类,偶数的定为另一类,配置如下:
-A PREROUTING -d 10.8.0.1/32 -m u32 --u32 0x2&0xffff&0x1=0x1 -j MARK --set-xmark 0xc8/0xffffffff
-A PREROUTING -d 10.8.0.1/32 -m u32 --u32 0x2&0xffff&0x1=0x0 -j MARK --set-xmark 0x64/0xffffffff
然后导出一个策略路由表即可
0: from all lookup local
32763: from all fwmark 0xc8 lookup ***1
32764: from all fwmark 0x64 lookup ***2
32766: from all lookup main
32767: from all lookup default
假设启动了两个Open×××客户端进程,希望流量在此二进程搞流量均衡,那就配置下面的策略路由
10.8.0.1 dev tap0 scope link
10.8.0.1 dev tap1 scope link
以上额外配置的Open×××客户端配置文件为以下:
daemon ×××C
script-security 2
dev tap
client
proto udp
explicit-exit-notify
# 听取python前端的建议
;remote 127.0.0.1 6119
tls-exit
resolv-retry infinite
nobind
float
ca CA.cer
verb 4
pkcs12 B.pfx
结合《 桥接多进程Open×××虚拟网卡解决多处理问题》,Open×××在多处理器上的问题就解决了。
-A PREROUTING -d 10.8.0.1/32 -m u32 --u32 0x2&0xffff&0x1=0x1 -j MARK --set-xmark 0xc8/0xffffffff
-A PREROUTING -d 10.8.0.1/32 -m u32 --u32 0x2&0xffff&0x1=0x0 -j MARK --set-xmark 0x64/0xffffffff
然后导出一个策略路由表即可
0: from all lookup local
32763: from all fwmark 0xc8 lookup ***1
32764: from all fwmark 0x64 lookup ***2
32766: from all lookup main
32767: from all lookup default
假设启动了两个Open×××客户端进程,希望流量在此二进程搞流量均衡,那就配置下面的策略路由
10.8.0.1 dev tap0 scope link
10.8.0.1 dev tap1 scope link
以上额外配置的Open×××客户端配置文件为以下:
daemon ×××C
script-security 2
dev tap
client
proto udp
explicit-exit-notify
# 听取python前端的建议
;remote 127.0.0.1 6119
tls-exit
resolv-retry infinite
nobind
float
ca CA.cer
verb 4
pkcs12 B.pfx
结合《 桥接多进程Open×××虚拟网卡解决多处理问题》,Open×××在多处理器上的问题就解决了。
转载于:https://blog.51cto.com/dog250/1268922
本文详细介绍了如何利用iptables的u32匹配功能,通过IP数据报的ID字段进行负载均衡,实现Open×××在多处理器环境下的流量均衡。文中还涉及到Open×××客户端配置、策略路由设置以及多进程虚拟网卡的使用,最终解决了多处理器环境下Open×××的问题。
2106

被折叠的 条评论
为什么被折叠?



