|
>>> Tom van Leeuwen <tom.van.leeuwen@xxxxxxxxxxxxx> schrieb am 17.10.2013 um
>>> 15:22
in Nachricht <525FE48C.4080506@xxxxxxxxxxxxx>:
> 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" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
> 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 - 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
|
