Hi Pablo,
On 26-02-2025 00:47, Pablo Neira Ayuso wrote:
I'm working on finally supporting nftables in Vuurmuur.
In the iptables support, I have special rules per interface to get per iface
packets and bytes. Essentially my tool reads the iptables -vnL output and
parses all the things. When a user applies a ruleset change, Vuurmuur reads
the most current values, constructs a new input file to `iptables-restore`
and loads the rules. This works but is tedious, and also lacks some
precision as we are not counting the packets/bytes while Vuurmuur is
working.
In the nftables support, I'm more or less looking at the same logic. The
ruleset is build as a .nft file that is loaded with `nft -f`.
Now I found the the named counter feature, and also the json output `nft -j
list counters`. This combination seems perfect.
I guess my main question is if we can make these counters persistent
somehow. As part of the ruleset reload, I issue a `flush ruleset`, which
also removes the counters.
So can we make counters survive a `flush ruleset`, or is there a better way
to load a new ruleset?
Would it work for you to destroy all other existing objects (not the
table and counters) instead?
Thanks Pablo. Here's what I'm thinking now:
I create an additional table "vrmr_accounting"
[...]
Then I create regular a regular filter table, where the normal rules are
created. My assumption is that due to the lower priority value the
`vrmr_accounting` table goes first in the processing.
I see, you are using a table that contains rules for metering only.
Do you see disadvantages for this?
In my reload instead of a `flush ruleset`, I do:
# clear existing tables/rules
destroy table ip filter
...
add table ip filter
add chain ip filter INPUT { type filter hook input priority 0; policy drop;
}
add chain ip filter OUTPUT { type filter hook output priority 0; policy
drop; }
add chain ip filter FORWARD { type filter hook forward priority 0; policy
drop; }
Maybe you could use?
flush table ip filter
to leave the table and chain in place. Similar semantics to
iptables -F.
I kind of want to avoid reading which tables and chains already exist,
and craft a .nft file that will do "the right thing" when loaded into a
fresh system or when loaded as a ruleset "reload".
`flush table ip filter` is invalid if `ip filter` doesn't exist yet,
while `destroy table ip filter` works even if `ip filter` doesn't exist.
A create + flush also doesn't work, as create fails if the table already
exists.
So far this is the only scheme I've been able to come up with that
allows me to "blindly" load a rules, so w/o caring about whether the
relevant tables and chain exist or not.
Cheers,
Victor
--
----------------------------------------------
Victor Julien
https://www.inliniac.net/
PGP: https://www.inliniac.net/victorjulien.asc
----------------------------------------------
