Reputation: 662
I am doing some research with nftables.
I am trying to create a set of IPs that will be either dropped/logged or dropped/accepted.
Why use a set? Because I want to easily add another element, such as {192.168.1.1 . 22 . drop}
, and it will be straightforward via libnft with Python.
I know I can use vamp
to set the drop/accept verdict, like {192.168.1.1 . 22 : drop}
, but I don't see an easy solution to handle both the log and drop case.
My current solution requires two sets: one for handle_input
and one for handle_input_log
. If an IP/port pair requires logging, the same elements go to both sets.
set handle_input {
typeof ip saddr . th dport
flags interval
}
set handle_input_log {
typeof ip saddr . th dport
flags interval
}
This looks redundant because both sets define the same fields and are repeated under the filter hook input
with:
ct state new ip saddr . th dport @handle_input_log log prefix "test comment"
ct state new ip saddr . th dport @handle_input drop
Also, all connections are prefixed with the same comment, which makes it useless.
It would be great to pack everything into one set. The first idea is to expand the set with a log prefix, and if a connection does not require logging, we can omit the prefix:
set handle_input {
typeof ip saddr . th dport . log prefix
flags interval
}
ct state new ip saddr . th dport . log prefix @handle_input_log
But it throws an error:
Error: syntax error, unexpected log
typeof ip saddr . th dport . log prefix
^^^
Or:
Error: syntax error, unexpected prefix
typeof ip saddr . th dport . prefix
^^^^^^
Second idea is to create separate sets but nest one in another but i have no progress on this one.
Perfect solution would work with adding set elements like
{192.168.1.1 . 22 . "drop from mars"}
or map
{192.168.1.1 . 22 . "drop from venus" : drop}
Upvotes: 0
Views: 53