Annoying that this has the same name as https://github.com/ucb-bar/chisel3
Sorry! Was originally a rewrite of https://github.com/q3k/crowbar so I chose a synonym.
Chisel – A fast TCP tunnel over HTTP
31–40 of 41 posts
Re: Chisel – A fast TCP tunnel over HTTP
#32How does this deal with double congestion control?
It doesn't. I'd like to support UDP at some point, maybe rewrite using https://github.com/xtaci/kcp-go.
Re: Chisel – A fast TCP tunnel over HTTP
#33Hold on, hold on, hold on. Let me get this straight: you took an application layer protocol (HTTP) that runs on top of TCP and ...reimplemented TCP over it!? (see: https://www.quora.com/What-is-the-difference-between-HTTP-pr... )
No, TCP has not been reimplemented.
Re: Chisel – A fast TCP tunnel over HTTP
#34Why TCP over websockets? You can just use the HTTP bodies as a stream in both direction. Which means the proxy just has to strip or add HTTP headers before forwarding. The overhead afterwards is 0 -> you just write to the socket.
I remember trying run SSH (the current TCP multiplexing protocol) over straight HTTP and found there were issues so I added WS to the mix. There probably is a way to do it though it does the job as is.
Re: Chisel – A fast TCP tunnel over HTTP
#35Earlier quoted context omitted.
this surely is great and i can't wait for a moment when someone finally comes up with a TCP Hole Punching as a Service. vpnazure kinda does this, but has the overhead of softether vpn service on top of it... I would rather go with punching myself an ssh port.
I do it at Wormhole[1] in a very similar fashion to "vpnazure"; also with SoftEther. Why would you rather "punch yourself and ssh port"? Do you mean that your main problem with vpnazure and the like is the need of an agent/client software installed? I am not sure I understood your concern, but I would be very interested in hearing more about it. Feel free to email me to the address on my profile if you prefer, althou…
That's seems like an awesome service, thank you for the work!
> main problem with vpnazure and the like is the need of an agent/client software installed
Yes, and at the same time vpnazure creates a vpn set up (I think it's server/client set up, not bridge), while for my simple usage I only need a single TCP connection through which I'd work with SSH. And from this point, I could spawn a ssh tunnel and forward the needed traffic through it, alleviating the need of vpn. Maybe it is a really basic use case, but for work/home environment I find it to be the thing I actually need, and not the full blown vpn.
Another problem with vpnazure I had is that I'd have no way of seeing where the traffic flows inside the vpn interface. Thinking about it now, probably could be seen in traceroute. But at the time, I thought about looking into tcpdump of vpnserver or setting up a firewall. And that was too complicated for my hobby set up. The point of my concern was that I wanted to see whether any traffic is leaking onto third party servers managed by SoftEther or otherwise. Of course I'd want the traffic to flow across the internet, but I'd expect it to take the path it would take if one of the nodes was a natural server.
Also, all the traffic is managed by vpnserver (softether's one), which makes it a little opaque in terms of where the packets go out of that process.
Of course a client would be inevitable for any hole punching SaaS, but preferebly I'd like if it'd only run during the connection establishment period of time.
That's my 2 cents, coming from a personal set up.
Re: Chisel – A fast TCP tunnel over HTTP
#36Earlier quoted context omitted.
Hmm, this choice is indeed strange, websockets still are blocked in some restrictive set ups (squid?). But still, what is the way of doing stream in both directions? Do you mean opening multi-part form data for uploading and transfer encoding chunked for download? But that would be 2 tcp connection for 1 tcp tunnel. And I believe there's no other way to do it without the overhead of HTTP request/response headers.
Not necessarily ... you would have to issue a HTTP request per uplink chunk but HTTP can use connection pooling so that does not necessarily translate to a single TCP connection [0] Agreed it's not quite as straightforward as the parent poster suggests. I can see issues with this approach for realtime/streaming applications but for applications relying on a similar request/response flow of traffic it would do the job…
Isn't connection pooling just using several connections to download one resource using content-range?
Re: Chisel – A fast TCP tunnel over HTTP
#37Earlier quoted context omitted.
Hmm, this choice is indeed strange, websockets still are blocked in some restrictive set ups (squid?). But still, what is the way of doing stream in both directions? Do you mean opening multi-part form data for uploading and transfer encoding chunked for download? But that would be 2 tcp connection for 1 tcp tunnel. And I believe there's no other way to do it without the overhead of HTTP request/response headers.
Technically HTTP represents a bidirectional stream of arbitrary data in both directions, which follows a set of headers and is optionally finished by a set of footers. This is for example quite obvious when you look at the HTTP/2 specification. There is no need for the bodies to be sent in a particular order (response body after request body) or in a particular encoding (form-data, chunked, SSE, etc.). It can be two…
It's true that underlying tcp connection can be reused for virtually anything and it doesn't have to be conformant with having http requests/response. But it would probably get blocked by a proxy which wouldn't be able to pass it down the line.
Re: Chisel – A fast TCP tunnel over HTTP
#38And no reference to the standard mechanism for HTTP tunnels, which has only existed for 18 years.
Re: Chisel – A fast TCP tunnel over HTTP
#39Earlier quoted context omitted.
I do it at Wormhole[1] in a very similar fashion to "vpnazure"; also with SoftEther. Why would you rather "punch yourself and ssh port"? Do you mean that your main problem with vpnazure and the like is the need of an agent/client software installed? I am not sure I understood your concern, but I would be very interested in hearing more about it. Feel free to email me to the address on my profile if you prefer, althou…
That's seems like an awesome service, thank you for the work! > main problem with vpnazure and the like is the need of an agent/client software installed Yes, and at the same time vpnazure creates a vpn set up (I think it's server/client set up, not bridge), while for my simple usage I only need a single TCP connection through which I'd work with SSH. And from this point, I could spawn a ssh tunnel and forward the ne…
Hi! thanks for sharing your opinion!
I think what you're looking for is https://ngrok.com/ - it's quite popular among developers.
> Another problem with vpnazure I had is that I'd have no way of seeing where the traffic flows inside the vpn interface. Thinking about it now, probably could be seen in traceroute. But at the time, I thought about looking into tcpdump of vpnserver or setting up a firewall. And that was too complicated for my hobby set up. The point of my concern was that I wanted to see whether any traffic is leaking onto third party servers managed by SoftEther or otherwise. Of course I'd want the traffic to flow across the internet, but I'd expect it to take the path it would take if one of the nodes was a natural server.
> Also, all the traffic is managed by vpnserver (softether's one), which makes it a little opaque in terms of where the packets go out of that process.
I see what you mean and I understand your concerns.
If you'd like to see the path from your connection to the VPN servers you can always do a traceroute to its public IP. However for concerns regarding what they do at the server level, if a 3rd party manages the VPN server, you only have your trust in them and their degree of transparency. Next step would be to go self-hosted, but then you need to trust the hosting provider too.
Thank you!
Re: Chisel – A fast TCP tunnel over HTTP
#40Earlier quoted context omitted.
Not necessarily ... you would have to issue a HTTP request per uplink chunk but HTTP can use connection pooling so that does not necessarily translate to a single TCP connection [0] Agreed it's not quite as straightforward as the parent poster suggests. I can see issues with this approach for realtime/streaming applications but for applications relying on a similar request/response flow of traffic it would do the job…
Isn't connection pooling just using several connections to download one resource using content-range?
Connection aggregation?