snapview / tungstenite-rs

Lightweight stream-based WebSocket implementation for Rust.
Apache License 2.0
1.93k stars 222 forks source link

Is there any support for proxies? #177

Open JakkuSakura opened 3 years ago

JakkuSakura commented 3 years ago

I can only access the dest host on another machine by ssh. If I can access it via proxy, it will be much convenient. How can I do it for tungstenite?

strohel commented 3 years ago

Do you have an option to use SSH TCP tunnelling?

JakkuSakura commented 3 years ago

Yes I can use it, but I have many different websocket addresses, so SSH TCP tunnelling is not very convenient.

daniel-abramov commented 3 years ago

We thought about making one of our internal libraries public (it brings support for proxies and supports such auth methods as basic, digest, ntlm, negotiate via SSPI / GSSAPI), but the support for proxies and their authentication methods should be part of another crate. We could introduce a proxy feature though that could rely on another crate for proxy and proxy authentication.

I actually believe we've discussed it somewhere in issues here, but can't find the discussion by just quick search for proxies (perhaps it was in one or another PR)

PrivateRookie commented 3 years ago

I created a branch that supports sock5 proxy in my forked repo, which may be helpful to you. pub fn connect_with_proxy

runapp commented 3 years ago

Actually I guess support for http/https proxy will be more useful. As I write in https://github.com/snapview/tokio-tungstenite/issues/168, to inspect secure websocket connections, the best way is to use some mitm proxy software, which requires the client to send domain (HTTP GET request) rather than resolved ip address. And BTW it also requires support for specifying custom CA certificate, to allow mitm work.

For client behind firewall and only proxy allowed, there are many workarounds, such as using gost to convert almost any proxy protocol to a transparent one, as long as one don't need to inspect the raw stream or the target is plain, unsecured websocket. Still crate level support is always better, for crate users.

JakkuSakura commented 3 years ago

Since we can use any stream that implementes Read and Write(or Async version), a proxy connection like async_socks5 would suffice.

daniel-abramov commented 3 years ago

Since we can use any stream that implementes Read and Write(or Async version), a proxy connection like async_socks5 would suffice.

I had a quick look at it and it seems like you can combine these easily, i.e. just use the async_sock5 to connect to the proxy and then pass the "upgraded" stream to the client() or something.

guotie commented 3 years ago

good question, any solutions?

siegfried commented 2 years ago

It would be great to support system proxies like reqwest does, which can be utilized by Docker easily without change the code.

daniel-abramov commented 2 years ago

Yes, it could have been more convenient, but reqwest is by its nature a batteries included wrapper around HTTP, whereas tungstenite-rs is more like a core for support of WebSockets with optional blocking implementation for quick/typical use cases. tungstenite-rs is more akin to hyper in this regard rather than to reqwest if I can put it like this.

qm3ster commented 2 years ago

@siegfried what makes them so "system"? Is HTTP_PROXY a standard well-known env var that a lot of software expects to be set systemwide?

siegfried commented 2 years ago

@siegfried what makes them so "system"? Is HTTP_PROXY a standard well-known env var that a lot of software expects to be set systemwide?

Supported by CURL, Docker, wget and reqwest. Call it "standard", "convention" or whatever you like. Not interested at the definition debate. I agree with what @application-developer-DA said.

Praying commented 2 years ago

so, any solution can solve the proxy problems?

qm3ster commented 2 years ago

so, any solution can solve the proxy problems?

@Praying depends on the type of proxy. Here's secure websocket over HTTPS proxy: https://github.com/websockets-rs/rust-websocket/issues/258#issuecomment-1052801655

qm3ster commented 2 years ago

In particular, since both that approach and async_socks5::connect leave you with an un-wrapped tokio::net::TcpSocket or whatever else you had, you can easily handle HTTP_PROXY values of http:// and socks5://, or lack thereof, without any dyn, enums, or generics. Only what you do on the socket before passing it to tokio_tungstenite::client_async_tls changes!

lambdalisue commented 2 years ago

FYI. I'm using async-http-proxy with async-tungstenite and works well for general HTTP proxy (not SOCK5). I remember that the feature was tested with nginx, squid, haproxy, and proxy.py

chuxi commented 1 year ago

I resolved the problem with reference from reqwest proxy implementation and make up all the details in my post websocket

copy the InnerProxy and ProxyStream in your websocket client wrapper file. I did not supply it as library, because maybe the tungstenite will support the feature.

please use tokio-tungstenite