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: <Pine.LNX.4.64.0809131100320.20936@wm7d.net>
Date:	Sat, 13 Sep 2008 11:17:33 -0700 (PDT)
From:	Joseph Mack NA3T <jmack@...d.net>
To:	Julius Volz <juliusv@...gle.com>
cc:	lvs-devel@...r.kernel.org, netdev@...r.kernel.org,
	j.stubbs@...kthink.co.jp
Subject: Re: Adding SNAT support to LVS/NAT

On Sat, 13 Sep 2008, Julius Volz wrote:

> Hi,
>
> I'm wondering about how hard it would be to add SNAT 
> support to IPVS (that is, the director rewriting packets 
> from the client to backends to appear to be from the VIP 
> and some randomly allocated port).

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).

> This would allow us to have remote real servers with 
> LVS/NAT.

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.

> I realize that Jason Stubb's PRE/POSTROUTING patches would 
> also make this possible, but they seemed risky and we 
> haven't heard of them in a long time.

Jason just sent me his current patch this week. You could 
ask him for it directly. Apparently it's little/no different 
to the patch he posted at

http://archive.linuxvirtualserver.org/html/lvs-devel/2008-04/msg00041.html

(hope I'm paraphrasing Horms correctly here...)
Horms would be happy to have this in the main release if it 
could be invoked as an option.

> Also, having this option directly integrated into the rest 
> of the IPVS NAT code might make it easier to use: just add 
> another flag on the ipvsadm command line when you want 
> SNAT for an LVS/NAT backend.

sounds great to me.

>From talking to Horms, LVS-NAT (and possibly LVS-DR) sends 
the packets to the realservers via

ip_vs_post_routing()

which bypasses the OUTPUT chain. It would seem to me that if 
you instead injected the packets into the OUTPUT chain, then 
normal iptables rules could handle the SNAT to the 
realservers. It might be slower that rewriting the packets 
yourself, but for a first attempt, I think people will be so 
happy to have the functionality that they won't quibble 
about speed.

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!
--
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