LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Obstacle with direct routing

To: linux-virtualserver@xxxxxxxxxxxx
Subject: Obstacle with direct routing
From: Lars Marowsky-Bree <lmb@xxxxxxxxx>
Date: Tue, 29 Jun 1999 10:53:05 +0200
Good morning,

I found the following obstacle when playing around with direct routing mode.

Imagine the servers A and B behind the loadbalancer C, which is also the
gateway / firewall for those two. (Maybe doing NAT for non-virtualserver
traffic etc)

On C, the address 1.1.1.1:80 is bound and direct-routed to A:80 / B:80.
Appears to work fine, no?

No. Since C has the address 1.1.1.1 bound, it will not route traffic comeing
in from A / B with src adr 1.1.1.1. The check is in net/ipv4/fib_frontend.c,
fib_validate_source() and is meant to protect against spoofing attacks.

I realize that direct routing is specified with an additional gateway out of
the network for the hosts, but I mainly wanted to get rid of the masquerading
overhead.

So, I think we have three options:

1. Either point this out in the documentation and say that "this is the way it
is" and disallow my configuration. (I am not too fond of this;)

2. Modify fib_validate_source() to not log these packets as martians.

3. Make "direct routing" work in a transparent proxy kind of way which does
not require a locally configured IP alias.

Number 1 seems like burying our heads in the sand. Number 3 has a problem if
the virtual address comes from the external subnet of the loadbalancer or even
if we want to use the external address of the load balancer itself!

Anyone feels up to 2. ? I could take the full check out myself, but I think it
would be cleaner to add logic to allow src addresses which are to be expected
by the vs code.

Sincerely,
    Lars Marowsky-Brée
        
--
Lars Marowsky-Brée
Network Management

teuto.net Netzdienste GmbH - DPN Verbund-Partner

<Prev in Thread] Current Thread [Next in Thread>
  • Obstacle with direct routing, Lars Marowsky-Bree <=