So he may not be receiving your reply. Ulrich if you want source nat on your LVS box, you'll have to do:
1) Create a loadbalancer: ipvsadm -A -t 192.168.200.100:443 # add real servers 2) Create the source nat rule for this loadbalancer: iptables -t nat -A POSTROUTING -m ipvs --vaddr 192.168.200.100/32 --vport 443 -j MASQUERADE 3) Set sysctl setting to allow conntrack on vs sysctl net.ipv4.vs.conntrack=1 So it seems what you want is possible and not difficult at all... Regards, Tom On 10/17/2013 02:51 PM, Graeme Fowler wrote: > Hi > > On 17 Oct 2013, at 07:48, "Ulrich Windl" <[email protected]> > wrote: >> I'm not subscribed to the list, so I hope someone will receive it anyway: > Yes we did, but if people reply to the list then you won't see it unless > you're watching an archiver somewhere... > >> I could pretty well use LVS for a load-balance, high-availability scenario >> like distributing SMTP requests to different servers, but the setup seems so >> complicated that I won't do. Reading the documentation, I felt that the NAT >> (masq) mechanism would be the most elegant for my requirements. However as >> it tuned out it did not work (as for many others). The reason is simple: LVS >> rewrites the destination TSAP (IP address and port), but it leaves the >> source TSAP unchanged. So any replies from a real server go to the original >> sender, instead of the LVS host > That's right. In NAT mode, the realservers don't talk directly to anything > but the director. > >> The proposed solution is to set the LVS host as default gateway on any real >> server. This has several problems: >> 1) You create a SPoF on the LVS host >> 2) You create a network bottleneck on the LVS host (_all_ traffic from a >> real goes to the LVS host which must be a router) >> 3) If LVS host and real server are not in the same subnet, you cannot route >> from the real server to the LVS directly >> 4) You cannot have two different LVS hosts that use different services on >> the same real host > That's NAT mode for you. > >> I reall wonder why you don't rewrite the source TSAP (in addition to the >> destination TSAP) as well so that the sender of the packet seems to be the >> LVS host. On a second rewrite the LVS destination TSAP would be rewritten to >> the original requester. I feel this would work like a charm: >> 1) The real server will reply to the LVS host automatically >> 2) Only LVS traffic needs to go through LVS host >> 3) LVS host does not need to be a router (after rewriting the destination, I >> think) >> 4) LVS host and real server can be in different subnets >> 5) You can use one real server from different LVS hosts >> >> Did I overlook something that makes this impossible or impractical? > Yes. You've sort of described both DR and TUN modes here, except for the > source IP being rewritten. LVS/IPVS is *not a proxy*, it's a fancy router. If > you want to do this with source rewriting, use a system such as haproxy. > > NAT mode is most useful where the realservers don't require any special > configuration apart from their default gateway. > > DR and TUN modes require extra configuration on the realservers, but do away > with the SPOF and bottleneck in the director. > > Graeme > _______________________________________________ > Please read the documentation before posting - it's available at: > http://www.linuxvirtualserver.org/ > > LinuxVirtualServer.org mailing list - [email protected] > Send requests to [email protected] > 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 - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
