Edit: The nice thing about this is that it allows you to proxy to any any target port including e.g. standard email ports. This was very helpful while I was working locally on a custom email server.
This looks promising! We were also considering to build tunnelling support in our desktop app. Definitely going to explore your DIY tool, thanks for sharing.
Nice work, these types of tools are invaluable and there are well-supported paid options, but not that many OSS projects. There is another project called fast reverse proxy (frp) that has been around for a while, it's open source, however some users are concerned with the country of origin. Never the less, it's probably more mature and well-tested at this point.
A reverse proxy receives the request, takes it apart, potentially examines it and manipulates it, then reconstructs it in accordance with policy and forwards it on to the receiving system. It then takes the response and also takes it apart, examines it, and again possibly applies policy, before reconstructing it and sending it back to the requestor.
Various steps can be elided; I've got a "proxy" that basically just blindly forwards everything, but it is based on an HTTP library and the request and response is fully parsed, even though the policy applied is very light. Various optimizations can be used to avoid expensive disassembly/reassembly, etc.
A tunnel simply shovels the bytes along, and can thus only apply policies based on TCP-level metadata like source and destination IP. A tunnel does not realize you're shoving "GET / HTTP/1.1" or anything else down it, it just moves it along.
Forstalling the inevitable "but what about..."s, this is definitely in that category of things that seems completely separated at 10,000 feet but the closer you get the fuzzier the lines get. Literally anything you can imagine that is technically possible has probably been done. For instance, a "TLS tunnel" is off the shelf tech nowadays; it takes apart the TLS layer of the connection and may apply policy to that, but the socket connection within the TLS tunnel is blindly sent along to the target (possibly itself a TLS connection), thus being simultaneously both a tunnel and a reverse proxy. I can think of at least three other similar things that are both tunnels and proxies, depending on which aspect of them you focus on, off the top of my head, and could list more if I sat down and starting writing it down. Down in the trenches these things are all mixed and matched in all sorts of ways. So in my personal opinion, getting really fussy about the nitty-gritty of the definitions is not terribly useful; there is no sharp line to be found anywhere here. What is useful is understanding that these are primitives that are available to you as you construct solutions, and that they can be assembled into interesting higher-level structures.
A reverse proxy uses one of request forwarding. The downstream router in this case did not initiate the request and so does not know to which internal IP to pass the request to unless you set up port forwarding. Tunnel services such as this solve this issue by setting up a persistent connection between the client and server and relying on the NAT features of your router. Because the client initiates the socket connection your router knows which private IP to forward packets to when the upstream service (e.g. Tunnelmole) sends data. NAT traversal means you don't need port mapping.
When people say reverse proxy they usually mean using nginx/etc to forward traffic to a normal service listening on a port, in that case you still need an open port. In Tunnelmole your "server" establishes long lived outbound connections to another server which forwards traffic to you that way. This technique is commonly used by penetration testers to use "reverse shells" on compromised boxes. It is a very handy technique because it bypasses NATs and inbound firewalls, however it does not scale as well as a traditional reverse proxy.
Looks very interesting (every now and then I wonder about good self-hostable ngrok alternatives), but the "curl x | sudo bash" pattern for installation is really putting me off this one.
There are quite a few of these out there. ngrok (very popular) and Svix Play (ours) come to mind, but I've also seen a few Show HNs in the last few months. What's your biggest differentiator to existing solutions? Not saying that one is needed (hacking for the sake of hacking is great), just wondering if there's something we need to add to ours. :P
[1] https://github.com/ziolko/tunnel
Edit: The nice thing about this is that it allows you to proxy to any any target port including e.g. standard email ports. This was very helpful while I was working locally on a custom email server.