|
Work, with the PREROUTING method.
sorry don't understand. Are you saying that there won't be a VIP on
the director with ipvs in PREROUTING either? (in which case I'm happy)
Yes, it should also work without a VIP.
you seem to be more interested in transparent proxy and localnode
than most other people on the ml so maybe you have a different
interest in it.
I regard transparent proxy only as a way of avoiding having the VIP
on the director (perhaps it has other virtues I've ignored), which
was pretty neat at the time and I was sorry we lost that capability
with 2.4.x kernels. With ipvs no longer in LOCAL_IN, you don't have
a requirement for the VIP anymore and presumably you wouldn't need
transparent proxy either.
People rarely use localnode. I wouldn't miss it if it didn't exist.
Do you want it for other reasons (eg sorry server)? If for a sorry
server, could we invoke something like Julian's iproute2 trick
that's currently being used to emulate transparent proxy?
Transparent proxying is very important for us because we use IPVS to
cluster application level proxies on firewalls. I.E. we have 2 nodes
and one of the two acts as master/director, balancing traffic between
node 1 (himself, localnode) and node 2 (slave, realnode). We would
like support transparent proxying for squid and let the master/
director node act as the gateway, outgoing web traffic to port 80
balanced over the node and tranparently redirected to port 8080
(squid). Probably it's an unusual setup for IPVS ;)
We could also use tproxy and haproxy, but LVS + keepalived work
together like a charm, so we tried to find a solution with LVS.
what's the localnode + realserver problem with transparent proxy?
It's the NAT problem i've described in the previous mail... if LVS
resides in LOCAL_IN traffic has to be DNATed before LVS comes into
play and the realservers return packets with the wrong/NATed
destination port to the client.
The only negative thing is that traffic can't be filtered in a
regular way,
it would be nice to avoid the collisions with firewall rules that
we have now.
Yes, but i can't find a good solution for that if used together
with transparent proxying, the only one i've found was the
PREROUTING one, any thoughts?
Hmmm, i think i've just understood the solution with FORWARD :) It
should also work with transparent proxies, LVS has to nat the traffic
for the localnode, instead of letting netfilter DNAT/REDIRECT it.
I'll try to put LVS inside the FORWARD chain and see what happens :)
Thanks,
Raphael
--
:: e n d i a n
:: open source - open minds
:: raphael vallazza
:: phone +39 0471 631763 :: fax +39 0471 631764
:: http://www.endian.com :: raphael (AT) endian.com
-
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
