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....)
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.
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 :(
Any good "restrictive network" blocks QUIC. This helps potentially in places the restriction is structural (CGNAT) but not where the restriction is security-based.
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.
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....)