feat: support client verify for derp #1957
Conversation
|
Nothing looks outrageous, but we need a way to test this, is there a way you can run a |
| @@ -485,6 +485,8 @@ func (h *Headscale) createRouter(grpcMux *grpcRuntime.ServeMux) *mux.Router { | |||
| router.HandleFunc("/swagger/v1/openapiv2.json", headscale.SwaggerAPIv1). | |||
| Methods(http.MethodGet) | |||
|
|
|||
| router.HandleFunc("/verify", h.VerifyHandler).Methods(http.MethodPost) | |||
There was a problem hiding this comment.
maybe this should be under the derp router further down since it is only relevant if we run a derp?
There was a problem hiding this comment.
No, helping other derps verify and running headscale build-in derp are two different things. Even without activating the built-in derp, headscale can still help other derps verify whether the client is in the nodelist.
In my own use case, my cloud server is more stable but has less bandwidth, while my homelab has more bandwidth but is often unavailable. Therefore, I install headscale on the cloud server but do not enable the built-in derp, and install derp in my homelab. At this point, I want the homelab's derp to access the cloud server's headscale via a verify-url to avoid unauthorized access to the derp.
117503445
force-pushed
the
117503445/verify-client
branch
from
fdb00de to
5c11b3b
Compare
|
I encountered an unresolved issue. In my testing, I created a DerpClient and DerpServer, setting the VerifyClientURL of the DerpServer to the Verify interface of Headscale. When a DerpClient created with a new privateKey attempts to connect to the DerpServer, the connection is rejected, which is the expected behavior. However, I am unable to obtain the privateKey of the connected node, so I cannot create a legitimate DerpClient, resulting in a failure to pass the verification. |
|
Does that mean there is an issue in derp, tailscale client or headscale? |
117503445
force-pushed
the
117503445/verify-client
branch
2 times, most recently
from
4117795 to
c450e2f
Compare
Signed-off-by: 117503445 <[email protected]>
117503445
force-pushed
the
117503445/verify-client
branch
from
c450e2f to
89e6c40
Compare
|
Now that I've solved the problem of testing, PR Ready |
|
@kradalby If the code no longer requires modifications, I can begin writing the documentation and |
|
any news here? it would be fantastic if this feature made it into the next version |
|
I found this feature useful to me. Is there something I can help to push the process? |
I compiled and used it on my own branch and had a good experience using it. I also hope this change will be merged. |
|
Im sorry, we are completely overrun, I have not had time to look carefully but it looks like this is still missing an integration test for the client. The test implemented checks the web endpoint from a http request, which is also good, but for us to merge this, it needs to be verified using the Tailscale client, not our code. I don't know how that should look, maybe a tailscale client not joined to the Headscale client (and therefore not authorised to use the derp) that fails. We are not able to take on the burden of untested code. |
|
merged by #2046 |
|
How to Use? It seems that the 0.24.0 document does not provide any information on this. |
I have initially implemented the verification function. Derp can verify whether the client is in the node list of headscale by specifying the
--verify-client-urlparameter to/verifyin headscale.I know there is still a lot of work to be done, such as comments, testing, documentation, etc. I am also willing to participate in the subsequent work.
Fixes #1953