I suspect your friends probably don't need access to your whole media stack.
What parts they do need access to, and from what type of devices, will determine the best approach.
Seeing as you say port 25565 you're using Minecraft Java, so i'd prob just do this:
Couple of points:
-
Make your account PAYG to lessen likelihood of server being shutdown (will still be free)
-
Take nightly backups just in case.
You could stump up for a management console like AMP if you want to make things a bit easier.
GL.
Outside of fixing your SSH issues, you should also change from using 11.0.0.1 for WG as that's a public IP. See RFC1918.
I don't self host anything where it would impact me unduly if it went down while I was on holiday to the point where I'd have to break state and fix stuff.
A password manager falls in that camp so it's paid-for Bitwarden every night every day every possible way for me.
Sure Vaultwarden suits others - generally those who either want control of their data, smaller target on their back than a public instance user, watching their pennies etc.
You can either point the first proxy to the second proxy, or point it to the backends directly. Depends if you have firewalls in the way that stop the VPS proxy reaching your backends directly; or if that internal nginx instance is dong anything clever like handling auth, adding headers etc. etc.
In your instance I'd more likely have the VPS locked down and unable to access my internal resources and just open up its access to my internal nginx instance. Therefore chaining proxies would be my approach but there's no right or wrong.
I'd go for an ESP8266/ESP32 with a telegram bot and LED (based sign) hanging off it. Just send a msg on telegram to turn it on/off.
That having been said loads of ways to trigger the sign status - it could poll a website to see what status it should display and you have a mechanism of updating that status yadda yadda yadda.
Note that those little chips needs wifi so you'd need to be able to connect it to wifi and have it get public internet access (or whatever you decide to control it). Loads of posts/youtube exist about driving WS2812 LEDs, or making your own DIY LED 'neon' signs. Cool little projects.
I assume you already have DNS=192.168.0.1 defined in your client WG config (or whatever DNS server you use at home)?
Cloudflare Tunnel's cloudflared links your home to two closest data centres and so should (?) be quicker, but response times would depend on where a user is accessing your service from.
However, given residential ISP speeds and peering in most parts of the world you'd be unlikely to notice any real difference between the two and other than that 'last leg' access tech the processing within Cloudflare's flow is the same whether you use cloudflared or direct proxying.
Not sure why no one has pointed you to the actual product Cloudflare have for API security - Cloudflare API Gateway (and API Shield).
You can kinda-sorta-not-really fudge control with a combination of Access Policy (or exclusion rules for that) and Firewall Rules, or even tack on Access control via JWT etc if you want though.
Withuot any of those just consider it having been made 'public' to the internet at large and secure accordingly.
Please follow the /u/jerwong advice.
I know, I know 'BuT It's NOt seLFhOStEd!' but I just let the pros deal with bots and front that kind of stuff with Cloudflare.
If you've privacy concerns you can always have that one thing on a specific subdomain and only enable Cloudflare on that, whilst keeping the rest of your subdomains unproxied.
Alternatively can't you add a capture (again, giving up a bit of privacy).
view more: next ›
zfa
joined 1 year ago
AGH with upstream lookups over DoH, and adblock list from oisd.nl.
Split-brain topology to give internal IP in preference to public IPs for my selfhosted services, and selective routing of a defined set of domains to a geo-unblocking service so I can access things like BBC iplayer etc. from my home network.