From: Jason Stubbs <jasonbstubbs@gmail.com>
To: Joseph Mack NA3T <jmack@wm7d.net>
Cc: LVS Devel <lvs-devel@vger.kernel.org>
Subject: Re: moving ipvs() to POST/PREROUTING
Date: Sat, 12 Apr 2008 09:06:09 +0900 [thread overview]
Message-ID: <200804120906.09863.jasonbstubbs@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0804110908240.13199@wm7d.net>
On Saturday 12 April 2008 01:14:08 JST, Joseph Mack NA3T wrote:
> On Sat, 12 Apr 2008, Jason Stubbs wrote:
> >> I would hope people don't do this. RIPs should be private,
> >> for security reasons and to preserve the fiction that the
> >> LVS setup is one machine.
> >
> > This is precisely why I chose the hooks that I did. My intention was for
> > the netfilter chains to only ever see the VIP, but packets with the RIP
> > are going through too after IP_VS_XMIT is called.
>
> hmm. still don't know what you're referring to then. Is this
> LVS-NAT, LVS-DR...?
>
> netfilter sees the source and dest on the packets. How can
> netfilter only see the VIP?
Current LVS-NAT goes something like:
PREROUTING client => VIP
LOCAL_IN client => VIP
LVS in hook
LOCAL_OUT client => RIP
POSTROUTING client => RIP
With my patch it goes like:
PREROUTING client => VIP
FORWARD client => VIP
POSTROUTING client => VIP
LVS hook
POSTROUTING client => RIP
LVS-DR is pretty much the same flow except that the packet's MAC destination
is changed instead. What I mean with netfilter only seeing the VIP is that
I'd like the second POSTROUTING run that happens with my patch to not happen.
Doing so makes rule writing on the director a little easier as the rules
don't need to know about the RIPs at all.
The configuration I'm planning to use is a LVS-NAT director/firewall that
allows external traffic to VIPs, SNATs traffic from RIPs to external
(including to VIPs) and drops everything else.
With LVS-DR, I am pretty sure that all the issues mentioned in the page you
linked to still apply as my patch only changes the flow through the director.
The rules mentioned in the following link would be needed whether the
SERVER_GW is separate device to the director or not.
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.non-lvs_clients_on_realservers.html#3-tier_routes
--
Jason Stubbs
next prev parent reply other threads:[~2008-04-12 0:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-11 5:00 moving ipvs() to POST/PREROUTING Jason Stubbs
2008-04-11 12:37 ` Joseph Mack NA3T
2008-04-11 13:13 ` Jason Stubbs
2008-04-11 14:38 ` Joseph Mack NA3T
2008-04-11 15:15 ` Jason Stubbs
2008-04-11 16:14 ` Joseph Mack NA3T
2008-04-12 0:06 ` Jason Stubbs [this message]
2008-04-12 0:46 ` Joseph Mack NA3T
2008-04-12 9:07 ` Julian Anastasov
2008-04-12 12:59 ` Jason Stubbs
2008-04-14 11:04 ` Jason Stubbs
2008-04-14 23:16 ` Julian Anastasov
2008-04-15 7:17 ` Jason Stubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200804120906.09863.jasonbstubbs@gmail.com \
--to=jasonbstubbs@gmail.com \
--cc=jmack@wm7d.net \
--cc=lvs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.