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

Register a cloned VM as a separate node. #827

New Issue
Closed
opened 2025-12-29 02:24:32 +01:00 by adam · 4 comments
adam commented 2025-12-29 02:24:32 +01:00
Owner
Copy Link

Originally created by @plummo on GitHub (Oct 11, 2024).

Use case

Adding a Clone attribute to the node register to allow a cloned VM to be independently registered.

Description

I am working on making my headscale network secure by tunneling all internet access through a central gateway which includes certificate validations etc. This will include removing all external access with the firewall. There is a high chance I may lock myself out during testing and by cloning a VM it is a good way instead of snapshop etc or to fork a base image.

When a cloned vm is registered, it will have the same identifiers Headscale uses to register and will not be considered a unique or different node. By having the option to register the node as a clone, it will appear in the register list, have a unique Machine and Node key and IP and then allow Magic DNS to be used.

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

Happy to write the design doc. The simplest way I see this is by having a "cloned" attribute when running register or login command.

E.g. sudo tailscale up --login-server=[url] --accept-routes=true --accept-dns=true --force-reauth --clone

and headscale nodes register --user default --clone --key XXXXXXXXXXXXXX

This would identify the same machine and node key and add a flag to it such as [MvBR0-C] with C declaring it is cloned from the machine with same Key. This would not change the way the Machine key or Nodekey is generated as I understand it.

Originally created by @plummo on GitHub (Oct 11, 2024). ### Use case Adding a Clone attribute to the node register to allow a cloned VM to be independently registered. ### Description I am working on making my headscale network secure by tunneling all internet access through a central gateway which includes certificate validations etc. This will include removing all external access with the firewall. There is a high chance I may lock myself out during testing and by cloning a VM it is a good way instead of snapshop etc or to fork a base image. When a cloned vm is registered, it will have the same identifiers Headscale uses to register and will not be considered a unique or different node. By having the option to register the node as a clone, it will appear in the register list, have a unique Machine and Node key and IP and then allow Magic DNS to be used. ### Contribution - [X] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? Happy to write the design doc. The simplest way I see this is by having a "cloned" attribute when running register or login command. E.g. sudo tailscale up --login-server=[url] --accept-routes=true --accept-dns=true --force-reauth --clone and headscale nodes register --user default --clone --key XXXXXXXXXXXXXX This would identify the same machine and node key and add a flag to it such as [MvBR0-C] with C declaring it is cloned from the machine with same Key. This would not change the way the Machine key or Nodekey is generated as I understand it.
adam added the enhancementstale labels 2025-12-29 02:24:32 +01:00
adam closed this issue 2025-12-29 02:24:32 +01:00
adam commented 2025-12-29 02:24:32 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Oct 17, 2024):

sudo tailscale up --login-server=[url] --accept-routes=true --accept-dns=true --force-reauth --clone

This sounds like it needs changes to the Tailscale client, which is out of scope for this.

I think we dont really have the capacity into venturing down into the path of handling this case, I think time is better spent automating joining the newly cloned node.

@kradalby commented on GitHub (Oct 17, 2024): > sudo tailscale up --login-server=[url] --accept-routes=true --accept-dns=true --force-reauth --clone This sounds like it needs changes to the Tailscale client, which is out of scope for this. I think we dont really have the capacity into venturing down into the path of handling this case, I think time is better spent automating joining the newly cloned node.
adam commented 2025-12-29 02:24:32 +01:00
Author
Owner
Copy Link

@plummo commented on GitHub (Oct 18, 2024):

Valid point re Tailscale. I could suggest it for their client.

@plummo commented on GitHub (Oct 18, 2024): Valid point re Tailscale. I could suggest it for their client.
adam commented 2025-12-29 02:24:33 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 16, 2025):

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

@github-actions[bot] commented on GitHub (Jan 16, 2025): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:24:33 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 23, 2025):

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

@github-actions[bot] commented on GitHub (Jan 23, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
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 stale
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#827
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?