|
On Wed, 10 Apr 2002, Peter Mueller wrote:
> > b.) my redirect statement on the LVS-director is somehow
> > wrong. here it is..
> > /sbin/ipchains -A input -i eth1:0 -j REDIRECT 81 -s $CORP -d
> > $VIP 80 -p tcp
> >
just guessing here...
If dst_port is changed, does the eventual reply to the client come from
the new port or the original dst_port?
> > Can I solve this problem with packet marking? I have a setup
> > in production (keepalived, mon, transparent redirects on
> > application servers) and I would rather not modify if possible.
>
> I've finally found a bit more about "-j redirect" (in the man page, what a
> concept :P) and I feel pretty confident "b" is the problem. The issue
> appears to be that I'm redirecting to localhost and not the new VIP.
>
> So at this point I have a working solution except redirecting source-known
> IP blocks to VIP:81. I'll email again if I find something. If I don't,
> please help me out iproute2/routing wizards!
hmm. You are using ipchains, are you using a 2.2 kernel? If you're using a
2.4 kernel, all bets are off as to whether a particular ipchains command
will work.
Even if you get it to work with 2.2/ipchains, be aware that if you go to
2.4, transparent proxy in 2.4 works differently than for 2.2. TP still
works for squids, but the rest of the functionality is gone. The writeup
in the HOWTO
http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-16.html#ss16.6
is a bit convoluted as it took a while to figure out what was going on.
It wasn't till I talked to Harald Welte at OLS last year that we found out
why/what had happened. The netfilter people hadn't realised anyone was
using the rest of the functionality.
Joe
--
Joseph Mack, mack@xxxxxxxxxxxx
Linux Virtual Server project
http://www.linuxvirtualserver.org
|
