Hacker News

kekub said a year ago:

I am using

> ssh -R 8080:localhost:8080 my.server.com

and have Caddy webserver running on my server (my.server.com) which is configured to proxy any requests to localhost:8080. It adds LetsEncrypt and makes sharing local web projects easy.

alexellisuk said a year ago:

Purpose-built UX, Docker images, Kubernetes support, future plans to add LetsEncrypt automation. There are ways to make "ssh" work through a corporate proxy, but normally it's banned. Websockets over HTTPS usually goes through without being blocked.

Multiple upstream sites are supported with ease as well as multiple exit node domains. If SSH is working for your use-case, then I'd say stick with it.

mbrumlow said a year ago:

At first I said why websockets, when you are using go you could simply had done TCP sockets. But then I realize websockets is probably the right choice. This allows you a single listening port for both inbound and outbound connections as you can simply route /api/proxy or proxy our whatever you are using as your endpoint.

At first I did not like it, and responded like others, over kill for something many people can do (or are doing) without the aid of a fancy tool like this. But then I realized trying to covey to others who are not system programmers how to setup something and realized I would rather spend my time doing something else and just point them to a tool.

Good job on this!

com2kid said a year ago:

That doesn't really scale to a team though, esp for tools that have a common configuration (e.g. localhost ports).

Some sort of tooling to point "this machine to this VM" becomes needed.

Then for full stack development it is even harder, as the app has to have this endpoint injected into it.

It is all possible, just a pain. Writing a mobile app (https only!) that talks to a service I am writing has a rather annoying set of minimal requirements to get up and running. (This may be why Firebase Functions are so popular, super easy to go from nothing to deployed endpoints in just a few minutes.)

macawfish said a year ago:

Yes! I just realized that you can do this without any fancy tools!

davnicwil said a year ago:

Well, the catch is you have to set up and maintain your own server running a proxy :-)

I don't think these tools are really claiming to sell anything fancy that you can't fairly straightforwardly do yourself - what you're buying is convenience (saved time and focus) - just pay for this tool and you're ready to go, within minutes.

macawfish said a year ago:

Recently I spent an hour trying to get a bunch of "self hosted ngrok alternatives" to work and couldn't figure out any of them. Either I couldn't get them to compile or their documentation had me seriously fooled.

Then I found out how easy it was to set up ssh reverse tunneling. Sshd + systemd turned out to be all I needed for a pretty stable and persistent connection from anywhere. I was so satisfied to find that the most common tools out there could already handle this. Yay!

alexellisuk said a year ago:

Give inlets a shot if you get time and let me know how you think it compares.

macawfish said a year ago:

Seems like it could really be convenient for dev work... I'll keep it in mind in the future!

eeZah7Ux said a year ago:

Very often the simplest and well-tested tools are more reliable and quicker to use together than yet another fancy tool.

alexellisuk said a year ago:

"just pay for this tool" - it's free, OSS and accepts contributions.

antoniomika said a year ago:

