Hi Victor,
On Sun, Feb 09, 2025 at 11:58:56AM +0100, Victor Julien wrote:
> On 08-02-2025 22:49, Pablo Neira Ayuso wrote:
> > On Sat, Feb 08, 2025 at 03:35:27PM +0100, Victor Julien wrote:
> > > Hi all,
> > >
> > > 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"
>
> table ip vrmr_accounting {
> counter vrmr_enp1s0 {
> packets 17546 bytes 3901328
> }
>
> chain INPUT {
> type filter hook input priority -100; policy accept;
> iifname "enp1s0" counter name "vrmr_enp1s0" comment
> "lan-nic"
> }
>
> chain OUTPUT {
> type filter hook output priority dstnat; policy accept;
> oifname "enp1s0" counter name "vrmr_enp1s0"
> }
>
> chain FORWARD {
> type filter hook forward priority -100; policy accept;
> iifname "enp1s0" counter name "vrmr_enp1s0"
> oifname "enp1s0" counter name "vrmr_enp1s0"
> }
> }
>
> 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.
> 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.
> ...
> # clear accounting chains (incl rules), but not the counter itself
> add table ip vrmr_accounting
> destroy chain ip vrmr_accounting INPUT
> destroy chain ip vrmr_accounting OUTPUT
> destroy chain ip vrmr_accounting FORWARD
> add chain ip vrmr_accounting INPUT { type filter hook input priority -100;
> policy accept; }
> add chain ip vrmr_accounting OUTPUT { type filter hook output priority -100;
> policy accept; }
> add chain ip vrmr_accounting FORWARD { type filter hook forward priority
> -100; policy accept; }
> ...
> add counter ip vrmr_accounting vrmr_enp1s0
> add rule ip vrmr_accounting INPUT iifname "enp1s0" counter name vrmr_enp1s0
> comment lan-nic
> ...
>
> This appears to leave the counters intact.
>
> Does this make sense to you?
I wonder if you could consolidate all in one single table:
flush table ip filter
leaves table, chain and counters intact.
