netdev - Re: Adding SNAT support to LVS/NAT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f4845fc0809131741w15fd73d7w298b7e7c5dd4956a@mail.gmail.com>
Date:	Sun, 14 Sep 2008 02:41:30 +0200
From:	"Julius Volz" <juliusv@...gle.com>
To:	"Graeme Fowler" <graeme@...emef.net>
Cc:	"Joseph Mack NA3T" <jmack@...d.net>, lvs-devel@...r.kernel.org,
	netdev@...r.kernel.org, j.stubbs@...kthink.co.jp
Subject: Re: Adding SNAT support to LVS/NAT

On Sat, Sep 13, 2008 at 8:55 PM, Graeme Fowler <graeme@...emef.net> wrote:
> Hi
>
> On Sat, 2008-09-13 at 11:17 -0700, Joseph Mack NA3T wrote:
>> when we've discussed it before, the packets will appear to
>> come from the DIP, a private IP (or whatever IP the servers
>> were using for their default route before they were put into
>> an LVS).
>
> I'm a bit late to the party, but...
>
> Ideally, the packets would appear to come from the "inside face" of the
> director - usually (and in the most basic case) the NIC with an address
> on the same layer 3 network as the real servers. This way the default
> route would be ignored as there would normally be a more specific route
> for that network, namely straight out of the device the packets arrived
> on. Of course, if that coincides with the default gateway address, it'll
> still work anyway.

Yes. I think this is what I meant in my previous answer to Joe.

>> more importantly, people who are bound by serious IT rules
>> setup by managers, can duplicate their (real) servers only
>> with a change in RIP on each server and can keep the default
>> route.
>
> This is the single most compelling thing about this setup.
>
> It's simultaneously a problem in that for (say) an HTTP server, all the
> requests will appear to be sourced from the director's internal address.
> For many applications this won't be acceptable, not least in that for
> the webserver case log processing will be an irrelevance!
>
> Anyone know how the F5 hardware gets around this? I can't get my hands
> on any to test...

Yes, this is a known issue that is usually handled by injecting
something like an X-User-IP header into the HTTP request. Hard to do
in IPVS (could be done in an app helper though, I assume).

Julius

-- 
Julius Volz - Corporate Operations - SysOps

Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html