Reverst: Reverse Tunnels in Go over HTTP/3 and QUIC | Hacker News Reader

Reverst: Reverse Tunnels in Go over HTTP/3 and QUIC

github.com

191 pointstodsacerdoti25 comments

This is great! I've had this exact idea for a specific robotics use-case but never got around to implementing it: a fleet of robots that each expose an HTTP service for debugging purposes. These robots connect to the internet through cellular or hop around among a set of wifi access points, such that long-lived connections are often interrupted and each robot IP address intermittently changes.

Many other reverse proxy / tunneling solutions use TCP-based protocols or require the target hosts to be accessible by the proxy server, but in this case QUIC connection migration avoids the reconnection handshakes needed for dropped TCP connections, and your client->server model allows the robots to register themselves from restrictive networks.

The only missing feature would be to allow some sort of auth plugin - perhaps as a sub-request made to an external auth service that contains the identifier of the client the request will be routed to, similar to nginx's auth_request (https://nginx.org/en/docs/http/ngx_http_auth_request_module....)

Generally people use Zerotier for this kind of usecase in the industry. It is pretty robust.

Have you considered wireguard / tailscale?

Would love a feature request GH issue for that! Seems totally doable!

You can do SSH from the robot to a host, and keep it alive with autoSSH. Add a reverse tunnel for the web if you have a web interface on the device.

https://linux.die.net/man/1/autossh

Few notes: manually add host machine key on first use. I add the parameters:

    autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"

But why http?

Network effects? (No pun intended.) HTTP has a big ecosystem. Ex. Everyone already has curl installed.

Edit: This isn't hypothetical, either; I literally use curl regularly to query services. Sure, there are other options, but HTTP generally works, so...

Very neat. Lots of similar tools listed on https://github.com/anderspitman/awesome-tunneling. Seems similar to zrok.io, ngrok, cloudflare tunnels, tailscale funnels and zrok although you're using http/3 explicitly.

Personally I work on two similar projects you might want to check out: zrok and OpenZiti. Similar projects, but zrok is closest to what you did here.

Amazing! There really is an awesome- for everything haha. Definitely checking these out.

Nice project :)

HTTP3 may not be suitable for all environments, as UDP is pretty commonly filtered.

If you are in such scenario, you may want to take a look at wstunnel, it allows you to do the same (and more) over websocket or HTTP2.

https://github.com/erebe/wstunnel

I just saw, judging by Nick you are probably the author :)

Do you have the protocol defined somewhere? Wstunnel is one of our options, and we'll likely add a golang library for the solution we chose. Would be easier if I don't have to figure out the frame format from code.

We recently ran into issues with http2. Specifically the lack of support in zscaler.

We are still looking into something like wstunnel and websockets, though I'm preparing myself for the day when we have to add "normal" http1.1 support :(

Nice, check out the selfhosted-gateway if you're looking for something similar based on nginx + caddy + wireguard: https://github.com/fractalnetworksco/selfhosted-gateway

Not a bad way to exfil data from target server.

Any good "restrictive network" blocks QUIC. This helps potentially in places the restriction is structural (CGNAT) but not where the restriction is security-based.

You can easily setup a reverse tunnel with something like websockets or HTTP/2 (TCP). For example with wstunnel[1].

[1] https://github.com/erebe/wstunnel

Add it to the toolkit!

This is a great idea! There are multiple tentatives of achieving the same feature with HTTP/2. A RFC is even being written https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-htt...

HAProxy implements something similar in HTTP/2 with the 'rhttp@' keyword.

edit: wrong URL.

This is great! Thanks for sharing!

I just updated the URL which was the wrong one.

This is very cool.

We built something similar in https://github.com/namespacelabs/breakpoint but the more general purpose nature here is great.

This is very useful. I needed this at least 10-20 times in the past but didn't know it existed.

I no longer need it in a CI context but I could imagine this getting really handy when some weird thing happens during the build stages of a docker container too.

Omg you have no idea how many times I wished I had something exactly like this! Going to test this out this week and almost certainly integrate this into my team’s workflow.

Let us know how it goes!

This is very cool. Checking it out! Thanks!

Reply on news.ycombinator.com