And then ALL traffic would have been routed through this connection. But then I’d have to fiddle with gateway settings every time that I want to use this “sticky” connection. I thought about adding a third NIC in the ZS box, which would have been statically routed to use a specific connection. Well, that would work but doesn’t it nullify the point of having a load balancer 😕 Except in that case that connections are spread evenly on 0.0.0.0-255.255.255.255 range. I hope that we can figure out how to make routing decisions for destinations “sticky” which would solve this problem for everyone without resorting to this type of hack. One half he always routes through one interface, the other half through the other. In another thread ppalias said he used a set of NetBalance rules to basically divide the IP address range into two halves when considering HTTP/S connections. I hope that we can figure out how to make routing decisions for destinations “sticky” which would solve this problem for everyone without resorting to this type of wrote: (5/16s of the traffic on two interfaces and 6/16s of the traffic on the third).Īssuming that the HTTPS and HTTP servers are in the same general part of the IP address range, what ever route is picked for your HTTPS session would be the same route for the HTTP session. (I hope I have those subnet ranges close.)Īnyway that would roughly spread your HTTP/S traffic equally among the three interfaces based on the destination address. But maybe dividing things like this might work: You have three interfaces which does not work into powers of two very well.
Yup you are right, I had some issues with OpenVPN with the static routes, so I created 2 pairs of Netbalancer rules for the destination ports 80 and 443 for the 0.0.0.0/1 and destination 128.0.0.0/1.Īs long as the rules for HTTP are the same as for HTTPS then the site would see the same IP from you for both protocols. One half he always routes through one interface, the other half through the wrote:
0 kommentar(er)
