|
> > 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?
the original. I don't really want to change ports and do all this funky
stuff, but unfortunately I couldn't think of any other hack that would do
the job. In this case the job was to shovel off packets destined for the
VIP to a non-LVS machine without having it go through a new VIP (port 81).
> > 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 Idon'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.
2.2. I'd definitely be putzing around with iptables on this project if I
could.
>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
Last night I was trying some interesting things like ipmasqadm portfw
commands. Unfortunately I didn't get any further. :(
/sbin/ipchains -A input -i eth1 -j REDIRECT 81 -s $CLIENT -d $VIP 80 -p tcp
/usr/sbin/ipmasqadm portfw -a -P tcp -L 127.0.0.1 81 -R VIP 81
I did notice that -i in the first rule must be eth1 and not eth1:0. If this
is not the case, packets don't ever seem to be seen by the rule. (this can
be observed via ipchains -L -nv).
thanks,
Peter
|
