[Feature Request] Support tproxy outbound
- Dominant language
- Go
- Stars
- 6.2k
- Forks
- 404
- Avg merge
- 57m
- Merged PRs (30d)
- 2
Description
### 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
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing eBPF outbound matching and the current dae control-plane forwarding path described in the issue. Define the tproxy outbound behavior around direct redirection to the configured local service, then verify that direct and dns paths remain unchanged and that traffic no longer traverses the dae control plane.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, linux
- Domain
- networking, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100