If someone's interested, this blog was very helpful: https://www.procustodibus.com/tags/wireguard/
The tailscale daemon/CLI/client code is already open source and works with the above as the control server.
The tailscale team appear to be encouraging development of headscale too:
"Our opinion is that Headscale provides a valuable complement to Tailscale: It helps personal users better understand both how Tailscale works and how to run a coordination server at home. As such, Tailscale works with Headscale maintainers when making changes to Tailscale clients that might affect how the Headscale coordination server works, to ensure ongoing compatibility."
> https://tailscale.com/opensource/
Personally I find WireGuard and tailscale/headscale to be extremely complementary, and with these you don't cede any control vs running WireGuard on its own.
Besides, Wireguard alone already does all I need from a mesh VPN. The UX could be a bit better, but I wouldn't trade ease of use for the peace of mind that my VPN traffic is secure.
Though doing this "well" is subjective, so I can understand someone preferring Tailscale because it's easier to use.
if your access concentrator (server) is behind a nat, you'll need a port-forwarding from the outside but that's rare.
For example, you can set ACL rules for which devices can access which others (or the internet, if you have explicit exit nodes) - it's using Wireguard for networking, but you can't do that with (just) Wireguard, it's not just 'make Wireguard easier to set up', as you said that doesn't really need doing.
There's value to some to having networking config centralised like that. It allows things like auto adding certain clients to certain rules/groups automatically.
Not spending time cycling through each server to poke iptables.
This is just irrational. The client is open source. You can build it and run it from source.
The sentence following the one about phoning home/leaking data explains the rationale. The computer user prefers simpler software. It's great that it's possible to compile a client provided by Tailscale from source, but this does not address the complexity issue.^1
Is the Tailscale control server open source. Why not. What's the rationale for that.
There's no problem IMHO with arguing Tailscale can make its own decisions and do whatever it wants. However the same argument must apply to the computer user. He can make his own decisions and do whatever he wants.
1. Wireguard was allegedly written at least in part because OpenVPN, another open source option, was excessively complex. Tailscale relies on Wireguard. If avoiding complexity was irrational, and people behaved rationally, then perhaps Wireguard would not have been written and Tailscale would not exist.
Avoiding complexity where possible sounds rational to me.
The official reason for why there's no official open source server is that headscale got there first, before tailscale team could (their words, not mine) the unholy mess that was the production server into something people could compile and deploy themselves.
Even so, software being open source doesn't make it inherently trustworthy. I would have to look into it, or trust that the community has done due diligence. My default stance towards all software is to not trust it, which can change as I get familiar with the project.
And then there's the complexity. I prefer using simpler tools if they accomplish what I need. It's less surface area for me to trust, and less chances for bugs. Not that Wireguard is necessarily simple, but since Tailscale is a wrapper around it with additional features, none of which I need, I'm perfectly fine using WG directly.
Something I don’t understand is if the client is open source, why is it not in the fedora repos? Why do I need to add a new repo to dnf?
Just because one group of people haven't done something doesn't mean it doesn't qualify. To show the exact opposite, look at OpenBSD. They have included Wireguard into their kernel.
Fedora not including Wireguard may be political, personal, or none-of-the-above. Maybe somebody hasn't offered to take on that task/responsibility.
The master config is essentially the Fabric script. It contains each servers IP, public key, etc. We even do server-server pre-shared keys.
I tried installing headscale. I didn't feel like I got the immediate rush of "cool, I have the baseline thing working" without reading the docs. And, I needed to use this for a GUI: https://github.com/gurucomputing/headscale-ui. I love the command line and am happy to use that, but I'm unsure if there is a benefit to headscale over wireguard if I'm already doing command line management.
I just read this article on tailscale vs. openziti and it mentioned netmaker (a YC company). I tried installing it, but out of the box, the "DNS" did not seem to work correctly (I could not use the machine.netmaker local alias, and not sure why not).
Is anyone here a power user that also benefits from a full fledged GUI? Is tailscale the only option there? I prefer to self-host whenever I can, despite loving tailscale and the people behind it.
But one thing that Tailscale didn't do well (at least early on) is performance. It's user space Go, which seemed to cap the data transfers when I tested it out. I would prefer a really fast data transfer P2P so I could use Tailscale in between my web server and DB.
Compared to another VPN? I’d be curious to know whether the kernel mode byte shuffling solves that problem. But even so, a kernel module is a pretty big ask only for connectivity.
In my experience, UDP in general isn’t as performant in practice as one would think. Not saying you can’t push the limits, and even outperform TCP, but to do so with a reliable cross platform way isn’t exactly trivial today.
All my benchmarks (albeit user space) have shown that pushing bytes over udp has a higher CPU overhead, and that’s even if you omit retransmission, congestion control, etc etc (ie just push garbage bytes). And even if your cpu can handle the throughput, the congestion control can still bite you for god knows what reason. When I ran quic benchmarks they got deprioritized in the presence of tcp traffic. Don’t know all the reasons why (sorry, just didn’t have the time) but at least to me TCP wins the bang-for-the-buck-throughput-on-commodity-hardware category, hands down. Maybe this changes with platform-specific optimized vectored IO, but that alone would be a huge effort. No, the more time I spent on it, the more I appreciated all the things TCP gives me for free, and it’s remarkable resilience in complex conditions. I am also happy I don’t have to worry about bulky 3p libraries. This is what the OS is supposed to do, imo. So this UDP-hype-renaissance we’ve seen over the last years is a bit premature or at least not as obvious as people hoped (including myself).
Another fun fact (for anyone who read this far): contrary to popular belief p2p TCP isn’t harder to do than UDP, not really.
Another thing I wondered about is how much CPU overhead VPNs add, and how it performs when maximizing throughput. (Not Tailscale but a “regular” one with kernel packet switching). Do you have any experience with that?
> VPNs that use TCP as the transport layer could try and special case TCP handling and treat them as a flow and just transport the TCP data streams instead
Yes! An interesting observation is that TCP composes really well, ie relaying works excellent. However, for VPNs it’d be nesting TCP which melts down quickly.
To be clear, nothing specific to Tailscale right? Just generic prudence?
There is a third-party OSS server they let the official client work with. Similar to Bitwarden/Vaultwarden.
I don't usually do admin stuff nor I unfortunately know much about network setups nor I know about the specifics of tailscale setup.
I tried the open source tailscale alternative netmaker which is quite nice but in the end I found it unnecessary for my 5-6 hosts since the wireguard stuff for me is basically set-it-and-forget-it. (I chose netmaker because it also uses wireguard.)
If you always go to your own vps then that IP address is tied to you, typically via a credit card.
use those to pay for VPNs, like PIA or Mullvad.