Show HN: Inlets – Expose your local endpoints to the Internet | Hacker News Reader

Show HN: Inlets – Expose your local endpoints to the Internet

github.com

146 pointsalexellisuk48 comments

Uh, how does _that_ work?

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

That's my goto tool for this type of thing

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.

https://github.com/mmatczuk/go-http-tunnel/blob/master/READM...

there is also this that I used instead of ngrok

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.

> Self sign certs just seem so dangerous.

Why are they dangerous? Is that because they need to be manually added to applications, and no one bothers to do that?

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.

> 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.

You can achieve this without exposing any service. Let's Encrypt allows you to prove ownership of a domain through DNS 01 hooks.

I personally use Duck DNS [1] for main internal domains, so I can have a certificate that most tools will recognize as valid. This saves me from adding my cert in every machine that will use that service.

I use dehydrated [2] to get a Let's Encrypt certificate using Duck DNS. There is a good article explaining that by Andreas Gohr [3].

[1] - https://www.duckdns.org/

[2] - https://github.com/lukas2511/dehydrated

[3] - https://www.splitbrain.org/blog/2017-08/10-homeassistant_duc...

Also https://localtunnel.github.io/www/

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

Unless a firewall on your network is blocking incoming connections to your IPv6.

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

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

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.

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.

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.

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.

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

these solutions are useful for more than "just when corporate IT sucks".

example: I need to debug a test-mode stripe webhook and normal approaches have failed for whatever reason. solution: fire up a dev environemnt locally, ngrok it, add the ngrok address to the staging webhook list, profit.

There are tons of use cases.

The chances are, your home router will still have default-deny inbound firewall even in IPv6 world.

So you will need to either configure router to open the firewall, or use a solution like this. Which pretty much like current situation -- you need to either configure router to make a NAT mapping, or use a solution like this one.

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

https://jerrington.me/posts/2019-01-29-self-hosted-ngrok.htm...

Or zerotier (to do it safely)

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

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

inbound, outbound, or both?

only outbound connections permitted

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.

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

There's this little gem that uses websocket tunnels for all those times only http is allowed. https://github.com/jpillora/chisel

A lot of modern websites rely on websockets for push notifications so they're usually open. It works wonderfully for things like public WiFi where all traffic is sent through an HTTP proxy and everything else blocked

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

So it’s like ngrok?

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.

Source code of Cloudflare's Argo Tunnel: https://github.com/cloudflare/cloudflared

ngrok v1 is open source.

Unfortunately:

"DO NOT RUN THIS VERSION OF NGROK (1.X) IN PRODUCTION. Both the client and server are known to have serious reliability issues including memory and file descriptor leaks as well as crashes. There is also no HA story as the server is a SPOF. You are advised to run 2.0 for any production quality system."

https://github.com/inconshreveable/ngrok

NB I've used ngrok and think it's very useful, but it's not really open source

Why would anyone run ngrok "in production" anyway? I thought it was just a tool for briefly making your computer into a publicly available server?

Because, if it's possible, someone will do it.

I've used it for demos - which aren't production but I'd really prefer if it didn't crash!

Make a small prototype and show it to your boss, they now think it's fully working (Prototype/WIP/etc... means nothing to some people) and they start to show it around aaaand before you know it you are hosting a new company's website.

> Make a small prototype and show it to your boss, they now think it's fully working (Prototype/WIP/etc... means nothing to some people) and they start to show it around aaaand before you know it ...

What is the best way to avoid this trap, short of making your prototypes purposefully buggy and incomplete?

I am afraid that even that would not work, in my opinion the best solution is be aware of it and try to always have prototype that you are confident enough you could release and keep working on.

Wipe data every X days and display a huge red header warning of this.

The same sort of tools are often used for accessing IOT devices running "in the wild" by the applications managing them. Ngrok has also themselves at times marketed for this purpose (although they now call it "ngrok link", but it seems to be the same underlying tech).

It's basically using the same tactics as a RAT used by hackers, but used for legitimate uses.

> 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!

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

Reply on news.ycombinator.com