On 12/02/2020 20:57, kfm@xxxxxxxxxxxxx wrote:
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
The current kernel deployed, which kconf is beyond my control, is
missing the flag to support sets and thus vmap. But that aside something
like this seems to work
table inet filter {
chain input { type filter hook input priority 0;
policy drop; iifname pppoe-wan jump wan_i; }
chain wan_i { ip saddr 0.0.0.0/32 udp sport 67 ip
daddr 255.255.255.255/32 udp dport 68 accept; }
}
