All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.