Re: Migrate ipsets to nftables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux