From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Mikhail Sennikovsky <mikhail.sennikovskii@cloud.ionos.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 6/8] conntrack: implement options output format
Date: Thu, 22 Oct 2020 14:36:47 +0200 [thread overview]
Message-ID: <20201022123647.GA15948@salvia> (raw)
In-Reply-To: <20200925124919.9389-7-mikhail.sennikovskii@cloud.ionos.com>
Hi Mikhail,
Thanks for your patchset.
On Fri, Sep 25, 2020 at 02:49:17PM +0200, Mikhail Sennikovsky wrote:
> As a counterpart to the "conntrack: accept parameters from stdin"
> commit, this commit allows dumping conntrack entries in the format
> used by the conntrack parameters.
> This is useful for transfering a large set of ct entries between
> hosts or between different ct zones in an efficient way.
>
> To enable the "options" output the "-o opts" parameter needs to be
> passed to the "contnrack -L" tool invocation.
I started slightly revisiting this 6/8 patch a bit (please find it
enclosed to this email), I have rename -o opts to -o save, to get this
aligned with iptables-save.
I have also added a check for -o xml,save , to reject this
combination.
I have extended it to display -I, -U, -D in the conntrack events.
I have removed several safety runtime checks, that can be done at
registration time (make sure the option description is well-formed
from there, otherwise rise an error message to spot buggy protocol
extensions).
This patch should also be extended to support for other existing
output flags combinations. Or just bail out if they are specified.
At this point I have concerns with NAT: I don't see how this can work
as is. There is also a conntrack helpers that might trigger NAT
sequence adjustments, this information would be lost.
We would need to expose all these details through the -o save, see
below. For some of this, there is no options from command line,
because it made no sense to expose them.
We have to discuss this before deciding where to go. See below for
details.
> To demonstrate the overall idea of the options output format works
> in conjunction with the "stdin parameter"s mode,
> the following command will copy all ct entries from one ct zone
> to another.
>
> conntrack -L -w 15 -o opts | sed 's/-w 15/-w 9915/g' | conntrack -I -
For zone updates in the same host, probably conntrack can be extended
to support for:
conntrack -U --zone 15 --set-zone 9915
If --set-zone is specified, then --zone is used a filter.
Then, for "zone transfers" *between hosts*, a different way to address
this is to extend conntrackd.
The idea is:
1) Add new "transfer" mode which does _not_ subscribe to
conntrack events, it needs to register a new struct ct_mode
(currently there is "sync" and "stats" ct_modes).
2) Add a new message type to request a zone transfer, e.g.
conntrackd --from 192.168.10.20 --zone 15 --set-zone 9915
This will make your local daemon send a request to the conntrackd
instance running on host 192.168.10.20 to retrieve zone 1200. The
remote conntrackd instance dumps the existing conntrack table from
kernel and sends it to you.
You can reuse the channel infrastructure to establish communications
between conntrackd instances in the new "transfer mode". You can
also reuse the sync protocol, see network.h, build.c and parse.c,
which takes a conntrack object and it translates it to network
message.
Note that the struct internal_handler actually refers to the
netlink handler for this new struct ct_mode that you would be
registering.
Let me know, thanks.
next prev parent reply other threads:[~2020-10-22 12:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 12:49 [PATCH 0/8] Fast bulk transfers of large sets of ct entries Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 1/8] tests: icmp entry create/delete Mikhail Sennikovsky
2020-10-13 18:28 ` Pablo Neira Ayuso
2020-09-25 12:49 ` [PATCH 2/8] conntrack: fix icmp entry creation Mikhail Sennikovsky
2020-10-13 18:29 ` Pablo Neira Ayuso
2020-09-25 12:49 ` [PATCH 3/8] conntrack: accept parameters from stdin Mikhail Sennikovsky
2020-11-04 13:56 ` Pablo Neira Ayuso
2020-09-25 12:49 ` [PATCH 4/8] conntrack.8: man update for stdin params support Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 5/8] tests: conntrack parameters from stdin Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 6/8] conntrack: implement options output format Mikhail Sennikovsky
2020-10-22 12:36 ` Pablo Neira Ayuso [this message]
2020-10-22 12:37 ` Pablo Neira Ayuso
2020-10-23 11:07 ` Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 7/8] conntrack.8: man update for opts format support Mikhail Sennikovsky
2020-09-25 12:49 ` [PATCH 8/8] tests: dumping ct entries in opts format Mikhail Sennikovsky
2020-09-25 13:28 ` [PATCH 0/8] Fast bulk transfers of large sets of ct entries Florian Westphal
2020-09-26 18:19 ` Pablo Neira Ayuso
2020-09-29 11:20 ` [PATCH 0/2] conntrack: -L/-D both ipv4/6 if no family is given Mikhail Sennikovsky
2020-09-29 11:20 ` [PATCH 1/2] " Mikhail Sennikovsky
2020-09-29 11:20 ` [PATCH 2/2] tests: conntrack -L/-D ip family filtering Mikhail Sennikovsky
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=20201022123647.GA15948@salvia \
--to=pablo@netfilter.org \
--cc=mikhail.sennikovskii@cloud.ionos.com \
--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).