LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Lvs and Trans-Proxy

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Lvs and Trans-Proxy
From: "Bikrant Neupane" <bikrant@xxxxxxxxxxxx>
Date: Fri, 24 Jun 2005 01:58:13 +0545
> On Thu, 23 Jun 2005, Bikrant Neupane wrote:
>
> > I have now removed -j REDIRECT  rule. But now the Director is not
forwarding
> > the packet at all!.
> >
> > However I can see the packet (syn) redirected by cisco to director
hitting
> > the mangle rule.
> >
> > With ip_forward = 0
> > tcpdump in director:
> > 202.79.45.235.2151 > 212.58.240.120.80: S 2729683022:2729683022(0) win
64240
> > <mss 1460,nop,nop,sackOK>
> > 202.79.45.235.2151 > 212.58.240.120.80: S 2729683022:2729683022(0) win
64240
> > <mss 1460,nop,nop,sackOK>
> > 202.79.45.235.2151 > 212.58.240.120.80: S 2729683022:2729683022(0) win
64240
> > <mss 1460,nop,nop,sackOK>
>
> I assume no packets are being accepted?


Packets are not redireced by the director but it does hit the Mangle rule. I
can see that with iptables -nL -t mangle -v: count increases with every
request from the client.


> > with ip_forward = 1 I observerd Hundreds of  syn packets!!
>
> LVS-DR works with ip_forward off. You shouldn't need to turn it on.


Somewhere in HOWTO I read rurning it on/off doesn't affect LVS-DR. I turned
it on just to check but most of the time I turn it off.


> > By looking at the src and dst mac address I found that the packet was
> > looping between the cisco router and the director.
> >
> > 00:80:48:31:86:db  --> Direcor Interface
> > 00:50:3e:f4:6d:e0   --> Cisco Router Interface
> >
> > 22:16:56.653006 00:50:3e:f4:6d:e0 > 00:80:48:31:86:db, ethertype IPv4
> > (0x0800), length 62: IP 202.79.45.235.2155 > 216.239.57.107.80: S
> > 2858487429:2858487429(0) win 64240 <mss 1460,nop,nop,sackOK>
> > 22:16:56.653015 00:80:48:31:86:db > 00:50:3e:f4:6d:e0, ethertype IPv4
> > (0x0800), length 62: IP 202.79.45.235.2155 > 216.239.57.107.80: S
> > 2858487429:2858487429(0) win 64240 <mss 1460,nop,nop,sackOK>
> >
> > How is this possible?? Instead of forwarding packet to Real Server
> > (202.79.45.241) the Director forwarded the packet to Router.
>
> what is the route on the director for packets to the RIP?

 As I said earlier  Director, Real Server and Client are on same subnet. So
the director can reach RIP with broadcast: no intermediate router between
Director and Real Server it is just a L2 switch.

My topology:

   <cisco router>
    202.79.63.230
       |
       |-------------------------|-----------------------|
       |                         |                       |
       |                         |                       |
 eth0: 202.79.63.240    fxp0 202.79.63.241        202.79.63.235
    <Director>           <real server >             <client>
    (gw: cisco)           (gw: cisco)              (gw: cisco)


> Does the ciso have icmp redirects turned off?

I guess it is turned off by default. I haven't touched it.


> Watch out for ciscos
>
>
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html#rout
er_wierdness
>
> it turns out I can't spell "weird". That's really wierd.
>
> > Since the source address is that of the client the route reforwarded the
> > packet to the Director and hece the loop.
>
> Things are starting to come back to me.
>
> Before you can mark the packets you need someway for the director to
> accept packets to 0/0:80. The REDIRECT method doesn't work anymore. Have a
> look at this untested method.

I think packets are accepted by the director otherwise there would have been
no hit to the Mangle rule at all.
It is just that the director is not forwarding packet to the real server
when ip_forward = 0.
It does forward when ip_forward =1 but also modifies the destination ip.

>
>
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.transparent_proxy.htm
l#tp_redirect

I thought TPROXY target was the solution. I downloaded 2.6.10 kernel,
iptables source and tpoxy patch and rebuild the kernel and iptables.
I applied this rule:

iptables -t tproxy -A PREROUTING -j TPROXY -p tcp --dport 80 --on-port 80
and iptables -t tproxy -A PREROUTING -j TPROXY -p tcp  --on-port 80

I can see hit on these rules but having or not having tproxy rule is same. I
could not see any difference at all in the way the director is working.
May be you can suggest me more on using TPROXY target if I am not using it
right way!!

# iptables -nL -t tproxy -v
Chain PREROUTING (policy ACCEPT 1331 packets, 133K bytes)
 pkts bytes target     prot opt in     out     source
destination
   33  1584 TPROXY     tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           [8 bytes of unknown target data]

Chain OUTPUT (policy ACCEPT 3 packets, 216 bytes)
 pkts bytes target     prot opt in     out     source
destination


>
> Julian's way of handling this (see his comment on 7 Jul 2002) is at
>
>
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.routing_to_VIP-less_d
irector.html#routing_and_delivery
>
> You should be able to run his two line command. It's black magic to me.

My topology is quite simple. If the director modifies only the dst-mac in
LVS-DR mode then it should have worked without a trouble since all the hosts
are on same broadcast n/w.

Anyways, I will be trying it again with RedHat 6.2 with 2.2.x kernel. Can i
keep my above topology for 2.2.x kernel?

thanks to every body :)

Bikrant



>
> LVS'ing squids was so simple in 2.2 kernels. I'll have to get
> the HOWTO all straightened out once we figure out what's
> going on here. It would be nice if someone with an
> LVS'ed squid would pop up here and give us the answer.
>
> Joe
>
> --
> Joseph Mack NA3T EME(B,D), FM05lw North Carolina
> jmack (at) wm7d (dot) net - azimuthal equidistant map
> generator at http://www.wm7d.net/azproj.shtml
> Homepage http://www.austintek.com/ It's GNU/Linux!
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.323 / Virus Database: 267.7.10/25 - Release Date: 6/21/2005
>
>


<Prev in Thread] Current Thread [Next in Thread>