[Feauture Request] Adding the option similar to "exclude_interface" in tun but with drop nftables rule

[OrLojqrG]

Operating system

Linux

System version

6.x

Installation type

Original sing-box Command Line

If you are using a graphical client, please provide the version of the client.

No response

Version

No response

Description

Right now using sing-box with auto_redirect and auto_route in tun to create a transparent proxy server is quick and dirty. But there is a tiny issue that bothers me a lot.
Here is a simple picture shows the topology of the transparent proxy server created by sing-box on GNU/Linux.

The en0 is the outbound interface to the internet (already been bind to the outbounds.bind_interface) and the en1 is configured to listen the traffic that needs to be proxy-ed. There is no problem with the en1 because it is working as expected with nftables rules created by the auto_redirect. However, if the exclude_interface hasn't been configured in tun, the sing-box will create a very fair nftables rule to handle the those two enX interfaces. Which means both of the interfaces will be allowed to redirect traffic to tun0. Or in a simple word, a device in the en0 side can easily set the en0 address as the gateway address to implement the bypass routing. I don't need bypass routing so I put the en0 into the exclude_interface. And now the traffic from the en0 side will be like this:

The traffic doesn't come into the tun0, but the traffic got a return at last and performed as a redirect. (Which can be found in the nftables rule as return, this is also something working as expected because it can control whether the traffic need to be redirected to the tun0 at firewall level)
My simple opinion is that, adding an option which is similar to exclude_interface but with drop nftables rule so that any traffic from the "wrong" side won't be redirect any more. (The name can be called dropped_interface).

Reproduction

There isn't any error. It's just a simple feature request.

Logs

No response

Supporter

• I am a sponsor

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
• I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
• I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.