feat: add coturn TURN support

[nslsrv]

Coturn support allows to use own TURN service in self-hosted deployments.
As with Cloudflare, it's used only on client side (client side is responsible for managing relay).
Current cloud-api interface supports only one credentials set, so it's either Cloudflare or coturn, and Cloudflare configuration takes precedence.

[nslsrv]

Hi, @adamshiervani, just checking in on this PR. I believe this kind of functionality could beneficial for JetKVM users.

Could you please find some time to review this PR? Is there something I can do to help move this forward? Thank you.

[pietheinstrengholt]

@nslsrv, does this really work? I also plan on using coturn.

[nslsrv]

@nslsrv, does this really work? I also plan on using coturn.

@pietheinstrengholt Yes, it works, I use it to stay independent from Cloudflare. Using my fork currently, which includes this patch, but I'd be happy to merge it to upstream eventually and drop the fork.

[pietheinstrengholt]

@nslsrv , may I ask for some help. I used your fork. What I want to achieve is a self-hosted JetKVM remote-access setup with a local Cloud API and coturn, mainly to make WebRTC work from restrictive corporate/hotel networks where normal TURN ports are blocked but TCP 443 is allowed.

What I have done so far:

• Deployed the JetKVM Cloud API locally with Docker/PostgreSQL and exposed it through nginx over HTTPS.
• Configured Google OIDC for the self-hosted Cloud API, including custom OAuth client credentials, callback URL, cookie secret and allowed identity.
• Verified the OIDC flow works and the Cloud API can create/adopt the device. At one point the device successfully connected back to the self-hosted Cloud API and the API logged a new device WebSocket connection.
• Configured coturn locally using use-auth-secret / static-auth-secret and matched that with COTURN_TURN_SECRET in the Cloud API.
• Verified plain TURN locally on TCP/UDP 3478 using turnutils_uclient; allocations succeeded and coturn returned public relay addresses.
• Added TLS support to coturn on 5349 using a valid Let’s Encrypt certificate and verified TURN/TLS allocation directly against coturn.
• Added a dedicated TURN hostname and configured nginx stream SNI routing so TURN/TLS traffic can share public TCP 443 with normal HTTPS traffic.
• Because TCP 443 was already multiplexed with sslh for SSH/HTTPS, changed the chain to:
  Internet:443 -> sslh -> nginx stream -> either normal HTTPS or coturn TLS.
• Verified nginx SNI routing works:
  normal application hostnames are routed to the HTTPS backend;
  the TURN hostname is routed to coturn on 5349.
• Verified the TURN hostname certificate is valid and the full TLS chain works through the public hostname.

Where I am currently stuck is the device adoption / frontend integration. Using the official app.jetkvm.com frontend with a self-hosted Cloud API fails because the official frontend/OIDC flow is tied to the official JetKVM backend.

I did not find any documentation in your repo. Perhaps, could you list out the steps that must be taken to setup a fully managed self-service environment. Would be much appreciated. Once, I have things working I plan to publish a wiki or document describing how to use your fork.

[pietheinstrengholt]

@nslsrv , I have it working. It is quite a lot of configuration steps you need to follow. Here is a runbook for others that would like to achieve the same: https://gist.github.com/pietheinstrengholt/e1ffa7542979bcca3ce81da28d966795