If you're interested in self-hosting your orchestration server, you can look into Netbird. It's a very similar tool, but has the server open sourced as well. So you have a self-hosted control server with a nice GUI and all the features the paid version does. https://netbird.io/knowledge-hub/tailscale-vs-netbird
Does it do the fancy NAT-traversal Tailscale does?
An open source, self-hosted implementation of the Tailscale control server
61–70 of 85 posts
Re: An open source, self-hosted implementation of the Tailscale control server
#62Earlier quoted context omitted.
Tailscale clients are the thing I am least happy about with Tailscale. Specifically mobile clients and battery usage. The reason I can't use Tailscale at work is because it routes traffic through servers we can't control. I would _love_ to use tailscale at work. It would solve so many problems. I am okay with being forced to open ports. But tunneling traffic through them is extremely worrysome.
> Specifically mobile clients and battery usage. yes. Battery usage is super bad, mainly because of their DNS features which forces every DNS resolution to go through their network extension. At least recent updates have stopped the background power usage when you disconnect from the network in the app. >But tunneling traffic through them is extremely worrysome. it only does that in case of super bad NATs that make t…
On the battery topic I’m curious if you have anything more than anecdotal evidence. A basic full tunnel wg network extension doesn’t affect battery in a noticeable or unacceptable way, in my experience. Is tailscale’s implementation doing more in a way you can isolate and attribute to poor battery?
Re: An open source, self-hosted implementation of the Tailscale control server
#63Earlier quoted context omitted.
> Specifically mobile clients and battery usage. yes. Battery usage is super bad, mainly because of their DNS features which forces every DNS resolution to go through their network extension. At least recent updates have stopped the background power usage when you disconnect from the network in the app. >But tunneling traffic through them is extremely worrysome. it only does that in case of super bad NATs that make t…
On the battery topic I’m curious if you have anything more than anecdotal evidence. A basic full tunnel wg network extension doesn’t affect battery in a noticeable or unacceptable way, in my experience. Is tailscale’s implementation doing more in a way you can isolate and attribute to poor battery?
I can see it (tailscale) in my battery usage on multiple devices. 20 hours of background usage per day is a bit much if you ask me.
Re: An open source, self-hosted implementation of the Tailscale control server
#64Earlier quoted context omitted.
> Headscale seems to have nailed down the part of bypassing the firewall and doing fancy NAT-traversal Did they really roll-their-own for those functions? I thought this was just a control layer on top of Tailscale’s stock services on the backend, are they facilitating connections with novel methods? Apologies if I’m asking obvious questions, I use ZeroTier pretty regularly, but I am not too familiar with Tailscale.
Can you share why you use ZeroTier over Tailscale? I run several headscale control planes and it really is nice to self-host. But, I'm curious about other options.
Not OP but I'm on ZeroTier because it was one of the best free tiers available before Tailscale could run as a Windows service.
Also I believe it implements a lower layer of the network stack so more options are supported, though I haven't needed to investigate in detail.
Re: An open source, self-hosted implementation of the Tailscale control server
#65I think it would be neat if headscale allowed peering / federating between instances. (Maybe after the ACL rework.) One of the main problems is address collisions.
So here's my proposal: commit to ipv6-only overlay network in the unique local address (ULA) range, then split up the remaining 121 bits into 20 low bits for device addresses (~1M) and 101 high bits that are the hash of the server's public key. Federate by adding the public key of the other instance and use policy and ACLs to manage comms between nodes.
I think it's a nice idea, but the maintainer kradalby said it's out of scope when I brought it up in 2023: https://github.com/juanfont/headscale/issues/1370
Re: An open source, self-hosted implementation of the Tailscale control server
#66Earlier quoted context omitted.
On the battery topic I’m curious if you have anything more than anecdotal evidence. A basic full tunnel wg network extension doesn’t affect battery in a noticeable or unacceptable way, in my experience. Is tailscale’s implementation doing more in a way you can isolate and attribute to poor battery?
I can see it (tailscale) in my battery usage on multiple devices. 20 hours of background usage per day is a bit much if you ask me.
FWIW: On iOS 18.4 my Battery report for the last 10 days is ~128h of background activity, using ~2% of my battery life.
Re: An open source, self-hosted implementation of the Tailscale control server
#67Earlier quoted context omitted.
From https://github.com/tailscale/tailscale "This repository contains the majority of Tailscale's open source code. Notably, it includes the tailscaled daemon and the tailscale CLI tool. The tailscaled daemon runs on Linux, Windows, macOS, and to varying degrees on FreeBSD and OpenBSD. The Tailscale iOS and Android apps use this repo's code, but this repo doesn't contain the mobile GUI code." and "The macOS, iOS, and…
Thanks, I stand corrected then! Android client is open source (and you can get in from F-Droid, even), so that only leaves iOS I guess.
Yep, Tailscale takes a pretty reasonable approach to that IMHO. Open source on platforms that are open source. I think that works out pretty well because it meets people where they are. For example the people who care about open source (and thus are running linux or android) get their open source needs met, and people who don't care about open source strongly or at all (as evidenced in part by them running closed/proprietary OSes) such as mac or windows users are also met where they are. Of course this also helps protect their business model because then competitors can't just take the open source versions and run off with them, and the number of linux users is quite small compared to mac and windows so it keeps the majority of the client closed while still providing the openness to those who truly care about it.
*In my perfect world everybody would care about open source, but the evidence is pretty clear that only a tiny minority of people actually do, even among engineers
Re: An open source, self-hosted implementation of the Tailscale control server
#68How much is the risk of my devices being compromised if Tailscale coordination server is compromised, and tailnet lock is enabled?
Re: An open source, self-hosted implementation of the Tailscale control server
#69"To me, not giving your Tailscale implementation any way for the user to understand or veto what the control server is instructing the clients to do while also not auditing your servers code at all sure seems daring..."
This statement sugggests that publishing the Headscale control server source code is not enough to allow the user to "understand or veto what the control server is instructing the clients to do".
If using the Headscale control server, the user can "understand or veto" anything "the control server is instructing the clients to do". This may be accomplished by reading, editing and compiling the source code.
If using the Tailscale control server, the user can only "understand or veto what the control server is instruction the clients to do" to the extent that the Tailscale company permits. The user is prohibited from editing or compiling the source code.
Not all users want the option to read, edit and compile third party software that they use. Some users may be comfortable relying on the ongoing assurances of companies funded by Silicon Valley VC. For those users that want the option of 100% open source projects, not dependent on venture capital, Headscale can be useful.
The author of Headscale calls the Tailscale coordination server "essentially a shared dropbox for public keys".
Re: An open source, self-hosted implementation of the Tailscale control server
#70Earlier quoted context omitted.
Can you share why you use ZeroTier over Tailscale? I run several headscale control planes and it really is nice to self-host. But, I'm curious about other options.
Not OP but I'm on ZeroTier because it was one of the best free tiers available before Tailscale could run as a Windows service. Also I believe it implements a lower layer of the network stack so more options are supported, though I haven't needed to investigate in detail.
More ZeroTier 3 years ago: https://news.ycombinator.com/item?id=30283987#30284754