|
"Ian C. Sison" wrote:
>
OK I don't really know what I'm doing here. I'll make
some guesses and hopefully I don't
lead you too far astray. Maybe someone else can fix you up.
> >> LVS is configured as the default route of a terminal server.
> >> Naturally, LVS should implement transparent proxying via:
do you know that transparent proxy for 2.4 kernels is different
to TP for 2.2 kernels and the 2.4TP is incompatible with LVS?
(It still works for squids, the main target TP, but they removed
the functionality we needed). If you want the gory details start at
http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-16.html#ss16.4
I'm not sure that the director needs TP anyhow to forward packets
for squids. I think you just need regular forwarding. For a start
you can just setup a regular port 80 forwarding LVS using rr.
You can change to dh once you have it running. I expect the squids just
look like regular port 80 realservers, except they answer to all IPs.
>---- ipvsadm ------------------------------------
> -A -f 3 -s dh
> -a -f 3 -r 192.168.254.1:80 -g -w 1
> -a -f 3 -r 192.168.254.2:80 -g -w 1
> -a -f 3 -r 192.168.254.3:80 -g -w 1
> -a -f 3 -r 192.168.254.4:80 -g -w 1
> -A -t 202.181.160.12:80 -s dh
> -a -t 202.181.160.12:80 -r 192.168.254.1:80 -g -w 1
> -a -t 202.181.160.12:80 -r 192.168.254.2:80 -g -w 1
> -a -t 202.181.160.12:80 -r 192.168.254.3:80 -g -w 1
> -a -t 202.181.160.12:80 -r 192.168.254.4:80 -g -w 1
> ---- ipvsadm ------------------------------------
I can't see that the last 5 lines are getting you anything.
You have already marked all packets to port 80 arriving
on the director - these marked packets will be intercepted
by the first rule.
> And true enough, if i:
>
> telnet SQUID1 80, i get the response of the squid server.
> telnet LVS 80, i get the response of one of the squid servers.
>
> However if i pass a packet through LVS from another box who's default
> gateway is the LVS box, i get a:
>
> IPVS connection entries
> pro expire state source virtual destination
> TCP 00:57.49 SYN_RECV 202.181.160.6:32782 202.181.160.11:80
> 192.168.254.1:80
>
> and it just stops there, at SYN_RECV.
no idea why telnet goes and the other client doesn't. sorry
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
