|
Hi Joe, folks,
On Tue, 11 Jan 2000, Joseph Mack wrote:
>
> I'm trying to figure out the kernel transparent proxy and am about
> to start putting printk statements into the code. Before I did I thought
> I'd see if I had my assumptions right.
>
> With VS-DR, if you run this script on a realserver which doesn't have the
> VIP
>
> VIP=192.168.1.110
> PORT=80
> /sbin/ipchains -A input -j REDIRECT $PORT -d $VIP $PORT -p tcp
>
> then a packet with dst=VIP:PORT which arrives on the realserver (from the
> director) will be processed locally (ie on the realserver).
Yes.
>
> My understanding of tcpip is this...
>
> Without the REDIRECT and without the VIP on the realserver, a packet with
> src=CIP,dst=VIP will be seen as destined for another machine and will be
> forwarded according to the routing table.
Yes.
>
> With a (non-arping) VIP on the realserver, the tcpip layer will recognise
> that the packet should be processed locally. The body of the packet will
> be recovered, the src/dst saved to make the reply packet and the body of
> the packet along with the port and IP sent to the socket layer. (The IP
> information must be sent too, I imagine, as some demons eg httpd, must
> send back a different reply for each IP on a multi-homed machine).
>
> With the above REDIRECT and no VIP on the realserver, the instructions to
> forward the packet are bypassed and the packet is processed locally.
> Presumably the dst=VIP is saved for the reply. If the body is sent to an
> httpd, what IP must the httpd be listening on for it to accept the
> packet - 127.0.0.1, the VIP? (I can check this myself in a minute).
It must listen to 0.0.0.0 or to VIP. For the software it
seems that this IP is local. But there is some services which
can make big troubles. They get the list of all local IP addresses
from the kernel and bind to them. But with transparent proxy the VIP
is not in this list!
>
> I was wondering if it would be possible to adapt Horms' REDIRECT for
> VS-Tun to bypass the arp problem. With 2.0.36 kernels on the realserver
> and an LVS running VS-Tun, the VIP can be on a lo:0 (or dummy0) device. I
> presume this works because the incoming packet is recognised as being of
> type IPIP and is decapsulated and it doesn't matter whether the packet
> arrives on a tunl, dummy or lo device. With 2.2.x kernels the VIP must be
> on a tunl (and not lo or dummy) device for VS-Tun to work. I don't know
> why IPIP packets are treated differently in 2.0.36 and 2.2.x kernels.
Is it required that VIP must be configured on tunl0 ? Why?
May be the LVS documentation is incorrect too?
You can try this setup for the real server:
- eth0 - REALIP
- tunl0 - REALIP or another UNIQ IP
- Transparent proxy for VIP
The setup in the Director is same:
- eth0 - DIP
- eth0:0 - VIP
- VS/TUN -> REALIP
The requirement is that the real server must accept
connections destined for VIP. This is true when:
- VIP is local IP address (configured on any interface)
- VIP is not local IP but we use Transparent proxy solution to
accept connections. Very good solution!
So, we must test these two variants for VS/TUN (we know that
TRANSPARENT PROXY is working perfectly with VS/DR):
1> With local VIP
1.1> VIP on tunl0 interface, sorry, we can serve only
one VIP
eth0 - REALIP
tunl0 - VIP, ARP problem => tunl0/hidden=1 (2.2.14)
1.2> We can serve many VIPs on 'lo' aliases or dummy
devices
eth0 - REALIP
tunl0 - REALIP
lo:*/dummy* - VIP, ARP problem => lo/hidden=1 (2.2.14)
Is this variant working? Can someone test it and
we can change the docs too.
I.e. the VS/TUN redirection for VIP to
REALIP?
2> No local VIP, use transparent proxy
eth0 - REALIP
tunl0 - REALIP
-d VIP -j REDIRECT
Again, not tested.
For security reasons it is recommended that:
- all/rp_filter=1
- tunl0/rp_filter=1
>
> I tried Horms' REDIRECT method with VS-Tun on a 2.2.x realserver and as I
> expected it didn't work. Presumably the REDIRECT has to send the packet to
> a tunl device for VS-Tun to work (any other way of getting an IPIP packet
> processed?). That would mean another IP on the realserver (different IP to
> the VIP so it can be an arping tunl device). This would mean that the
> kernel transparent proxy code would have to be modified to change the IP
> of the packet. I don't know enough to know wether this would work, as the
> correct src/dst have to be saved for the reply packet.
>
Sorry, can't test it. Please someone to try the above
setup, i.e. tunl0 configured with REALIP and with transparent proxy.
What about tunl0 configured with 0.0.0.0 ?
So, I expect your comments about the above setups for VS/TUN.
Regards,
Julian Anastasov
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
