Show HN: An Almost Free, Open Source TURN Server
I have been messing around with WebRTC for a few years now but when it comes to the TURN server I never quite got to my gold standard of free, self-hosted and open source. I decided to give it a go using Oracle Cloud Infrastructure's free tier, meaning that my total spend got down to domain name hosting. I know plenty of people have been burnt by Oracle in the past, but I have had servers running on the free tier for 5 years now without so much as a hiccup. Regardless, the concepts will be the same using any cloud based server.
This is the first time I've written up an end-to-end technical how-to like this and the audience I am writing for is really myself - I know just enough about networks and web dev and Linux, etc to get all this running and there are plenty of snippets out there on the web that tell you how to do one thing or another, but nowhere that puts it all together in one place so if I'm explaining what is obvious to you, my apologies - like I say, I'm writing to myself here.
I don't know that this even is a Show HN - @dang, if it isn't, please feel free to recategorise/edit the title.
@Everybody else, I am happy to answer questions if I can but please bear in mind that I am not claiming to be an expert on any of the tech gathered together to make this work.
Mostly, though, what you are describing is the internet
* TURN handles protocol bridging (TCP <-> UDP)
* TURN is useful for privacy preservation.
* TURN handles NAT Traversal (unfortunate when it comes to this)
* TURN is used for security in some cases. It sits at the edge and clients create allocations
Much like TLS, both clients offer all the protocols, versions, and media encodings that they support so that they can find a common set that they can use together.
This is standard negotiation when establishing connections in WebRTC and it's obviously fingerprintable information.
Use of a TURN server does not imply hiding of negotiation details. The TURN RFC [1] does not mention anything related to media encodings or WebRTC negotiations at all.
[1] https://datatracker.ietf.org/doc/html/rfc5766
I’m so used to seeing both STUN and TURN together.
You could do all of that with your own protocol, but...
Some NATs will include the remote IP in the "key" of the mapping, or even more restrictive approaches, meaning that STUN will have to fall back to other strategies and eventually give up and use TURN.
These days you'll also find that mDNS and other local broadcasts play a role, so that the internet can be avoided entirely for LAN peers.
when I wrote my other comment in my head TURN and STUN were practically synonymous, since I’ve never seen one without the other.
> TURN is considered an extension to the STUN. So, a typical TURN server would include a STUN server implementation by default.
https://www.100ms.live/blog/webrtc-turn-server
...only if ipv6 wasn't written by the very people profiting from NAT.
Pedantic: Fibre and wireless do not fit this criteria, but I still agree with the spirit.
[1]: https://en.wikipedia.org/wiki/Universal_Plug_and_Play
[2]: https://en.wikipedia.org/wiki/Zero-configuration_networking
https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...
https://en.wikipedia.org/wiki/Port_Control_Protocol
For hobby projects like this I have had no complaints with OCI but yeah, you would have to be crazy to use it in production.
This is a valuable contribution. IMO, the Internet needs more STUN, TURN, and MQTT servers. It's even more valuable if they support as many protocols as possible and have IPv4 / IPv6. For STUN -- running it with two IPs means it can support bind requests which is necessary for testing NAT types.
Good prose, clearly not written by AI - respect!
It's important to point out that Web RTC is E2E encrypted, so Google never actually sees your data.
As long as the server you use for signaling is secure, your TURN server may as well be run by the NSA. Since initial signaling is extremely low-bandwidth compared to the actual call, it's usually fine to handle it in your application directly.
THe actual problem with WebRTC is that, in its default setup, every call participant leaks their IP address to everybody else, and you need to upload your data n-1 times for n call participants, making it almost unusable on slow connections. You can mitigate both of these problems with an SFU, essentially a central server that takes in streams from all clients and distributes them further, but then you lose the E2E.
Did you evaluate any other TURN servers? I’m curious about your thoughts of the Elixir and Go ones. Maybe even more exist, I haven’t looked recently
https://github.com/l7mp/stunner
For those of you needing turn services without wanting to host, I can highly recommended Xirsys. Excellent service and while pricing is more than Cloudflare you get better network quality.
If you prefer Cloudflare, unless you are using GBs a day you'll most likely have a $0 monthly bill which makes it an excellent choice for small projects and testing.
There are more thoughts on tightening up authentication in the last section "Tightening and tidying"
Apologies if I have misunderstood your comment
[0]https://github.com/lvidgen/WebRTC/blob/master/FOSS_TURN_Serv...
Unless you're asking every user to manually input a TURN password and they promise not to give it out, you're basically forced to reveal it to every visitor of your site.
Again, not an expert. This problem only really exists for "ad-hoc" connections where you don't want people to have to set up accounts. coturn has the ability to do standard authentication by checking credentials stored in databases
* Your TURN server should provide APIs that allow you to verify that allocations/permissions are only created for your users.
* Use an auth mechanism that has an expiry time. Like [0]
[0] https://github.com/pion/turn/tree/master/examples/lt-cred-ge...
coturn provides these APIs, they're not covered in the writeup, though
> * Use an auth mechanism that has an expiry time. Like [0]
This is how the credentials server in the write up works