
Localtunnel exposes your localhost to the world for easy testing and sharing - cond289123
https://github.com/localtunnel/localtunnel
======
notliketherest
Just want to point out how easy it is to do this using SSH tunnels. ssh -nNT
-R :<server port>:localhost:<local port> user@domain

~~~
nuggien
that requires you to have a server to ssh to, and doesn't give you free https.

~~~
tomc1985
"Free HTTPS"?

SSH encryption is your "Free HTTPS"

~~~
pcthrowaway
There's still no client-server encryption over the http leg. Someone snooping
on packets can see the traffic of the person using the web-service in
plaintext. HTTPS would mitigate this.

~~~
tomc1985
That's why you route your plaintext traffic it through the tunnel. ssh -L
8080:localhost:80 then go to [http://localhost:8080](http://localhost:8080)

~~~
nuggien
How does that help you access your app from some other machine? And how does
ssh help you get secure access from a remote browser to the tunneled port? The
ssh security is only from the tunneled port to your local port.

~~~
pdkl95
There commands above are suggesting two tunnels, appropriate for when both
parties have private IP addresses behind NATing routers. This requires a
rendezvous server with a publicly visible IP address, The first (with -R)
forwards the listening port of the local private server to the rendezvous
server:

    
    
        ssh -nNT -R 8080:localhost:80 rendezvous.example.com
    

This allows connections to the private local server from processes on
rendezvous.example.com which connect to _their_ localhost:8080. This requires
configuring "GatewayPorts yes" on the rendezvous server, which is disabled by
default. The person you are sharing with then sets up their tunnel to using
the forwarded port:

    
    
        ssh -L 8081:localhost:80 rendezvous.example.com
    

(port number changed to distinguish between the endpoints) This creates a
tunnel from _their_ localhost:8081 to rendezvous.example.com:8080, which is
then forwarded to port 80 on your server that you wanted to share.

Both tunnels are encrypted. While traffic analysis is still possible, the
tunnels also obscure the details of each request; eavesdroppers only see the
tunnels as a stream of encrypted data regardless of how many GET/POST requests
actually happen.

If one side has a public address that can be directly accessed, the rendezvous
server is not needed; just use one tunnel. The fact that we ever need a
rendezvous server is part of the incredible damage IP Masquerading (private
IPv4 addresses behind NAT) has done to the internet. Working around "party
lines" is incredibly frustrating.

If you're setting up many forwarded ports, it may be easier to use a SOCKS
proxy server (ssh option -D <local_proxy_port) instead of many "ssh -L"
tunnels. The other side (-R) will be the same.

~~~
Symbiote
With a public address, and control of the firewall, this isn't even needed.

We have a /23\. I've opened ports 7000-7010 to a few developers' computers, so
they can easily share what they're working on when they want to.

With IPv6, anyone can do this.

------
neeksHN
I must have overlooked this when I unhappily settled for ngrok -- thank you
for sharing a FOSS alternative.

~~~
juancampa
I'm curious, what don't you like about ngrok? Is it just that it's a paid
service? You do need a server somewhere to forward connections and that
normally costs money to run

~~~
shubb
Well indeed - I wonder how these folks are gonna pay for hosting once someone
starts testing a video streaming site...

~~~
burntrelish1273
It would be nice if there were flattr, Patreon, Venmo, BTC/LTC donation links
all over it to pay for VPS/AWS charges. (Not PayPal, F them.)

It's good to ensure survival and utility of cool things such that Tragedy of
the Commons doesn't spoil them.

------
burntrelish1273
LT is probably the best free tunnel out there. I've tried most of them free
and non-free.

 _thumbs up!_

