From: Florian Westphal <fw@strlen.de>
To: Norman Rasmussen <norman@rasmussen.co.za>
Cc: netfilter@vger.kernel.org
Subject: Re: nft tproxy without iproute2 rule
Date: Thu, 10 Oct 2019 00:02:51 +0200 [thread overview]
Message-ID: <20191009220251.GA15526@breakpoint.cc> (raw)
In-Reply-To: <CAGF1phaHKy_bb1ALmB+YpB27gYtN30U8=zViaJ181TaCEPd4sQ@mail.gmail.com>
Norman Rasmussen <norman@rasmussen.co.za> wrote:
> If there was a way to set the output interface in the prerouting and
> output hooks, would the meta mark action and ip rule & route still be
> required?
Yes.
> The netdev fwd statement can be used to transmit packets via a given
> interface, but is only supported in the ingress hook. Would supporting
> setting the output interface it for inet hooks just be a matter of
> supporting the oif and oifname keywords for the "meta set" statement?
No.
> For example (taking from Documentation/networking/tproxy.txt) the
> config becomes:
>
> # nft add chain filter divert "{ type filter hook prerouting priority -150; }"
> # nft add rule filter divert meta l4proto tcp socket transparent 1 fwd
> to lo accept
> # nft add rule filter divert tcp dport 80 tproxy to :50080 meta set
> oif lo accept
The purpose of mark + rule + route is to influence the routing decision
made after the prerouting step, so packet gets passed to input path and
not forward.
skb->dev is the input device at this point.
The code that is being influenced by mark + route is
the call to ip_route_input_noref() in ip_rcv_finish_core which assigns
skb->dst, and the dst_entry describes how the packet will travel in the stack.
> and for local connections:
> # nft add chain filter local "{ type filter hook output priority -150; }"
> # nft add rule filter local tcp dport 80 tproxy to :50080 meta set oif
> to lo accept
> Is there a complication with supporting this in prerouting and output,
> or would this mostly just work as expected? I assume it wouldn't need
> to do the same as the netdev fwd path where the packet is immediately
> sent to egress and xmit, and just doing the far simpler set skb->dev
> and let the rest of the processing continue would work fine?
See above, skb->dev is still telling the stack where the packet is
coming from, not where its going.
Is this about ip rule scalability or keeping config 'private' to nftables,
i.e. bypass the FIB?
next prev parent reply other threads:[~2019-10-09 22:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 20:49 nft tproxy without iproute2 rule Norman Rasmussen
2019-10-09 22:02 ` Florian Westphal [this message]
2019-10-12 5:24 ` Norman Rasmussen
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=20191009220251.GA15526@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter@vger.kernel.org \
--cc=norman@rasmussen.co.za \
/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.