Open Vigilans opened 3 months ago
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?
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.
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.
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.
@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