Re: exclude named sets

Re: exclude named sets

[Andrew Clark]

Thank you for your answer Kamil!
Under words "not valid" I mean this:

root@anvil:~# /usr/sbin/nft -f /etc/nftables.conf
/etc/nftables.conf:113:48-48: Error: syntax error, unexpected @
                iifname $int_ifs ip daddr != { @stormwall, @akamai }
meta l4proto tcp redirect to :9051
                                               ^
root@anvil:~# vim /etc/nftables.conf
root@anvil:~# /usr/sbin/nft -f /etc/nftables.conf
/etc/nftables.conf:113:49-57: Error: unknown identifier 'stormwall'
                iifname $int_ifs ip daddr != { $stormwall, $akamai }
meta l4proto tcp redirect to :9051
                                                ^^^^^^^^^
Your proposal:

iifname $int_ifs ip daddr != @akamai meta l4proto tcp redirect to :9051

Also does not work.


-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: exclude named sets

[Kamil Jońca]

Andrew Clark <andrewclarkii@gmail.com> writes:

> Thank you for your answer Kamil!
> Under words "not valid" I mean this:
>
> root@anvil:~# /usr/sbin/nft -f /etc/nftables.conf
> /etc/nftables.conf:113:48-48: Error: syntax error, unexpected @
>                 iifname $int_ifs ip daddr != { @stormwall, @akamai }
> meta l4proto tcp redirect to :9051
>                                                ^
And that is what I expected.

> root@anvil:~# vim /etc/nftables.conf
> root@anvil:~# /usr/sbin/nft -f /etc/nftables.conf
> /etc/nftables.conf:113:49-57: Error: unknown identifier 'stormwall'
>                 iifname $int_ifs ip daddr != { $stormwall, $akamai }
> meta l4proto tcp redirect to :9051
>                                                 ^^^^^^^^^
> Your proposal:
>
> iifname $int_ifs ip daddr != @akamai meta l4proto tcp redirect to :9051
>
> Also does not work.
And error message is ... ?
How you define these sets?
by
--8<---------------cut here---------------start------------->8---
define SIMPLE_SET = ...
--8<---------------cut here---------------end--------------->8---
or  as named set?

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: exclude named sets

[Andrew Clark]

Yes they are named sets. I define them like this:

root@anvil:~# grep "include" /etc/nftables.conf
include "/etc/nftables/*.nft"
root@anvil:~# cat /etc/nftables/nftables-stormwall.nft
table ip nat {

        set stormwall {
                type ipv4_addr;
                flags interval;
                auto-merge;
                elements = { 185.121.240.0/22,
        185.121.240.0/24,
        185.121.241.0/24,
        185.121.242.0/24,
        185.121.243.0/24,
        185.71.64.0/24,
        185.71.66.0/24,
        193.84.85.0/24,
        193.84.88.0/24,
        193.84.90.0/24,
        5.252.32.0/24,
        5.252.33.0/24,
        5.252.34.0/24,
        5.252.35.0/24
        }
    }
}
root@anvil:~#

According to nftables wiki
(https://wiki.nftables.org/wiki-nftables/index.php/Sets)
I can do like this:

nft add rule ip filter output ip daddr != @blackhole accept

But, probably not like this
nft add rule ip filter output ip daddr != {@akamai, @stromwall} accept

-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: exclude named sets

[Robert Sander]

Am 20.05.22 um 13:04 schrieb Andrew Clark:

> But, probably not like this
> nft add rule ip filter output ip daddr != {@akamai, @stromwall} accept

In such a scenario I would suggest a new chain from which you return 
with multiple rules in case the IPs match against the sets. The last 
rule of the chain then redirects to the Tor network.

Regards
-- 
Robert Sander
Heinlein Consulting GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-43
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG:
HRB 220009 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin

exclude named sets

[Andrew Clark]

I use Debian 11 as my home router, and I have a script for workaround
blocked addresses. Alas Roskomnadzor lists are getting bigger, so I
came to the simple thought that it would be much easier to route all
traffic in the TOR network, but I have a bunch of addresses which
should be passed directly, without using TOR.

This is valid rule: iifname $int_ifs ip daddr @rkn meta l4proto tcp
redirect to :9051
But this one is not: iifname $int_ifs ip daddr != { @akamai,
@stormwall } meta l4proto tcp redirect to :9051

How to exclude couple of named sets properly?

-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: exclude named sets

[Kamil Jońca]

Andrew Clark <andrewclarkii@gmail.com> writes:

> I use Debian 11 as my home router, and I have a script for workaround
> blocked addresses. Alas Roskomnadzor lists are getting bigger, so I
> came to the simple thought that it would be much easier to route all
> traffic in the TOR network, but I have a bunch of addresses which
> should be passed directly, without using TOR.
>
> This is valid rule: iifname $int_ifs ip daddr @rkn meta l4proto tcp
> redirect to :9051
> But this one is not: iifname $int_ifs ip daddr != { @akamai,
> @stormwall } meta l4proto tcp redirect to :9051

What do you mean "not valid?" You got error, or rule does not work as
expected?


Can you try:

--8<---------------cut here---------------start------------->8---
iifname $int_ifs ip daddr != @akamai meta l4proto tcp redirect to :9051
--8<---------------cut here---------------end--------------->8---
?
I suspect that problem is with "{ @akamai, @stormwall }" construct and not with
exclusion.

>
> How to exclude couple of named sets properly?
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: exclude named sets

[Benno]

Am 20.05.22 um 05:49 schrieb Andrew Clark:
> […] to route all
> traffic in the TOR network, but I have a bunch of addresses which
> should be passed directly, without using TOR.
> 
> This is valid rule: iifname $int_ifs ip daddr @rkn meta l4proto tcp
> redirect to :9051
> But this one is not: iifname $int_ifs ip daddr != { @akamai,
> @stormwall } meta l4proto tcp redirect to :9051
> 
> […]

Would it be sufficient to have only one list and work with the default
package handling? For example a single whitelist causes direct package
routing without Tor. The default rule forwards to the Tor network.

The other way around a blacklist would force packages through Tor while
the rest via default rule goes through!?

Out already pointed out that one rule is the other's negation.

Is there a third route? Or even more?