
Show HN: Inlets – Expose your local endpoints to the Internet - alexellisuk
https://github.com/alexellis/inlets
======
gmac
See also: [http://localhost.run/](http://localhost.run/)

~~~
Sujan
Uh, how does _that_ work?

~~~
gmac
It's a nice use of SSH tunnelling (e.g.
[https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding](https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding)).

------
irl_
For additional security, instead of exposing your internal services to the
Internet, communicate using a Tor Onion service. It handle NAT for you, and
can be very resilient (you have 6500 servers that can act as a rendezvous
point in the Tor network instead of just the 1 VPS). It's not going to give
you the same low latency and high throughput as putting the service straight
on the Internet but it's going to be difficult to match the security (for
confidentiality, integrity and availability) properties any other way.

------
disiplus
[https://github.com/mmatczuk/go-http-
tunnel/blob/master/READM...](https://github.com/mmatczuk/go-http-
tunnel/blob/master/README.md)

there is also this that I used instead of ngrok

------
tdhz77
I will use this to get letsEncrypt Certs for intranet pages. Self sign certs
just seem so dangerous. And I want to renew every 30 days and not 100.

~~~
zaarn
There is nothing dangerous about self-signed certs, browsers show you a
warning because it doesn't know if it should trust the cert. If you add your
CA to the trust store then you can sign your localhost certs.

~~~
zeveb
> If you add your CA to the trust store then you can sign your localhost
> certs.

Not necessarily. Google have decided that Android users can't be trusted to
install their own certificates. I don't know if Apple will permit it, either.

------
rhardih
Also [https://localtunnel.github.io/www/](https://localtunnel.github.io/www/)

------
rohan1024
We will not need these solutions after complete ipv6 migration, right? Or it
also has some NAT equivalent?

~~~
dsr_
You won't need these solutions in any situation where your IT organization is
cooperative and responsive to the company's needs.

~~~
avip
Sometimes you don’t have “an IT organization”. Think demo day with an IoT
device. God bless ngrok.

~~~
dsr_
You're going to do a demo of a network connected device in a new place? Bring
your own network. If you can bring all the parts with you, that's even better
-- a self-contained system that has no external dependencies is best.

If you absolutely need network connectivity, bring a cellular-wifi hotspot
that you've already tested. Talk to the site organizer to find out what cell
networks work there, and if you need to, buy a SIM in advance.

If you don't have an IT organization, you are the IT organization, so be a
good one.

~~~
jsjohnst
While I emphatically agree with you, if the person doesn’t know what they are
doing, following your advise can cause major havoc too.

As someone who has hosted hack days in many countries on six continents and
prides himself on providing a reliable and friendly network (including hand-on
supporting IoT folks) for said events, it’s really freaking annoying when
someone starts blasting their AP at ridiculous power levels for their one-off
use case effectively muddying to hell the RF spectrum of the event space.

~~~
dsr_
So you were the site organizer, and I bet you told people in advance what they
could expect to be available on-site, right?

They weren't in the wrong for being prepared, but for not listening to you.

~~~
jsjohnst
Irregardless if we were prepaired for them or not, or if they listened or not,
there should be an expectation that you know how to use the gear you bring if
you bring your own gear.

It’s the equivalent of bringing a machine gun to a shooting range and spraying
bullets all around you (missing everyone, but still causing a bad time for all
involved) because you don’t even know how to hold it properly.

~~~
jnty
I swear you only got downvoted here for using the word 'irregardless'

------
thunderbong
There's also a roll your own version if you have a domain

[https://jerrington.me/posts/2019-01-29-self-hosted-
ngrok.htm...](https://jerrington.me/posts/2019-01-29-self-hosted-ngrok.html)

------
gesman
Or zerotier (to do it safely)

------
adnanh
Why wouldn't one use SSH tunnels instead of this/ngrok?

~~~
omegabravo
my glorious corporate firewall doesn't allow any traffic other than on ports
80,443

~~~
adnanh
inbound, outbound, or both?

~~~
omegabravo
only outbound connections permitted

~~~
x0x0
I'd ask for approval in writing from my boss to play this game. If received,
you could perfectly well set up a $6 digital ocean box and ask sshd to listen
to 443. Then...

    
    
       ssh -R 443:localhost:3000 -N my_remote-server
    

is a perfectly good outbound connection?

Obviously, you'll want some iptables on the remote end or for your local box
not to have anything valuable on it, but it will let you test webhooks.

~~~
wut42
I run an sshd on 443 for this reason. Helped me bypass some corporate
firewalls in the past, very useful when you go onsite.

------
ithkuil
similar idea (shameless plug) [https://github.com/bitnami-
labs/udig](https://github.com/bitnami-labs/udig)

------
moltar
So it’s like ngrok?

~~~
gruez
From the readme:

>Why do we need this project? Similar tools such as ngrok or Argo Tunnel from
Cloudflare are closed-source, have limits built-in, can work out expensive and
have limited support for arm/arm64. Ngrok is also often banned by corporate
firewall policies meaning it can be unusable.

~~~
dspillett
_> is also often banned by corporate firewall policies meaning it can be
unusable_

If this tool offers similar functionality, as soon as it becomes well-known it
too will "be often banned by corporate firewall policies meaning it can be
unusable".

Welcome to an arms race!

~~~
pingiun
It would be difficult to ban this as it looks like regular https traffic

