From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 2/2] Handle the routing changes in the MASQUERADE target
Date: Fri, 16 Nov 2012 11:09:14 +0100 [thread overview]
Message-ID: <20121116100914.GB25964@1984> (raw)
In-Reply-To: <alpine.DEB.2.00.1211151532500.7485@blackhole.kfki.hu>
Hi Jozsef,
On Thu, Nov 15, 2012 at 03:42:14PM +0100, Jozsef Kadlecsik wrote:
> On Thu, 15 Nov 2012, Pablo Neira Ayuso wrote:
>
> > Two comments on this patch:
> >
> > On Tue, Nov 13, 2012 at 09:17:37PM +0100, Jozsef Kadlecsik wrote:
> > > When the routing changes, MASQUERADE should delete the conntrack
> > > entries where the source NATed address changes due to the routing
> > > change. As a first approximation, delete all entries which are
> > > marked with the new "--route-dependent" flag of the MASQUERADE
> > > target.
> > >
> > > Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
> > > ---
> > > include/uapi/linux/netfilter/nf_conntrack_common.h | 4 ++
> > > include/uapi/linux/netfilter/nf_nat.h | 1 +
> > > net/ipv4/netfilter/ipt_MASQUERADE.c | 40 ++++++++++++++++++++
> > > 3 files changed, 45 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/include/uapi/linux/netfilter/nf_conntrack_common.h b/include/uapi/linux/netfilter/nf_conntrack_common.h
> > > index 1644cdd..1c698b5 100644
> > > --- a/include/uapi/linux/netfilter/nf_conntrack_common.h
> > > +++ b/include/uapi/linux/netfilter/nf_conntrack_common.h
> > > @@ -87,6 +87,10 @@ enum ip_conntrack_status {
> > > /* Conntrack got a helper explicitly attached via CT target. */
> > > IPS_HELPER_BIT = 13,
> > > IPS_HELPER = (1 << IPS_HELPER_BIT),
> > > +
> > > + /* Conntrack must be deleted when routing changed (NAT) */
> > > + IPS_ROUTING_DEPENDENT_BIT = 14,
> > > + IPS_ROUTING_DEPENDENT = (1 << IPS_ROUTING_DEPENDENT_BIT),
> >
> > This seems to me a bit too specific for the masquerade module. I've
> > been checking the struct nf_conn_nat to squash that information there,
> > but I don't find the way to make it without increasing the length of
> > the NAT area.
>
> I know, we waste a status bit. But I couldn't find a better way to store
> the information in conntrack.
>
> > > };
> > >
> > > /* Connection tracking event types */
> > > diff --git a/include/uapi/linux/netfilter/nf_nat.h b/include/uapi/linux/netfilter/nf_nat.h
> > > index bf0cc37..a0dfac7 100644
> > > --- a/include/uapi/linux/netfilter/nf_nat.h
> > > +++ b/include/uapi/linux/netfilter/nf_nat.h
> > > @@ -8,6 +8,7 @@
> > > #define NF_NAT_RANGE_PROTO_SPECIFIED 2
> > > #define NF_NAT_RANGE_PROTO_RANDOM 4
> > > #define NF_NAT_RANGE_PERSISTENT 8
> > > +#define NF_NAT_ROUTING_DEPENDENT 16
> > >
> > > struct nf_nat_ipv4_range {
> > > unsigned int flags;
> > > diff --git a/net/ipv4/netfilter/ipt_MASQUERADE.c b/net/ipv4/netfilter/ipt_MASQUERADE.c
> > > index 5d5d4d1..ecf3063 100644
> > > --- a/net/ipv4/netfilter/ipt_MASQUERADE.c
> > > +++ b/net/ipv4/netfilter/ipt_MASQUERADE.c
> >
> > We now have IPv6 NAT support, so I guess you need to patch
> > /net/ipv6/netfilter/ip6t_MASQUERADE.c
>
> Ohh, yes, I missed that. I'll add the required code there.
>
> Currently I'm trying to find a way to purge just the entries which are
> affected by the routing change (for example when there are muliple VPN
> tunnels). However that requires a new conntrack extension and it's
> nontrivial (at least for me) to figure out the required data from struct
> fib_info.
>
> If the conntrack extension is used then of course the status bit is not
> required.
We can register now variable length conntrack extensions. I think we
can use that feature to extend nf_conn_nat to allocate extra
information for all working modes of MASQUERADE. It may require
changing the nf_nat_setup_info interface to pass some new flags.
Regarding the variable length conntrack extensions, please check
nf_ct_ext_add_length in net/netfilter/nf_conntrack_helper.c for
instance.
next prev parent reply other threads:[~2012-11-16 10:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 20:17 [PATCH 0/2] [RFC] Get MASQUERADE target to handle routing changes Jozsef Kadlecsik
2012-11-13 20:17 ` [PATCH 1/2] Introduce notification chain for " Jozsef Kadlecsik
2012-11-13 22:15 ` David Miller
2012-11-14 7:57 ` Jozsef Kadlecsik
2012-11-13 20:17 ` [PATCH 2/2] Handle the routing changes in the MASQUERADE target Jozsef Kadlecsik
2012-11-13 23:49 ` Jan Engelhardt
2012-11-14 7:55 ` Jozsef Kadlecsik
2012-11-15 11:44 ` Pablo Neira Ayuso
2012-11-15 14:42 ` Jozsef Kadlecsik
2012-11-16 10:09 ` Pablo Neira Ayuso [this message]
2012-11-16 21:38 ` Jozsef Kadlecsik
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=20121116100914.GB25964@1984 \
--to=pablo@netfilter.org \
--cc=kadlec@blackhole.kfki.hu \
--cc=netfilter-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).