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.
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].
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'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.
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.
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.
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.
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
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.
>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.
> 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".
"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."
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.
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.
