[Feature Request] Support tproxy outbound

[Vigilans]

Greetings

No response

Feature Request

Support a new proxy protocol tproxy, which will forward all traffic to a local service port with transparent proxy enabled.

When matching tproxy outbound in eBPF, directly redirect the traffic to the outbound destination, instead of redirecting to dae control plane first and then forward to the destination.

Use Cases

This allows dae works as a general-purpose kernel-level router that all third-party proxies with tproxy support can extend with.

e.g., By using tproxy outbound that points to v2ray tproxy inbound, dae will forward all traffic directly to v2ray, and let v2ray do advanced sniffer-based routing and dialing to actual remote outbounds.

Potential Benefits

Currently, all non-direct/block traffic are directly forwarded to dae tproxy port. Even using socks outbound that points to other local proxy service, there is still overhead of going through dae control plane.

With tproxy outbound supported, eBPF code will directly send the data to thrid-party proxy service, eliminating the dae control plane path, so dae will works more like a kernel-level router plugin that other proxies can extend with. New proxies can implement the proxy in their own codebase and choose to use dae as router by implementing tproxy support.

The traffic path will look like this:

direct: eBPF -> direct
dns: eBPF -> dae control plane (for reversed domain lookup)
outbound1: eBPF -> v2ray
outbound2: eBPF -> any other proxy services that supports tproxy inbound

instead of

direct: eBPF -> direct
dns: eBPF -> dae control plane (for reversed domain lookup)
outbound1: eBPF -> dae -> v2ray
outbound2: eBPF -> dae -> any other proxy services that supports tproxy inbound

[dae-prow]

Thanks for opening this issue!

[mzz2017]

Thanks for your issue.

Although it is technically feasible and can be achieve with a certain amount of work, we recommend you to use dae and make it better.

We hope that the dae control plane and the ebpf program are integrated rather than separated. The separated design is not supported and may bring more maintenance costs.Thank you for your understanding.

[Vigilans]

Thanks for your reply. So it looks like a pull request for this feature will also not easily get merged in terms of maintenance cost?

The separated design is not supported and may bring more maintenance costs.

---

My current data path setup is split into three v2ray instances: dns, router and proxy, where dns and router are long lifetime services, while proxy are simple servers and outbounds managed by heavily patched v2rayA using customized core-hook, for simple and quick switching between nodes.

The datapath is:

tproxy -> v2ray router -> v2ray proxy

If tproxy outbound feature as specified in this issue supported, the datapath will be updated to be:

ebpf(tproxy) -> v2ray router -> v2ray proxy

Now that this feature is possibly not available, to not add one more chain level of userspace program, I may consider to replace v2ray router with dae router:

ebpf(tproxy) -> dae router -> v2ray proxy

This would be fine. The only issue is that v2ray router and v2ray proxy are communicated using unix domain socket (with each socket file named as a v2rayA outbound/server, and will unconditionally route all traffic to that outbound/server), but dae's dialer seems to not support unix socket?

I've patched v2ray to support using unix socket as outbound address, and brought support for unixgram (UDP like) socket, so overall I will switch to dae when I took the time to port these patches to dae.

[mzz2017]

I don't hope tproxy outbound, it will separate the dae control plane and the ebpf program.

unixdomain outbound is acceptable. The only consideration is its protocol design. Do you have a relevant specification and relevant PR（in v2fly)? The communication protocol in relevant commits do not seem to be universal.

[Vigilans]

unixdomain outbound is acceptable

It is normal socks/vmess outbound that supports using unix socket address instead of ip address as remote server.

The communication protocol in relevant commits do not seem to be universal.

The universal part is the TCP and UDP dialer. In provided patches many of the commits are for higher level transport like grpc, http2, quic]. They are built on top of the universal TCP and UDP dialer, and the non-universal part is to figure out the network used from the destination string (tcp for https://test.com, unix for unix:///path/to/xxx.sock, parsed as net.Destination struct in v2fly).

Do you have a relevant specification and relevant PR（in v2fly)?

I am seeking for available time to format the patches to open PRs to v2fly. During that time I may also do the port job for dae.

[mzz2017]

@Vigilans After your explanation, I re-read your commits and they look fine. Adding unix(unixgram) outbound to the dae is a exciting iteration of functionality.

Your contributions are welcome. Before that, please allow me to introduce you to the relevant code import structure.

daeuniverse/dae imports daeuniverse/outbound imports daeuniverse/softwind

daeuniverse/outbound just combines some protocols/transports as a outbound and parses link format to generate an outbound instance.

daeuniverse/softwind is the underlay protocol implementation.

You can implement unix as an outbound, and code the detailed implementation in softwind. Of course, the actual situation may be different, you can make your own decision and keep in touch with us.

Thanks.