|
On Sun, Sep 14, 2008 at 04:47:51PM +0200, Julius Volz wrote:
> On Sun, Sep 14, 2008 at 12:39 PM, Julius Volz <juliusv@xxxxxxxxxx> wrote:
> > On Sun, Sep 14, 2008 at 3:37 AM, Joseph Mack NA3T <jmack@xxxxxxxx> wrote:
> >> On Sun, 14 Sep 2008, Julius Volz wrote:
> >>
> >>> So maybe it would already work? ;)
> >>
> >> No. Some highly motivated people tried doing SNAT on OUTPUT in an attempt
> >> to
> >> do F5-SNAT and it didn't work. This lead to the write up in
> >>
> >> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.non-modified_realservers.html#F5_snat
> >>
> >> which brings us to where we are now.
> >
> > Thanks for the info! Right, I even said myself in the previous reply
> > that ip_vs_postrouting() stops further processing in the POSTROUTING
> > chain, so it never reaches netfilter NAT code.
>
> Actually, what if we modify or remove that function to allow further
> processing in POSTROUTING? Could SNAT work with IPVS then?
>
> The comment above it says that the function specifically wants to
> avoid further NAT by netfilter. But is this always a problem?
Well, it would be a problem if it gets DNATed a second time.
But perhaps we can take a slightly different approach such that
we protect against DNAT while allowing SNAT.
Perhaps it might just be easier to allow iptables to explictly match
packets that have been mangled by LVS-NAT. Perhaps by poviding
a match rule for skb->ipvs_property? Or by using Siim Põder's match
against connections in the LVS connection table.
http://lists.graemef.net/pipermail/lvs-users/2008-July/021081.html
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
