|
Thanks for explaining it Andrew.
My guess is the same -- it's to do with cloud routing/networking, but the
cloud hosting company says that their infrastructure and equipment have no
restrictions in place, and tunneling should work fine.
>> Could you test using a proxy style load balancer? That way, the
>> inbound and reply traffic would all match up nicely. If that works, it
>> would prove that your setup is sound and working and would narrow down
>> the problem to being TUN specific. For a test, HAProxy is a great
>> FLOSS proxy style load balancer.
I just tried HAProxy to load balance to the same real-server, and it works
fine. I don't mind using HAProxy for my requirements, but an LVS tunnel
seemed interesting because the real-server could respond back directly to
the client, bypassing the load balancer.
Cheers,
Nick
On Tue, 31 Mar 2020 at 22:22, Andrew Howe <andrew.howe@xxxxxxxxxxxxxxxx>
wrote:
> Hi Nick,
>
> > There's no firewall in-front of the real server, while I'm testing LVS.
> > There should be router I'm guessing. As this a cloud hosted VM, I checked
> > with the hosting company, and they've confirmed that their network
> > equipment is not configured to drop any packets, and tunneling should
> work
> > fine.
>
> Being in the cloud changes things. Not having access to the underlying
> infrastructure, to make configuration changes and perform
> troubleshooting, may make using LVS/TUN impossible.
>
> Whatever the service provider has sitting at the edge of their/your
> network is surely providing at least a basic level of security. Even
> if there's just a simple router that is tracking connection states at
> the edge it would surely drop the reply traffic from your real server.
>
> Inbound packet:
> Source = Load balancer's public IP address
> Destination = Real server's public IP address
>
> Whatever is sitting at the edge will forward the inbound packet to the
> real server and will start tracking this as a new connection.
>
> Reply traffic:
> Source = VIP address (on the real server)
> Destination = Client's IP address
>
> Whatever is sitting at the edge is unable to match up the reply packet
> with the inbound packet, as the IP addresses are different. The reply
> packet looks like a new, unrelated connection: the response half of a
> connection to a request that hasn't been observed. I think it would
> appear as an unsolicited SYN-ACK and be dropped.
>
> That's my theory, at least.
>
> Could you test using a proxy style load balancer? That way, the
> inbound and reply traffic would all match up nicely. If that works, it
> would prove that your setup is sound and working and would narrow down
> the problem to being TUN specific. For a test, HAProxy is a great
> FLOSS proxy style load balancer.
>
> Thanks,
> Andrew
>
> --
> Andrew Howe
> Loadbalancer.org Ltd.
> www.loadbalancer.org
>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
