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

[Feature] Support for derp's verify-client-url #714

New Issue
Closed
opened 2025-12-29 02:22:45 +01:00 by adam · 6 comments
adam commented 2025-12-29 02:22:45 +01:00
Owner
Copy Link

Originally created by @117503445 on GitHub (May 19, 2024).

Use case

When I deploy derp myself and don't want it to be used by other unauthorized clients, the traditional approach is to have derp access tailscaled to verify that the clientKey is in the list via derp's verify-clients parameter.

But I don't want to deploy tailscale on derp's nodes, and derp provides the verify-client-url parameter to determine if the clientKey is in the list via HTTP. I want Headscale to support this HTTP interface, so I can set derp's verify-client-url to the Headscale interface.

Description

See https://github.com/tailscale/tailscale/blob/964282d34f06ecc06ce644769c66b0b31d118340/derp/derp_server.go#L1159.

Derp sent a POST request to verifyClientsURL with the following JSON

{
  "NodePublic": "clientKey",
  "Source": "clientIP"
}

The expected return is

{
    "Allow": true
}

Contribution

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

How can it be implemented?

In Headscale, it could be to provide an HTTP interface that receives an authentication request, checks if the clientKey is in the list of nodes, and returns Allow.

Originally created by @117503445 on GitHub (May 19, 2024). ### Use case When I deploy derp myself and don't want it to be used by other unauthorized clients, the traditional approach is to have derp access tailscaled to verify that the clientKey is in the list via derp's `verify-clients` parameter. But I don't want to deploy tailscale on derp's nodes, and derp provides the `verify-client-url` parameter to determine if the clientKey is in the list via HTTP. I want Headscale to support this HTTP interface, so I can set derp's `verify-client-url` to the Headscale interface. ### Description See <https://github.com/tailscale/tailscale/blob/964282d34f06ecc06ce644769c66b0b31d118340/derp/derp_server.go#L1159>. Derp sent a POST request to `verifyClientsURL` with the following JSON ```json { "NodePublic": "clientKey", "Source": "clientIP" } ``` The expected return is ```json. { "Allow": true } ``` ### Contribution - [X] I can write the design doc for this feature - [X] I can contribute this feature ### How can it be implemented? In Headscale, it could be to provide an HTTP interface that receives an authentication request, checks if the clientKey is in the list of nodes, and returns Allow.
adam added the enhancementstaleneeds design doc labels 2025-12-29 02:22:45 +01:00
adam closed this issue 2025-12-29 02:22:45 +01:00
adam commented 2025-12-29 02:22:46 +01:00
Author
Owner
Copy Link

@ohdearaugustin commented on GitHub (May 20, 2024):

I think this would be a useful feature with a clear use case.

@ohdearaugustin commented on GitHub (May 20, 2024): I think this would be a useful feature with a clear use case.
adam commented 2025-12-29 02:22:46 +01:00
Author
Owner
Copy Link

@117503445 commented on GitHub (May 20, 2024):

I think this would be a useful feature with a clear use case.

I can try to contribute to this feature :)

@117503445 commented on GitHub (May 20, 2024): > I think this would be a useful feature with a clear use case. I can try to contribute to this feature :)
adam commented 2025-12-29 02:22:46 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (May 21, 2024):

Sounds good, but please write up a plan for it before you start coding too much.

@kradalby commented on GitHub (May 21, 2024): Sounds good, but please write up a plan for it before you start coding too much.
adam commented 2025-12-29 02:22:46 +01:00
Author
Owner
Copy Link

@117503445 commented on GitHub (May 25, 2024):

Sounds good, but please write up a plan for it before you start coding too much.

see #1957, I think this feature is relatively simple. We can start with a simple implementation and discuss what needs to be improved.

@117503445 commented on GitHub (May 25, 2024): > Sounds good, but please write up a plan for it before you start coding too much. see #1957, I think this feature is relatively simple. We can start with a simple implementation and discuss what needs to be improved.
adam commented 2025-12-29 02:22:47 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 26, 2024):

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

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

@github-actions[bot] commented on GitHub (Sep 2, 2024):

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

@github-actions[bot] commented on GitHub (Sep 2, 2024): 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 needs design doc 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#714
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?