Dňa 26. augusta 2024 23:55:20 UTC používateľ "Atkins, Brian" <Brian.Atkins@xxxxxxxxxx> napísal:
OK, thus in our topic, the chain is in mean of chain with hook defined,
nested chains (jump/goto, without hook) ends whole chain.
>If, say, you had a table of type ip, and another table of type inet, and they both had input hook chains, I don't think accept in one chain would have an impact on the other table's chain, although I don't know that for sure.
I asked about that in this ML some time ago. IIRC, it doesn't matter
on table, all chains with input hooks goes into input hook. The inet
family table just register its input chain into both family (ip/ip6) hooks.
The order of processing is based only on priority value, in case of the
same priority, the order is unspecified.
In other words, it doesn't matter if input hook chains are one eg. in ip
family table and second in inet table, or both input hooks chains are
in the same table, they both ends in the same netfilter hook. If packet
have to be accepted in that hook, all chains (in that hook) must not
drop/reject it.
You can simply test that by enabling trace and then monitor it, i created
ip table (for you) just with one accept in input chain (redacted)::
trace id be75f3b8 inet filter input packet: ...
trace id be75f3b8 inet filter input rule ... (verdict accept)
trace id be75f3b8 ip filter input packet: ...
trace id be75f3b8 ip filter input rule ... (verdict accept)
Note "verdict accept" in both, in the inet filter input and in the ip filter
input chains.
Another note, both these chains has the same priority and the ip table
is defined before inet table in config, but packet goes into inet table
first.
regards
--
Slavko
https://www.slavino.sk/
