From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Slavko <linux@slavino.sk>
Cc: Netfilter list <netfilter@vger.kernel.org>
Subject: Re: Combine ipv4 and ipv6 in a set
Date: Wed, 31 Jan 2024 23:36:51 +0100 [thread overview]
Message-ID: <ZbrLg8luc8tbZALr@calendula> (raw)
In-Reply-To: <83255444-F0BF-4340-B721-976AC8E5B6AC@slavino.sk>
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@plushkava.net> 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?
next prev parent reply other threads:[~2024-01-31 22:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 10:17 Combine ipv4 and ipv6 in a set Daniel
2024-01-30 10:39 ` Kerin Millar
2024-01-30 12:13 ` Daniel
2024-01-30 12:59 ` Daniel
2024-01-30 13:08 ` Marc Haber
2024-01-30 13:22 ` Kim B. Heino
2024-01-31 10:21 ` Marc Haber
2024-01-31 11:22 ` Kim B. Heino
2024-01-30 15:17 ` Kerin Millar
2024-01-30 17:00 ` Slavko
2024-01-30 17:57 ` Kerin Millar
2024-01-30 19:34 ` Slavko
2024-01-30 22:05 ` Kerin Millar
2024-02-01 12:13 ` Marc Haber
2024-01-31 11:27 ` Marc Haber
2024-01-31 11:13 ` Marc Haber
2024-01-31 11:00 ` Marc Haber
2024-01-31 10:54 ` Marc Haber
2024-01-31 11:55 ` Daniel
2024-02-01 11:39 ` Marc Haber
2024-01-31 13:02 ` Kerin Millar
2024-01-31 20:23 ` Slavko
2024-01-31 22:10 ` Kerin Millar
2024-02-01 6:06 ` Kevin P. Fleming
2024-02-01 17:09 ` Kerin Millar
2024-02-01 10:50 ` Slavko
2024-02-01 12:48 ` Kerin Millar
2024-02-01 13:42 ` Slavko
2024-02-01 14:03 ` Kerin Millar
2024-01-31 22:36 ` Pablo Neira Ayuso [this message]
2024-02-01 8:22 ` Slavko
2024-02-02 1:38 ` Eric
2024-02-02 9:23 ` Pablo Neira Ayuso
2024-02-03 9:24 ` Slavko
2024-02-03 15:49 ` Eric
2024-02-05 9:47 ` Pablo Neira Ayuso
2024-02-05 17:02 ` Eric
2024-02-05 17:08 ` Pablo Neira Ayuso
2024-02-05 17:16 ` Eric
2024-02-01 11:33 ` Marc Haber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZbrLg8luc8tbZALr@calendula \
--to=pablo@netfilter.org \
--cc=linux@slavino.sk \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox