Inter-controlplane federation

[ckiee]

Use case

Hi! Currently I cannot use headscale, because I like to share my machines with friends who are on controlplane.tailscale.com. They are using a network effect, and it prevents me from accessing a good feature like infinite/automatic key expiry which I currently have to rotate every 90d even though I do not personally require this.

Description

I would like headscale instances to be able to talk to eachother, and to the tailscale.com CP — specifically for device sharing across controlplanes.

Our control plane will be provided with an authkey for an another controlplane, which it will use to create "proxy machines", replicating our machines' view of the world, but on another instance.

Me, a [headscale.]puppycat.house tailnet/user will be able to talk to tailscale.com:

• My headscale instance is configured with user accounts on other *scale instances.
• headscale nodes share -i … --to tailscale.com or [headscale-blub.]example.com (another headscale)
• I am given a share link for my machine's virtual clone on this other instance, which I give to my friend
• My friend accepts this invite to "my" machine, and starts sending traffic.
• The connection is established on their controlplane, which my controlplane is a client to.
• The controlplane-acting-as-client receives this, and rewrites their messages to my controlplane -- while adding a suffix to their machine name (same as current intra-CP sharing on tailscale.com: their-machine.their-tailnet.ts.net, we would have their-machine.their-user.headscale.example.com)
• The rest of the port punching protocol proceeds normally, and the users of the machines cookiemonster.ckie.headscale.puppycat.house and deep-space-probe.snake-beaver.controlplane.tailscale.com are happy because they just connected to eachother (Note: We have to ensure we have intersections in the two instances' DERP lists, otherwise it will be sad and randomly fail when we have to fallback.)

Contribution

• [X] I can write the design doc for this feature
• [X] I can contribute this feature

Drawbacks to consider

• [x] We might break our social contract with tailscale, as this removes some dependence on tailscale.com. Probably not a big deal since we don't have SSO/SCIM/MDM/audit logs, and those seem like the bigger ticket items for corps than self-hosted federation between multiple controlplanes which really changes nothing for centralized orgs. So this only benefits people socially, and they will still move to the corporate controlplane if they already were going to before.
• [ ] This complicates the design workload of the controlplane.
• [ ] This can create a very ugly protocol if we do not seriously walk through it before jumping into impl.

Alternatives to consider

We could extend the controplane↔client protocol to allow for more on-band network management and make this bridge a separate component that can be ran anywhere. This would keep headscale lean but introduce a bazillion other considerations that we wouldn't need when we are the controlplane. Still, it is possible.

[nadongjun]

I’m also looking for a similar feature. It seems that Tailscale’s configuration might allow for merging tailnets. Do you have any updates on this?

Related resources:

• https://gist.github.com/drio/b90b772a2857e873bf95214841ee95d1
• https://github.com/tailscale/tailscale/issues/183

[ckiee]

Those two links seem to be running two tailscaled's which while working around the problem does defeat the point of this (and you can see the two concurrent instances struggle a bit to both config the host)

Currently I am waiting for some validation from @juanfont, et al. before I dive in at some unknown point (^:

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.