On 26/09/2020 21:07, Pablo Neira Ayuso wrote:
On Sat, Sep 26, 2020 at 06:44:00PM +0000, ѽ҉ᶬḳ℠ wrote:
On 26/09/2020 20:21, Pablo Neira Ayuso wrote:
On Fri, Sep 25, 2020 at 07:10:00PM +0000, ѽ҉ᶬḳ℠ wrote:
Been trying to concatenate sets update:
tcp dport @b_t update @b_sa4 { ip saddr } drop;
tcp dport @b_t update @b_sa6 { ip6 saddr } drop;
with:
tcp dport @b_t update @b_sa4 . @b_sa4 { ip saddr . ip6 saddr } drop;
What's the intention here?
but that did not work out. Is somehow possible to concatenate sets update?
Yes, you can do:
tcp dport @b_t update @b_sa4 { ip saddr . ip6 saddr } drop
You can update one single set at a time. Not sure what you expect from
this concatenating sets instead of keys.
The two mentioned sets are dynamic, learning ip | ip6 saddrs from hits on
tcp dport.
The intended concatenation was to put it into one rule instead of two, like
if ip saddr then update element in set @b_sa4 and if ip6 saddr then update
element in set @b_sa6 respectively.
So you would like to consolidate:
tcp dport @b_t update @b_sa4 { ip saddr } drop
tcp dport @b_t update @b_sa6 { ip6 saddr } drop
In one single rule?
Something like (hypothetical syntax)
tcp dport @b_t update @b_sa { inet saddr } drop
where b_sa is a set with something like type inet_addr.
In a way yes, though this would consolidate also ip and ip6 into the
same set and could make viewing (a large) set it bit cumbersome, unless
there was an optional view filter something like
nft list set [family] [table] filter [set] ( optional [ip] | [ip6] )