[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter
Subject:    Re: Migrate ipsets to nftables
From:       "" <kfm () plushkava ! net>
Date:       2021-01-21 12:06:38
Message-ID: 43938678-15a5-ac0b-ebab-4b9bd327e225 () plushkava ! net
[Download RAW message or body]

On 21/01/2021 10:18, Nikolai Lusan wrote:
> Hi,
> 
> Basically I have a handfull of custom sets, the small ones are easy
> enough to transition in nft - and they remain fairly static - the
> larger ones (some contain networks, some IPv4/6 hashes) are cumbersome
> at best to re-create ... currently I have been using ipset-save to put
> all the sets into a file which is used to rebuild the sets when needed,
> or on reboot. Some of the larger sets have thousands of IP addresses in
> them, so sticking them in the standard nftables.conf file is unsightly
> and unreadable at best.

Ah, I see. Indeed, I can fully understand the desire not to clutter the 
primary ruleset file with large sets whose contents would normally 
remain out of sight and mind. The following approach is by no means 
perfect but might be acceptable.

   • use "list set" to dump the sets into individual files
   • have nftables.conf import these files with include directives
   • use the -n option in the case of "list ruleset"

Note that the include directive supports simple globbing, so you may do 
such things as include "/etc/nftables.d/*.conf" or include 
"/etc/nftables.d/bogons[46].conf".

In the case of scripts that are used to dynamically create and/or update 
sets, they may execute "list set" commands to re-generate the relevant 
files that are the subject of any include directives. For instance, 
consider the following excerpt from one of my shell scripts.

   # Atomically flush and populate the set, efficiently
   {
     echo "flush set $table $setname"
     echo "add element $table $setname { "
     tr '\n' ',' < "$tmpfile"
     echo " }"
   } | nft -f - || exit

   # Stash the updated set for later inclusion
   nft -s "list set $table $setname" \
     > "/etc/nftables.d/set-$table-$setname.conf"

There are some potential annoyances. In particular, it would be 
necessary to ensure that the OS does not attempt to save the ruleset 
upon stopping the the service that is responsible for ruleset loading 
and persistence. Otherwise, it will flatten the ruleset, losing the 
include directives. The same consideration applies in the case that you 
want to re-generate the primary ruleset file by running "list ruleset" 
manually.

-- 
Kerin Millar
[prev in list] [next in list] [prev in thread] [next in thread]