-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Support tproxy outbound #469
Comments
Thanks for opening this issue! |
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. |
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?
My current data path setup is split into three v2ray instances: The datapath is:
If
Now that this feature is possibly not available, to not add one more chain level of userspace program, I may consider to replace
This would be fine. The only issue is that 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. |
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. |
It is normal socks/vmess outbound that supports using unix socket address instead of ip address as remote server.
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
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. |
@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. |
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 v2raytproxy
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:
instead of
The text was updated successfully, but these errors were encountered: