Tunnelmole – give your local servers a public URL

Requestly (https://github.com/requestly/requestly) founder here!

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.

My favourite one is https://github.com/antoniomika/sish

It uses SSH as the method of opening the remote tunnel to the public server.

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.

But that's at least the basic understanding.

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.

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.

You can download the file with curl so you can read what the script is doing before executing it. You don't have blindly pipe it to bash.

Which isn't going to be of much use to anyone given that feature is still invite-only (my email is in my profile, wink wink).

CGNAT

You could hide that behind a proxy

Could you please share some abuse instances?