Closed networkhermit closed 4 weeks ago
Sorry, but this isn't a use case we want to support.
You're welcome to modify the Tailscale client or derper code for your own use.
Could you elaborate a bit more? As this feature is regularly brought up by other users.
If the official reponse to this feature is "make your own fork", then related issues in the future could get linked to the explanation.
People running their own DERP servers is a constant source of support costs for us. We provide the source code for transparency reasons and in theory it saves us money if people run their own, and it's better for users if their DERP servers are lower latency and close to them. So we do, and it's open source, and we support custom DERP servers.
And yet: so many people run them in bizarre unsupported ways and come to us for help, which we spend lots of time helping with.
We do not want yet another possible configuration to support and maintain in the code base, especially for something so fringe: LetsEncrypt is free, and domain names are often nearly free. So I'm skeptical there's enough demand for this feature to justify the various costs.
LetsEncrypt is free, and domain names are often nearly free. So I'm skeptical there's enough demand for this feature to justify the various costs.
In some countries, domains without an ICP license are not permitted to provide web services. For individual users, obtaining an ICP license can be extremely cumbersome.
https://en.wikipedia.org/wiki/ICP_license
For these users, supporting deployment of self-signed certificates based on IP would be extremely convenient.
What are you trying to do?
Not everyone has a domain name plus dns hosting. It's more accessible for users if we support using self-signed ip-only certificate in custom DERP server (just like k8s 6443 tls).
This issue had been brought up by #3647 and partially in #4082.
This feature is kind of implemented by a fork, ip_derper (which is regularly updated and just adding the patch for ip-based certificates):
https://github.com/yangchuansheng/ip_derper/blob/936de2789923d81b9eab538b50f124110dee6f9b/.github/workflows/main.yml#L21-L24
The above modification is not ideal for users who want to use domain-based tls certificates. I think some more appropriate minor fix could be the following: https://github.com/tailscale/tailscale/blob/226486eb9ae90a32c3bb6857b9dbc3dec605597c/cmd/derper/cert.go#L90-L93
So we could support well both domain-based certificates and the ip-based ones.
How should we solve this?
No response
What is the impact of not solving this?
Separate fork keeps patching this feature and some users fallback to that.
Anything else?
No response