There was a popular post less than a month ago about this recently >>46305585
I agree maintaining wireguard is a good compromise. It may not be "the way the internet was intended to work" but it lets you keep something which feels very close without relying on a 3rd party or exposing everything directly. On top of that, it's really not any more work than Tailscale to maintain.
This incident precisely shows that containerization worked as intended and protected the host.
Containerizing your publicly exposed service will also not protect your HTTP server from hosting malware or your SMTP server from sending SPAM, it only means you've protected your SMTP server from your compromised HTTP server (assuming you've even locked it down accurately, which is exactly the kind of thing people don't want to be worried about).
Tailscale puts the protection of the public portion of the story to a company dedicated to keeping that portion secure. Wireguard (or similar) limit the protection to a single service with low churn and minimal attack surface. It's a very different discussion than preventing lateral movement alone. And that all goes without mentioning not everyone wants to deal with containers in the first place (though many do in either scenario).
That's where wg/Tailscale come in - it's just a traditional IP network at that point. Also less to do to shut up bad login attempts from spam bots and such. I once forgot to configure the log settings on sshd and ended up with GBs of logs in a week.
The other big upside (outside of not having a 3rd party) in putting in the slightly more effort to do wg/ssh/other personal VPN is the latency+bandwidth to your home services will be better.
I am sure there must be an Iphone app which could probably allow something like this too. I highly recommend more people take a look into such workflow, I might look into it more myself.
Tmate is a wonderful service if you have home networks behind nat's.
I personally like using the hosted instance of tmate (tmate.io) itself but It can be self hosted and is open source
Once again it has third party issue but luckily it can be self hosted so you can even have a mini vps on hetzner/upcloud/ovh and route traffic through that by hosting tmate there so ymmv
I would argue OpenVPN is easier. I currently run both (there are some networks I can’t use UDP on, and I haven’t bothered figuring out how to get wireguard to work with TCP), and the OpenVPN initial configuration was easier, as is adding clients (DHCP, pre-shared cert+username/password).
This isn’t to say wireguard is hard. But imo OpenVPN is still easier - and it works everywhere out of the box. (The exception is networks that only let you talk on 80 and 443, but you can solve that by hosting OpenVPN on 443, in my experience.)
This is all based on my experience with opnsense as the vpn host (+router/firewall/DNS/DHCP). Maybe it would be a different story if I was trying to run the VPN server on a machine behind my router, but I have no reason to do so - I get at least 500Mbps symmetrical through OpenVPN, and that’s just the fastest network I’ve tested a client on. And even if that is the limit, that’s good enough for me, I don’t need faster throughput on my VPN since I’m almost always going to be latency limited.
It's worth an assessment of what you _think_ running ssh on a nonstandard port protects you against, and what it's actually doing. It won't stop anything other than the lightest and most casual script-based shotgun attacks, and it won't help you if someone is attempting to exploit an actual-for-real vuln in the ssh authentication or login process. And although I'm aware the plural of "anecdote" isn't "data," it sure as hell didn't reduce the volume of login attempts.
Public key-only auth + strict allowlists will do a lot more for your security posture. If you feel like ssh is using enough CPU rejecting bad login attempts to actually make you notice, stick it behind wireguard or set up port-knocking.
And sure, put it on a nonstandard port, if it makes you feel better. But it doesn't really do much, and anyone hitting your host up with censys.io or any other assessment tool will see your nonstandard ssh port instantly.
Now, I do agree a non-standard port is not a security tool, but it doesn't hurt running a random high-number port.
One less setup step in the runbook, one less thing to remember. But I agree, it doesn't hurt! It just doesn't really help, either.
As someone who spent decades implementing and securing networks and internet-facing services for corporations large and small as well as self-hosting my own services for much of that time, the primary lesson I've learned and tried to pass on to clients, colleagues and family is:
If you expose it to the Internet, assume it will be pwned at some point.
1. No software is completely bug free and those bugs can expose your service(s) to compromise;
2. Humans (and their creations) are imperfect and will make mistakes -- possibly exposing your service(s) to compromise;
3. Bad actors, ranging from marginally competent script kiddies to master crackers with big salaries and big budgets from governments and criminal organizations are out there 24x7 trying to break into whatever systems they can reach.
The above applies just as much to tailscale or wireguard as it does to ssh/http(s)/imap/smtp/etc.
I'll say it again as it's possibly the most important concept related to exposing anything:
If you expose it to the Internet, assume that, at some point, it will be
compromised and plan accordingly.
Want to expose ports? Use Wireguard? Tailscale? HAProxy? Go for it.
And do so in ways that meet your requirements/use cases. But don't forget to at least think (better yet script/document) about what you will do if your services are compromised.
Because odds are that one day they will.