Shameless self plug, but I wrote something that does the exact same thing as this (https://github.com/antoniomika/sish) but has some added benefits:

1. Don't require installing a local client, use something that is installed almost everywhere: ssh 2. Use a protocol that is already great at multiplexing: ssh 3. Supports authentication using PK/password auth: ssh 4. Completely opensource

Nothing crazy or flashy, just simple and does the job.

bantunes said a year ago:

Sish is pretty cool and full of features.

Buetol said a year ago:

I also like the idea of "onion-expose"[0], no need for a central server anymore and a stable address for free !

[0]: https://github.com/ethan2-0/onion-expose

eeZah7Ux said a year ago:

You don't need a tool. Creating a temporary onion service is trivial.

Buetol said a year ago:

If it's more trivial than an simple "pip install & onion-expose 8000", then please tell me ! (this is theorical, onion-expose is not yet on PyPI)

Also, let's learn from our history: https://news.ycombinator.com/item?id=9224

rbrtl said a year ago:

That does seem to be the theme with these new apps...

qrv3w said a year ago:

I like that they are using websockets to process the GET requests. I was thinking about this just this week and it occurred to me that the "Host Node" [1] doesn't even need to be a program, it could just be a browser since they also have websockets and a API for getting files. I made a POC (proof-of-concept / piece-of-crap) example for this idea: https://hostyoself.com

[1] https://github.com/alexellis/inlets#intro

Svoka said a year ago:

Seems like https://ngrok.com/ with extra steps

pknopf said a year ago:

Except ngrok supports ssh.

These projects really need to consider plain TCP connections. It's a deal breaker for me.

My company installs ngrok on our embedded devices. When there is an issue, they connect it to the internet, type a keystroke, and I'm in.

alexellisuk said a year ago:

Ngrok is closed source, I do explain the differences in the post. Ngrok is also almost always banned..

pknopf said a year ago:

I haven't run into a single hospital network where it is banned, so far.

You can also use ngrok1, which you can host yourself. It's got the features you'd need. This would get around firewalls.

kevin_nisbet said a year ago:

For remote access, Teleport for IOT supports a similar use case using SSH, where an agent can be run on an embedded device, optionally or always enabled that phones home, and allows SSH connections to be reverse tunneled back to the device behind a firewall. https://gravitational.com/blog/iot_security_teleport/

Disclaimer: I work for gravitational but not on teleport.

iampims said a year ago:

Can you share more details about this? Sounds very interesting!

pknopf said a year ago:

I have an X11 key listener. When someone reports a problem and they have access to the internet, I have them type "__medxremotedebug". An ngrok process is started, the machine beeps to notify the user that the backdoor is open. I then login to ngrok.com, see the tunnel and connect to it. All the units have a public ssh key and only I have the private key.

This has saved me and my customers so many times.

smashah said a year ago:

Bro. TMI

pknopf said a year ago:

Hmm? He asked.

gitgud said a year ago:

Or my personal favourite: http://localhost.run/

trevordixon said a year ago:

https://serveo.net is similar.

jchook said a year ago:

If it’s this simple to host an arbitrary TCP reverse proxy, why would inlets make it a “non-goal”?

sandGorgon said a year ago:

Surprising that a site like this operates on http.

mceachen said a year ago:

https://localhost.run/ works (and when you use their tunnel, both http and https work).

gpmcadam said a year ago:

Is this a direct competitor to Zoom?

haggy said a year ago:

Comment of the week

discordance said a year ago:

very funny

said a year ago:
rohug said a year ago:

Serveo is another good alternative to Inlets or ngrok that is completely free and pretty flexible: https://serveo.net/

Legogris said a year ago:

Interesting, I will definitely try this out. If the Kubernetes ingress integration works well and it's stable, this could be really awesome.

I'm a bit curious about the choice of websockets as a protocol over the tunnel, though. Why is "tunnelling plain (non-HTTP) traffic over TCP" a non-goal? What's the benefit over just tunneling the HTTP traffic over a reverse SSH tunnel or similar?

EDIT: Maybe it's just a question of the author finding websockets "good enough" (despite performance overhead) and wanting to keep the scope small with a single implementation that isn't really going anywhere. Here a suggestion on using WebRTC instead of Websockets: https://github.com/alexellis/inlets/issues/49

> Thanks for the suggestion. I'll look into webrtc when I get time, but for the time-being I think web sockets are going to be the way inlets works.

ComputerGuru said a year ago:

That issue was not handled in a way that makes it an open source project I’d want to contribute to.

icebraining said a year ago:

How would you prefer it be handled?

veesahni said a year ago:

I also run ultrahook.com for unidirectional webhook only use case.

markstos said a year ago:

This seems like a solution for sharing a private development server with co-workers.

A decade ago we used another solution which seemed to work well enough: Developers had a Unix accounts on a Linux server. Their workspace was mounted as a remote filesystem. Interactive console access was available via SSH.

Inlets seems to still require a remote Linux server, but seems a like a more complicated way to solve the problem.

By using a shared server, we didn't need maintain container image to keep laptop environments sync'ed. If we wanted to upgrade the development database version, we upgraded the DB once on the shared server and everyone had the new version immediately.

asdfman123 said a year ago:

I don't believe that's the main use case for this project. The main use case for stuff like this is if you're using some external API like Zuora or Twilio that needs to hit endpoints on your local test box. Something like this allows them to actually contact your machine indirectly.

I've used ngrok before and it's a great solution for quick tests. I guess this is an open-sourced version of that.

markstos said a year ago:

Thanks for clarifying that. I have occasionally had that need. Some protocols like SAML are actually doing in-browser redirects so they bypass that problem.

I'll bookmark this in case I have this need in the future.

tyrbo said a year ago:

I've been using https://github.com/fatedier/frp to expose UDP endpoints for a while. Works pretty well.

superasn said a year ago:

This looks very useful. I'm currently using localtunnel.me for this but will definitely give this a try too and subdomain option sometimes doesn't work on localtunnel.

alexellisuk said a year ago:

Yep, free TLS and free domains.. and it is completely open source. Contributions are welcome too.

ivolimmen said a year ago:

I just have port forwarding on my modem. Changed my aname record on my dns to point to my public IP of my modem. Technically I don't have a static address but until know (3 years?) I never needed to update it. Got my pine64 running an nginx with my java application behind it. Using let's encrypt for SSL certificates.

kingosticks said a year ago:

Sadly not possible for those of us poor souls stuck behind carrier-grade NAT. I do have an ipv6 range, but of course, there's no ipv6 connectivity from my workplace! And that's often where I want access from.

thomas536 said a year ago:

There are many of these so obviously it's useful for folks. What's your favorite use case? :D

jammygit said a year ago:

WRT setting up a desktop as a remote workstation, where can a person go to learn more about how it works? Is it just about setting up port forwarding on your router, then using a proxy to deal with the non-static IP?

Zaheer said a year ago:

I use https://localtunnel.github.io/www/

Simple and works well

beardedwizard said a year ago:

Ssh tunnels work well

corbinlc said a year ago:

I use http://holepunch.io Really stable. Also, much easier than this.

alexellisuk said a year ago:

It's not the same thing, you may as well use grok, it's just as limiting. https://holepunch.io/pricing

alexellisuk said a year ago:

Inlets is designed to be super easy to use, from provisioning the exit-node, to punching out for your first service / endpoint.

It'd be great some of the folks commenting to try the project and then bring some feedback via GitHub, Slack, Twitter etc.

What did you like? What would you like to see next? What can be improved?

nurettin said a year ago:

Is this different than setting up openvpn and serving with haproxy?

guipsp said a year ago:

Yeah, you don't have to setup openvpn and configure haproxy

nurettin said a year ago:

Is that the only difference?

alexellisuk said a year ago:

Try it :-) look at the video and how fast the connection is established.

nurettin said a year ago:

If I was going for "establish a connection as fast as possible" I'd go for `autossh -R`. Maybe "inlets" has better naming, is that the reason we need to use it?

MaconBacon said a year ago:

Really good name for this product.

anderspitman said a year ago:

Does it support Range requests?

W0lf said a year ago:

sounds a lot like smee.io to me?