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.
