starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Peering/federating between headscale instances #486

New Issue
Closed
opened 2025-12-29 02:18:57 +01:00 by adam · 1 comment
adam commented 2025-12-29 02:18:57 +01:00
Owner
Copy Link

Originally created by @infogulch on GitHub (Apr 21, 2023).

In Multi Server Support #588 kradalby said:

There are scenarios where multiple servers would make sense and allowing them to connect would also make sense:

  • Multiple headscale servers, allowing two companies/owners to share nodes between them

This is the use case that I am interested in. If this is solved correctly then it could also solve part of the redundancy/partition-tolerance use case.

Design

Based on general knowledge about how Tailscale and Headscale works, I suspect this design could solve the "sharing nodes" use case and also be reasonably implementable:

  1. ipv6-only (wait hear me out)
  2. Headscale allocates all addresses out of a /20, about ~1 million total
  3. The rest of the 108 bits are derived from a fingerprint of the control server's private key
  4. Independent headscale servers can opt-in to peer/federate with each other.
    • This would come down to accepting each others' private keys and domains, set by config file or something.
  5. New ACLs so that both control servers can manage access to and from each of their respectively owned nodes

There's no race conditions because severs allocate from different IP pools. 108 bits is enough to make benign collisions virtually impossible, with a clear workaround: one control server 'just' changes its private key and prefixes (I said the solution is clear, not easy). I'm guessing that on an actively updated network, 1M nodes is probably near the useful limit for a single headscale instance anyways.

Use cases

  • For me, I'd like for it to be easy to communicate privately and directly between me and my friends' devices without either of us giving up agency over our headscale control server. For example, if we meet at one of our homes or at a coffee shop we could securely taildrop a file over the local wifi.
  • For someone like 0n1cOn3 from the original issue, they could set up two separate headscale instances, one in each locale, and peer them. This will make their system tolerant to either side being down or the internet being partitioned, though it doesn't fix the local outage aspect of crashes.

Inspiration

This design is inspired by Yggdrasil Network. In contrast to Yggdrasil, this design retains more control over which nodes peer with each other, and completely sidesteps the entire Globally Synced Node Database problem and associated collision vulnerabilities. And then there are practical matters like performance... I will stop short of proposing that this could eventually grow into a global mesh network at the same scale as yggdrasil, not because its necessarily impossible but because these simple use cases are more relevant to the project at this time.

Thoughts?

Originally created by @infogulch on GitHub (Apr 21, 2023). In [Multi Server Support #588](https://github.com/juanfont/headscale/issues/588) kradalby said: > There are scenarios where multiple servers would make sense and allowing them to connect would also make sense: > > * Multiple headscale servers, allowing two companies/owners to share nodes between them This is the use case that I am interested in. If this is solved correctly then it could *also* solve part of the redundancy/partition-tolerance use case. ### Design Based on general knowledge about how Tailscale and Headscale works, I suspect this design could solve the "sharing nodes" use case and also be reasonably implementable: 1. ipv6-only (wait hear me out) 2. Headscale allocates all addresses out of a /20, about ~1 million total 3. The rest of the 108 bits are derived from a fingerprint of the control server's private key 4. *Independent headscale servers can opt-in to peer/federate with each other.* * This would come down to accepting each others' private keys and domains, set by config file or something. 6. New ACLs so that both control servers can manage access to and from each of their respectively owned nodes There's no race conditions because severs allocate from different IP pools. 108 bits is enough to make benign collisions virtually impossible, with a clear workaround: one control server 'just' changes its private key and prefixes (I said the solution is clear, not easy). I'm guessing that on an actively updated network, 1M nodes is probably near the useful limit for a single headscale instance anyways. ### Use cases * For me, I'd like for it to be easy to communicate privately and directly between me and my friends' devices without either of us giving up agency over our headscale control server. For example, if we meet at one of our homes or at a coffee shop we could securely taildrop a file over the local wifi. * For someone like 0n1cOn3 from the original issue, they could set up two separate headscale instances, one in each locale, and peer them. This will make their system tolerant to either side being down or the internet being partitioned, though it doesn't fix the local outage aspect of crashes. ### Inspiration This design is inspired by [Yggdrasil Network](https://yggdrasil-network.github.io/). In [contrast](https://yggdrasil-network.github.io/2019/03/25/peering.html) to Yggdrasil, this design retains more control over which nodes peer with each other, and completely sidesteps the entire *Globally Synced Node Database* problem and associated [collision vulnerabilities](https://yggdrasil-network.github.io/2018/07/28/addressing.html#addressing-in-yggdrasil). And then there are practical matters like performance... I will stop short of proposing that this could eventually grow into a global mesh network at the same scale as yggdrasil, not because its necessarily impossible but because these simple use cases are more relevant to the project at this time. Thoughts?
adam added the enhancementout of scope labels 2025-12-29 02:18:57 +01:00
adam closed this issue 2025-12-29 02:18:57 +01:00
adam commented 2025-12-29 02:18:58 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (May 10, 2023):

While we appreciate the suggestion, it is out of scope for this project and not something we will work for now.

@kradalby commented on GitHub (May 10, 2023): While we appreciate the suggestion, it is out of scope for this project and not something we will work for now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement out of scope
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#486
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?