>>> Tom van Leeuwen <[email protected]> schrieb am 17.10.2013 um >>> 15:22 in Nachricht <[email protected]>: > So he may not be receiving your reply. > > Ulrich if you want source nat on your LVS box, you'll have to do:
Hi Tom, I really appreciate your help, but... > > 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 Unfortunately this does not work: iptables v1.4.6: Couldn't load match `ipvs':/usr/lib64/xtables/libipt_ipvs.so: cannot open shared object file: No such file or directory # ls /usr/lib64/xtables libip6t_HL.so libipt_icmp.so libxt_hashlimit.so libip6t_LOG.so libipt_realm.so libxt_helper.so libip6t_REJECT.so libipt_set.so libxt_iprange.so libip6t_ah.so libipt_ttl.so libxt_length.so libip6t_dst.so libipt_unclean.so libxt_limit.so libip6t_eui64.so libxt_AUDIT.so libxt_mac.so libip6t_frag.so libxt_CLASSIFY.so libxt_mark.so libip6t_hbh.so libxt_CONNMARK.so libxt_multiport.so libip6t_hl.so libxt_CONNSECMARK.so libxt_osf.so libip6t_icmp6.so libxt_DSCP.so libxt_owner.so libip6t_ipv6header.so libxt_MARK.so libxt_physdev.so libip6t_mh.so libxt_NFLOG.so libxt_pkttype.so libip6t_rt.so libxt_NFQUEUE.so libxt_policy.so libipt_CLUSTERIP.so libxt_NOTRACK.so libxt_quota.so libipt_DNAT.so libxt_RATEEST.so libxt_rateest.so libipt_ECN.so libxt_SECMARK.so libxt_recent.so libipt_LOG.so libxt_TCPMSS.so libxt_sctp.so libipt_MASQUERADE.so libxt_TCPOPTSTRIP.so libxt_socket.so libipt_MIRROR.so libxt_TOS.so libxt_standard.so libipt_NETMAP.so libxt_TPROXY.so libxt_state.so libipt_REDIRECT.so libxt_TRACE.so libxt_statistic.so libipt_REJECT.so libxt_cluster.so libxt_string.so libipt_SAME.so libxt_comment.so libxt_tcp.so libipt_SET.so libxt_connbytes.so libxt_tcpmss.so libipt_SNAT.so libxt_connlimit.so libxt_time.so libipt_TTL.so libxt_connmark.so libxt_tos.so libipt_ULOG.so libxt_conntrack.so libxt_u32.so libipt_addrtype.so libxt_dccp.so libxt_udp.so libipt_ah.so libxt_dscp.so libipt_ecn.so libxt_esp.so > > 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... With SLES11 SP2 it seems a bit more difficult ;-) Regards, Ulrich > > 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
