Re: nft tproxy without iproute2 rule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> See above, skb->dev is still telling the stack where the packet is
> coming from, not where its going.

I think I meant skb->dst, or skb->dst->dev (I seem to have gotten
confused about the variables in the code snippet).

> Is this about ip rule scalability or keeping config 'private' to nftables,
>
> i.e. bypass the FIB?

It's mostly to keep the config in one place. I was thinking for tools
like sshuttle it would be nice if they only had to mutate nftables,
and didn't have to worry about also setting up (or requiring the user
to set up) the ip rules and routes.

It also feels like marking the packets and creating a rule & route
just to route the packets to the local interface is a bit unnecessary.
It would be simpler to just have an action that could route them to
the local interface, or even directly to the listening socket.

The tproxy action calls nf_tproxy_assign_sock if the socket is
transparent, why not finish setting up delivery so that the rule and
route are not required? Is there something else that could happen to a
packet once the tproxy action has assigned skb->sk?

--
- Norman Rasmussen
- Email: norman@xxxxxxxxxxxxxxx
- Home page: http://norman.rasmussen.co.za/



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux