Rule commands within chains are somewhat standalone, like a python or SQL statement. They completely describe which packets are matched (the expression) and what should be done with them (the statements). Rules are the only things that actually examine packets and perform actions. But rules don't control which packets are examined. The chain they are placed in controls that, similar to how a Python statement executes in method. The 'hook' chains define where in the flow packets are examined. Where in the chain the rule is placed restricts which packets it examines (based on both the initial chain's hook and the previous rules already run). Non-hook chains gather rules to facilitate control flow through the table, similar to Python method. A table is just a set of chains restricted to a specific protocol family (inet, ip, ip6, arp, bridge, netdev), which, in turn, defines which hooks are available. I find this diagram to be very helpful: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks The rest of the configuration (sets, maps, etc.) are just ways to provide data to rule expressions. Rule actions can update structures like sets and maps. I also find the --json option to be helpful. The structure is what controls the flow. Packets enter at a hook chain (like 'input', or 'prerouting'), and traverse rules according to the structure of the chains. The chain JSON objects are analogous to Python functions. Note that the same packet can come in on different hooks as it flows through the system (see the diagram mentioned above). Another thing to keep in mind is that 'drop' is immediate, and the packet is not handled further and will not be available via subsequent hooks in the flow. 'Accept', on the other hand, accepts the packet in the current hook. No other rules reachable from the hook chain are executed. However, the same packet can come in via a subsequent hook, and the rules reachable from that chain may drop the packet. Not an answer to your specific question, but hopefully some of this context helps. -----Original Message----- From: Brian Sammon <bds@xxxxxxxxxxxxxxx> Sent: Friday, August 23, 2024 10:39 PM To: netfilter@xxxxxxxxxxxxxxx Subject: Re: Understanding output from "nft list" [You don't often get email from bds@xxxxxxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] EXTERNAL EMAIL - USE CAUTION when clicking links or attachments On Sat, 24 Aug 2024 01:08:53 +0100 "Kerin Millar" <kfm@xxxxxxxxxxxxx> wrote: > > The first questions I have: > > Can/should I assume that each line in the output of "nft list" is a > > separate, uh... "thing"[1] that can be (human-)parsed independently > > from every other line? > > No, though it is possible to compose rulesets in the iptables-esque > fashion that you imply. That is, by writing consecutive commands of > the form of "add table", "add chain", "add rule" and so forth. > However, the > nft(8) utility does not have an option to list the loaded ruleset in > that way. Instead, it always lists the ruleset in the declarative style. I'm wondering if there's a misunderstanding here. I'm thinking that the output of "nft list" could be like (90% of) python code, where a line like a = b + c can be understood (somewhat) in isolation, even though you don't have the context to know what a, b, and c are. Or, the output of "nft list" could be more like SQL, where you can have lines like SELECT x FROM or users INNER which are each, an incomplete "thing", but can be part of a valid statement. Is the "nft list" output more like python, or more like SQL?
