Re: Postrouting not available in directors ?

Horms <[email protected]>
Newsgroups gmane.linux.highavailability.ultramonkey
Message-ID <[email protected]>
On Tue, Sep 13, 2005 at 11:04:42AM +0200, Yann Dupont wrote:
> Hello all. I'm new on this list and to the wonderful world of ultramonkey.
> I have a question, searched in the archives but didn't find a clear 
> answer (The last topic on the subject is from 2002, I think)
> Hope this is not a FAQ.
> 
> I there a way to use the postrouting nat rule on a director ??

No, I do not believe that this is possible without modifying lvs,
which incidently should be easy enough.

> what I want to do is to dynamically change the source of the packet 
> before it reaches the realserver.
> I use a masquerading topology.
> 
> Long explanation (don't read this if you're not interested)
> 
> I have setup 2 directors ;
> I have thoses services on the director : Webmail, Ldap, imap/pop ... All 
> thoses services are served by 4 realservers:
> 4 for webmail, 4 for ldap, 4 for imap.
> 
> All my realservers have 2 network interface : 1 for the service of 
> requests coming from ultramonkey, with an ip rule where default gw is 
> LVS, 1 for administrative (ssh) and requests to other services provided 
> on my intranet (default rule).
> 
> The problem is coming from the fact that my realservers, are, in 
> reality, vservers (http://linux-vserver.org/), all hosted on 4 physical 
> machines.
> 
> This configuration works very well, except when I re-enter in the 
> ultramonkey.
> 
> Supose this case:
> 
> I have connection to Webmail, which in turn needs to ask an ldap server.
> 
> 1) connection to webmail via ultramonkey, realserver Webmail-A is 
> choosen. connexion go to eth0. (Webmail-A is a vserver on host A). reply 
> go through the LVS. OK.
> 2) webmail-A need to ask the ldap. Request go from eth1, and reach the 
> VIP of the director. OK
> case 3a) director choose Ldap-B or C or D. Ldap request go from eth0 on 
> vserver, and is answerd there, via LVS.  All is fine.
> case 3b) no luck, director choose Ldap-A. Ldap-A is hosted on the same 
> physical server. Ldap-A see packets from Webmail-A to Ldap-A. Ldap-A has 
> a local route (rule 0, local table). He will reply DIRECTLY to 
> Webmail-A, WITHOUT passing by director...
> 
> This is my problem.
> No matter what ip rule I can make, I have NO WAY (well , not found the 
> way) to route back the packet via the director. Ok, the fact that 
> vservers share routing tables with host are directly due to the way 
> linux-vserver works, and this is the source of my problem.
> But I don't know how to resolve this...
> 
> After playing (without much succes) with local tables on host (where 
> realservers lives),I thought the simplest way to achive was to modify 
> the packet on the POSTROUTING side of the director (I need only when the 
> SRC adress of the packet comes from the administrative interface of my 
> realservers). but this don't seems to work
> 
> Quite a bit complicated, I guess...
> 
> Anybody have a slight idea ?

This problem has cropped up a few times recently, and I don't think that
anyone has a good solution. That is, if you have a VIP, then the
real server's servicing that VIP will always connect to themselves
when accessing the VIP.

One way around this, is to have separate VIP's and separate real-servers
for each service. So Webmail-A and Webmail-B would be different machines
to Ldap-A and Ldap-B. With LVS-NAT this works as log as Webmail-X and
Ldab-X are on separate subnets, although they can use the
same linux director. For LVS-DR Webmail-X and Ldab-X can be on the
same subnet and share the same linux director.

If you don't want to add extra machines, you could contrive some setup
that works with virtual machines, like qemu, xen, user-mode linux,
vmware, etc...

-- 
Horms


-- 
Ultra Monkey - http://www.ultramonkey.org/
To UNSUBSCRIBE, email to [email protected], with a body:
unsubscribe ultramonkey-users [email protected]
where "[email protected]" is YOUR email address.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.