On Wed, Jan 31, 2024 at 08:23:54PM +0000, Slavko wrote:
> Dňa 31. januára 2024 13:02:57 UTC používateľ Kerin Millar <kfm@xxxxxxxxxxxxx> napísal:
>
[...]
> I check manpage now, 1.0.6 (as is in debian bookworm) and from its
> ADDRESS FAMILY section is nor clean (at least for me) the order of
> inet and ip/ip6 tables processing. It is even not clearly stated here,
> that packet will be processed in both, the inet and the ip/ip6.
There is a command to display the datapath hook pipeline per device:
# nft list hooks device eth0
family ip {
hook ingress {
0000000000 chain netdev x y [nf_tables]
}
hook input {
0000000000 chain inet x y [nf_tables]
}
hook forward {
-0000000225 selinux_ip_forward
}
hook output {
-0000000225 selinux_ip_output
}
hook postrouting {
+0000000225 selinux_ip_postroute
}
}
family ip6 {
hook ingress {
0000000000 chain netdev x y [nf_tables]
}
hook input {
0000000000 chain inet x y [nf_tables]
}
hook forward {
-0000000225 selinux_ip_forward
}
hook output {
-0000000225 selinux_ip_output
}
hook postrouting {
+0000000225 selinux_ip_postroute
}
}
family bridge {
hook ingress {
0000000000 chain netdev x y [nf_tables]
}
}
[ The quick example above is rather silly, because it was taken from a
VM with selinux hooks, one single inet/chain at input and one hook at
netdev. ]
But it shows a view per family, for an IPv6 packet...
- going for local process follows ingress hook, entering nf_tables
chain netdev x y, then in case it is local traffic it enters chain
inet x y [nf_tables].
- being forwarded goes through ingress, then forward selinux hook at
priority -225, then postrouting selinux hook again.
- leaving from local process follows output and postrouting selinux
hooks.
- entering the bridge layer, it gets evaluated by the ingress hook
too.
It is a flat representation, so you still have to understand how
routing determines what hook the packet visits.
There is a terse refering in the manpage:
LISTING
list { secmarks | synproxys | flow tables | meters | hooks } [family]
list { secmarks | synproxys | flow tables | meters | hooks } table [family] table
list ct { timeout | expectation | helper | helpers } table [family] table
Inspect configured objects. list hooks shows the full hook
pipeline, including those registered by kernel modules,
such as nf_conntrack.
which is a really shame :)
Someone up for contributing an improvement for the manpage, including
a better example than above and the explaination?
