Re: named counters vs flush ruleset

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
----------------------------------------------