Cproxy: Per app transparent proxy built on Linux cgroup net_cls | Hacker News Reader

Cproxy: Per app transparent proxy built on Linux cgroup net_cls

github.com

43 pointslian017 comments

I need to proxy my programs with different proxy servers on a daily basis. Existing solutions such as proxychains has drawbacks such as not able to proxy programs written in Go, so I wrote this to make transparent proxy on Linux handy and simple :)

This looks mighty interesting!

One use-case that I still haven't found a workable solution for: P2P applications over UDP, where I want all incoming and outgoing connections to be tunneled through a remote endpoint (typically over VPN).

And example for how to achieve that in some way (I guess with for, say, Bitcoin, Ethereum or Bittorrent, would be simply amazing.

dokodemo-door is something I never heard about before and looks like the other half of that puzzle, as the readme notes. Going to have to look at it closer.

https://www.v2ray.com/en/configuration/protocols/dokodemo.ht...

Thanks for your comment! Just released v2 with iptables tproxy support. With tproxy, you have all income and outgoing UDP traffic proxied, which should support your use case now.

> One use-case that I still haven't found a workable solution for: P2P applications over UDP, where I want all incoming and outgoing connections to be tunneled through a remote endpoint (typically over VPN).

https://github.com/tailscale/tailscale ?

I've looked at Tailscale before, but I thought it was just a managed WG architecture?

It's more the routing that is the issue which, unless I'm mistaken, falls out of scope for Tailscale (assuming one already has the VPN part sorted).

Tailscale fixes the Internet [0]: It makes it private, secure, and seamless. And because of that, one could do a lot on top of those basic uncompromising guarantees, like build a private, roaming, cross-platform P2P network, for example.

https://tailscale.com/blog/sharing-over-tailscale/

[0] Well, they aren't an ISP yet, but I wouldn't put it past them because of the founding team's previous experience leading Google Fiber.

I still don't see it. The link you shared is for creating ad-hoc tunnels with provisioned trusted parties.

I want to have incoming and outgoing UDP from a particular process/container reachable externally, but routed through a different peer. Maybe I wasn't clear, but I'm talking about public, unathenticated and untrusted P2P networks.

I've looksed over their repos and documentation and see nothing (apart from general "anything is possible" marketing handwaving) indicating it's less work than on any other topology/protocol.

I don't quite get your usecase, but you may be looking for their "exit node" feature which just landed in the CLI (yet to be supported across their UIs)?

https://github.com/tailscale/tailscale/issues/1401

No, that's not it.

If you read the parent issue to what you're posting (which is also not exactly what I'm asking for, I need something more granular wrt routing), you can see clearly from the discussion that this is completely orthogonal to what Tailscale is aiming to achieve.

https://github.com/tailscale/tailscale/issues/102

Isn't it still the case that net_cls cgroup is not available with cgroups v2?

I think it's still not available, so this tool works with cgroups v1 only at the moment. I can add support for cgroup v2 later though (there is workaround by hooking on cgroup v2 pathnames in iptables to achieve the same goal).

Dumb question: this is basically the same thing as the HTTP_PROXY env variable on Linux but at the TCP level instead of HTTP?

Yes and no. There are several differences, the biggest one in my opinion is that cproxy proxies all TCP and UDP connections without requiring the underlying program supporting any proxy, while if you want to use HTTP_PROXY on a program, the program has to explicitly support HTTP_PROXY in its source code. Overall they are all methods to proxy some traffic though.

Another question: do you have any numbers on the performance hit using cproxy? (I have no intuition for how cgroups performs here.)

I didn't do any benchmark, but the performance hit should be minimal since all the heavy work are done by kernel cgroup and iptables. They are very efficient in most cases.

Makes sense, thanks!

HTTP_PROXY is not transparent. The application has to opt-in.

Reply on news.ycombinator.com