Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
This feels like it has validated my decision to just use plain wireguard and hardcode my client list. It's really not too hard to set up, barely different that configuring authorized_keys or ssh.
Tailscale ssh isn't enabled by default and I for one don't see the need for it.
Your choice is valid, but you've chosen to be responsible for adding new clients everywhere and making sure they can all connect to each other, etc. you have simpler software but more manual work, which is a valid choice if you're up for it.
Also, I've never been able to understand how something exposed to the entire internet (a WG server) is considered more secure than something that only connects peers privately to each other.
The attack surfaces are nothing alike.
Even if you limit access to WG with IP blocking there's still no comparison to something you can't access at all from outside.
I don't see it as there being much of a distinction from the two when you say one is public and the other isn't, i don't really see it that way. Wireguard may be more obviously public, but they both technically are, right? Otherwise accessing a node just wouldn't be possible.
If you don't need something specific that tailscale offers, then wireguard offers probably better security.
Tailscale uses wireguard, but using wireguard itself is removing all of the extra code and services (their connection facilitation layer?) that go with using tailscale.
Tailscale probably isn't an inconsiquential amount of code added, so it can be a threat, even if it adds additional security layers (identity?). There's more code to exploit.
Plus, wireguard is so well used directly by so many businesses, orgs and people who NEED it to be secure, and it has so many more eyes going over it that it I can't see any way that it would be less secure.
Edit: have never used tailscale cuz i dont need it, so maybe im completely wrong about something, dont think i am tho im confident
There is something exposed to the Internet in both cases, yes, but it works very differently.
With WG it's a client-server pattern; the server exposes a port, waits for authorized clients to connect, and when a client connects successfully the server routes their connections into the private LAN with everything that entails.
With TS the public part is a supplier of control configurations and client pairing service. The pairing service needs to be contacted by two authorized clients in order to negotiate a connection between them. Once that's done, it's the clients that route each other's connections into their respective LANs, the pairing server is not involved anymore.
In other words the TS public surface is not WG, it's their (proprietary) client verification and matching service. The WG connections between clients happen later, privately.
To me, separating client authentication from routing and transport looks like a better design, because it's multi-layered. You get the normal WG authentication and another layer on top.
"Security" is a relative term. It's better to think in terms of attack surface, exposure, whether attacks are targeted or not etc. Which are all ongoing factors.
Both TS and WG are popular and being used by lots of people but it's also important for them to be actively maintained, independently audited, maintain transparency etc.
This is pedantics, but technically what you are talking about can be achieved with wireguard too. You are talking about using STUN/TURN to do NAT holepunching to establish a connection between two wireguard clients.
Wireguard is just the vpn protocol. Tailscale even uses it. How the connection is established, is up to the user. So what you're really talking about is Tailscale vs "how most people set up Wireguard".
The reason why I make this distinction is because it would be nice if somebody made an easy self-hosted way to do the STUN/TURN stuff for plain wireguard.
There's Headscale, but it can't be fully selfhosted because you need an external host if both clients are behind NAT.
afaik Headscale is designed for Tailscale and not plain Wireguard. It's overkill for plain wireguard.
I mean, "plain WG" doesn't have the ability to connect multiple sites seamlessly, nevermind from behind NAT. That's what Headscale/Tailscale do, they enable multiple WG backends to connect together on the fly into a common VLAN, with almost zero extra config.
It may seem overkill if you only want to connect two sites but once you solve this problem for 2 it's basically also solved for N so why not take advantage of the capability.
Doesn't Tailscale do a lot more, like ACLs and tailnet lock and a web ui and everything? I thought Headscale was trying to provide the same, though I admit I've never tried it myself
It does, there's a lot of features and UI added on top of it because it's primarily an enterprise-oriented service and large companies tend to have a lot more complex usage scenarios than self-hosters.
Headscale is a FOSS reimplementation from scratch of some of the Tailscale proprietary features. It's inteded as a fallback option for Tailscale users in case the Tailscale service ever enshittifies, and also as a canary for ongoing verification of the Tailscale claim that the client plane functionality is entirely FOSS and above-board.
Speaking of which, Tailscale today is a great example of a company using FOSS well. They are able to provide commercial services and have proprietary code while at the same time opening the client-facing code so users can see for themselves their privacy is cryptographically proven. They also cooperate very well with Headscale and provide a generous gratis service tier.
My issue with Headscale is that it seems like they are providing a very complex product and haven't had any security audits (at least last I checked)...
Wireguard is nice because it is very simple, and thus has a much smaller attack surface.
In my configuration I have a server with a public IP that manages incoming connections, and my home network connects to that server via a keepalive connection, so it's actually operating in the same client-server mode you described going through my NAT. This also solves the dynamic IP issues.
When I'm at home, my phone can route directly over my LAN, and when I leave the house it proxies through my public server back to my house (or out to the web depending on what I'm accessing).
That's one of my TODOs on NixOS but I keep procrastinating on that. Today I finally set up adguard home locally on my PC and I want to make it available as a VPN(?) on my phone so I may finally get around to doing that soon-ish. I have zero clue how any of that works or how to set it up, however. Lol
This seems like a decent guide on how to set it up:
https://www.cyberciti.biz/faq/how-to-set-up-wireguard-firewall-rules-in-linux/
It's very similar to the config I've got. The nat iptables stuff in step 1 is what enables wireguard to be used as a VPN exit node. (+ net.ipv4.ip_forward=1)
The only downside is that it's not redundant. I wish it was, somehow.