Thanks Pablo, Do you want me to send the updated patchset with your adjustments incorporated? Mikhail On Thu, 22 Oct 2020 at 14:37, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Thu, Oct 22, 2020 at 02:36:47PM +0200, Pablo Neira Ayuso wrote: > > 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. > > Attaching the revisited patch 6/8 to this email. > > > 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.
