I was able to keep my code small by leveraging existing protocols: TLS for authentication and HTTP2 for multiplexing, stuffing simultaneous HTTP1 requests onto a single TLS-encrypted tunnel socket.
There is must be a reason why they have blocked ngrok. It is not the tool, but the idea that you are opening tunnels from person machine to transport data undetect is what they don't like.
Let me know how to goes! And watch for an update this week. I'm writing thousands of lines of tests to iron out all the event handling quirks in case of bad network conditions etc. I want to make it rock solid.
Clearly a lot of work went into this so kudos for that.
I do think it missing the point a tiny bit though. For me the primary use of Ngrok is to automatically get sub a domain with TLS and this seems to be outsourcing that to Caddy. And also I need to run a server. If I was going to run a server and run caddy I'd probably just use SSH -L directly.
Also SSH -L is a TCP/IP level tunnel so I'm missing something regarding why the HTTP/2 multiplexing is necessary vs just using the tunnel as is.
SSH does some kind of lower-level multiplexing. Multiplexing is unavoidable here because the local server must maintain simultaneous TCP connections that must be somehow distinguished between each other whereas the tunnel is just a stream of binary data.
I understand multiplexing is necessary. My point is SSH tunnels already multiplex. If two people connect to the same port on the tunnel machine then that will be two seperate sockets on the destination machine. Since they are already two separate sockets what is the point of adding HTTP/2 protocol awareness at the tunnel level? Just let the endpoints handle it.
Oh looks like we misunderstood each other. The fact is that h2tunnel is not using SSH, because my goal was a minimal Node.js native solution. So I had to look for a built-in alternative for multiplexing and found HTTP2.
Hopefully I'll make it on the hall of fame [1] :)
[1] https://github.com/anderspitman/awesome-tunneling