On 12/02/2020 19:51, ѽ҉ᶬḳ℠ wrote:
On 12/02/2020 19:44, kfm@xxxxxxxxxxxxx wrote:
On 12/02/2020 19:21, ѽ҉ᶬḳ℠ wrote:
On 12/02/2020 19:01, kfm@xxxxxxxxxxxxx wrote:
On 12/02/2020 18:52, ѽ҉ᶬḳ℠ wrote:
On 12/02/2020 18:40, kfm@xxxxxxxxxxxxx wrote:
On 12/02/2020 16:41, ѽ҉ᶬḳ℠ wrote:
Have tried to some online guidance which NFT features require
which kernel config to be set to get them working and whether
jump is among such feature set.
Because hitting:
Error: Could not process rule: Not supported
with:
table inet filter {
chain input { type filter hook input priority 0; iifname
pppoe-wan jump wan_i }
}
As shown, this isn't quite valid nft syntax. Please post a minimal
- but complete - ruleset that reproduces your issue in a form that
is verbatim. Include the wan_i definition, even if it merely an
empty chain.
table inet filter {
chain input { type filter hook input priority 0; iifname
pppoe-wan jump wan_i; }
chain wan_i { type filter hook input priority 0; }
}
You may not jump to the wan_i chain because it is hooked. It makes
as little sense as trying to run iptables -I INPUT -j INPUT.
So jump and goto are only good with non-base chains and those can
only be utilised for:
* nft_immediate: loads an immediate value into a register.
* nft_cmp: compare a given data with data from a given register.
* nft_payload: set/get arbitrary data from packet headers.
* nft_bitwise: perform bit-wise math operations over data in a given
register.
* nft_byteorder: perform byte order operations over data in a given
register.
* nft_counter: a basic counter for packet/bytes that gets incremented
everything is evaluated for a packet.
* nft_meta: set/get packet meta information, such as related
interfaces, timestamps, etc.
* nft_lookup: search for data from a given register (key) into a
dataset. If the set is a map/dictionary, returns the value for
that key.
then, that correct? I had hoped that I could organise the chain
structure for processing into something like WAN, LAN and WAN<>LAN.
The obvious solution is to remove the hook from the wan_i chain. There
is no apparent reason for it to have one. Also, you may find it useful
to jump from your input chain to others by way of a verdict map.
If the hook is removed then packages are not processed in the chain, e.g.
I do not understand what is meant by "not processed". If the packet is
directed to the wan_i chain, then it will be processed there.
table inet filter {
chain input { type filter hook input priority 0;
iifname pppoe-wan jump wan_i; }
chain wan_i { policy drop; ct state 1 drop; ct state
2,4 accept; }
}
which does not help with organising chains in the sense/way I had mind.
Looks like it requires a more circuitous route with more/different
tables and negating interfaces (iif = ! | oik = !) for each such table.
Consider the following ruleset as a possible foundation (formatted to be
somewhat post-friendly).
table ip filter {
chain input {
type filter hook input priority 0; policy drop;
ct state vmap {
established : accept,
related : accept,
invalid : drop,
untracked : drop }
# At this point, the packet can only have a ct state of new
iifname vmap {
"lo" : accept,
"ppoe-wan" : jump wan_i,
"eth0-lan" : jump lan_i }
}
chain wan_i {
tcp dport 22 accept
}
chain lan_i {
accept
}
}
Here, you accept whatever you intend to accept in the wan_i and lan_i
chains. If the packet isn't accepted then it will return to the input
chain and fall through to its drop policy.
There are nuances that could stand to be altered. For example, you might
want to accept lo up front, rather than subject it to the ravages of
connection tracking, and ICMP isn't dealt with in any capacity, which
would become pertinent in an inet table.
Still, from a basic structural standpoint, it's not clear to me why your
ruleset would need to be markedly more circuitous than this.
--
Kerin Millar
