Re: meter in 0.9.1 (nft noob question)

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

 



Laura Garcia wrote:
> On Tue, Aug 6, 2019 at 1:04 PM Trent W. Buck <trentbuck@xxxxxxxxx> wrote:
> >  * The wiki[1] says "the meter keyword is obsolete", but
> >    "man nft" (v0.9.1) and "iptables-translate" (v1.8.3) both still use it.
> >
> >    Is there a way to change a meter rule into a map rule?
> >    I can't work it out.
> >
> >    [1] https://wiki.nftables.org/wiki-nftables/index.php/Meters
> >
>
> I've updated the wiki page with some of your proposals and fixed some commands.

Thanks!

I played with your example.
The "missing ingredient" in my earlier attempts was an explicit "flags dynamic".
Without it the error message is very generic, so I didn't understand what I did wrong:

    # nft --file tmp2.nft
    table ip my_filter_table {
            set my_ssh_meter {
                    type ipv4_addr
                    timeout 1m
            }

            chain my_input_chain {
                    type filter hook input priority filter; policy unknown;
                    meta l4proto tcp tcp dport 22 ct state new add @my_ssh_meter { ip saddr limit rate 10/second } accept
            }
    }
    tmp2.nft:44:9-92: Error: Could not process rule: Invalid argument
            tcp dport 22 ct state new add @my_ssh_meter { ip saddr limit rate 10/second } accept
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It looks like whenever an "old style" rule says

    ... meter foo { ... } ...

that turns into

    set foo { type ...; flags dynamic; }
    ... add @foo { ... } ...

As a bonus, it means that if you then do "nft list ruleset", you can see the current elements:

    # nft list set inet ips_demo baddie_meter
    table inet ips_demo {
            set baddie_meter {
                    type ipv4_addr . ipv4_addr . inet_service
                    size 65535
                    flags dynamic,timeout
                    timeout 1h
                    elements = { 203.7.155.5 . 203.7.155.214 . 22 expires 54m39s624ms limit rate over 1/minute burst 3 packets }
            }
    }

    # nft list set inet ips_demo baddie_list
    table inet ips_demo {
            set baddie_list {
                    type ipv4_addr
                    size 65535
                    timeout 1m
                    elements = { 203.7.155.5 expires 57s160ms }
            }
    }

That's based on this proof-of-concept ruleset:

    http://cyber.com.au/~twb/tmp/nftables-just-ips.nft



I'm still a bit confused, though -- where does the "map" come in?
It looks like basically you've done this (below)?  Why?

     table a {
       chain b {
         … add @my_meter { … } …
       }
    -  set my_meter { type …         ; flags timeout, dynamic; }
    +  map my_meter { type …: counter; flags timeout, dynamic; }
     }

I tried that and works - the ruleset loads, and the lists update as before.
It's still accessed via "nft list set" not "nft list map" - WTF?
Your "nft list map" showed the counter, but mine didn't (see below) – why?

    # nft list set inet ips_demo baddie_meter
    table inet ips_demo {
            map baddie_meter {
                    type ipv4_addr . ipv4_addr . inet_service : counter
                    size 65535
                    flags dynamic,timeout
                    timeout 1h
                    elements = { 203.7.155.5 . 203.7.155.214 . 22 expires 57m1s528ms limit rate over 1/minute burst 3 packets }
            }
    }

    # nft list map inet ips_demo baddie_meter
    Error: No such file or directory
    list map inet ips_demo baddie_meter
                           ^^^^^^^^^^^^



[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