what I am looking for is a VPN that will help me with a music project (Supercollider) that is using OSC messages. So this means i don’t need the VPN predominantly for security but so that udp messages can reach their destination for people behind a NAT. While being connected to the internet.
I know about openVPN but its free only for 2 connections. I saw shadowsocks but I am not sure it does what i want. And i saw wireguard.
I think wireguard will do the job, BUT I was hoping for something simple UX-wise because it will be used by non-tech people.
So i hope someone of you lovely people has an idea. Tell me if clarifications are needed.
I’m having trouble understanding what Supercollider is exactly.
Am I correct in assuming that there’s a “server” component (worker puppet node role) and the expectation is that servers somehow register themselves to pools and then become available to run arbitrary stuff?
How is this “randevous” / “discovery” … (using the terms loosely) expected to work.
Do servers need to talk to other servers?
Thinking…
Maybe lookup a library called ICE for nat traversal and see if you can integrate it with Supercollider.
Alternatively, you’d probably need to run relays for OSC somehow. (remember there’s IPv6 as well as IPv4 to take care of, and you can’t directly connect V6 only to V4 only nodes and vice versa and there’s all kinds of complicated other things that relays just solve).
There’s things like Tailscale, Zerotier, Nebula… You could wrap Wireguard into installers, share config through qr codes, reuse and adapt per platform docs and so on…
They’re all general purpose and applications agnostic heavy hammers, that add entire network interfaces; and thus are potentially detrimental to security and safety of people running them since they end up enabling connections of computers with other computers run by other potentially malicious people, and enable communication for any and all purposes - having an application specific solution would be safer if people connecting each other are not fully trusting of one another.
If you’re a developer (e.g. Supercollider author), you could potentially reuse what Tailscale is doing for it’s NAT hole punching but instead of plumbing Wireguard, you could plumb OSC or whatever is your application protocol of choice.
Wireguard and Nebula are based on “noise protocol framework” to establish connections that then carry network packets that are reinjected into the host network stack. These days there’s that “noise explorer” where you pick/plugin a protocol pattern and it does formal verification of the handshakes and generates most of your actual code in a few programming languages. Once you establish end-to-end connectivity, you could wrap OSC data into a noise framework based protocol, and this would provide a guarantee that other side is who they’re supposed to be. Or you could use TLS/DTLS or similar.
all kinds of things are technically possible and potentially not hard for end users and free. Not all are right/easy for Supercollider
tldr this is going to be something like an MMO but for audio, if that makes sense.
I am sorry I was a bit excited when was writing my question and left some things out.
First of all the usage of supercollider is not important in this project any software using OSC messages could take its place.
Secondly at this point I am using oscgroups as a framework to share messages between users. It works very nice most of the time, except I have had some problems with some people with network setups i don’t know about. But I have had success with putting the oscgroups server inside a openVPN or Hamachi network. Now i want to host a VPN server that 30-50 clients can connect to.
If you have an alternative solution instead of oscgroups please tell.
I am planning to secure this system but at this point i want see it working first.
Do you run your own oscgroups server? - it’d make things easier.
This is doable, OpenVPN is free software and this is actually not too hard… but depending on the platform the software of choice for end users you’ll probably need to generate configs for everyone and provide instructions for Linux/Mac/Windows and then everyone will send traffic through the OpenVPN server to everyone else.
I’m thinking you could carve out a smaller subnet, a part of the 172.16.0.0/12 … (e.g. 172.22.22.0/25 which e.g. gives you 126 IPs) … put your oscgroups server on 172.22.22.1 and configure OpenVPN to give out remaining 125 addresses (172.22.22.2-172.22.22.126) to clients.
OpenVPN can be configured to not push any routes to client, other than 172.22.22.0/25… and the IPs that the oscgroups server will see and handout should be in that range as well.
From there onwards it’s a question of whether folks have firewalls that would be restricting incoming traffic and what the software they’re running is doing.
And look at some example configs - you can start by using the “static key” for experimentation, and then later switch to certificates until you get the rest of configuration nailed down.
It looks like the connectivity model here is similar to BitTorrent. oscgroups server being analogous to a BitTorrent tracker thst keeps track and distributes a list of peers that then need to connect to each other…; the assumption is that peers will be directly reachable somehow; and that the address that a peer is reachable on is the same for all other peers.
This is fundamentally not true with all kinds of NAT (the Tailscale article I linked to above goes in detail and as enumerates most NAT situations you may encounter).
In other words, because Tailscale wants peers to connect directly, their servers help coordinate this, and their software does not assume that a IP:port that a host on the network is using for one server is the best IP:port that all other hosts could use to connect.
You could try modifying the OSC client to perhaps do more effective nat traversal?
One thing that I noticed and found strange is the description for localtoremoteport; what the oscgroups server keeps track of should be the public address and port, not the ones oscgroups client host machine would use, but the ones that NAT rewrote.
This is discoverable by the client through STUN protocol… but often is not needed.
Do you want to tunnel everyone’s traffic through an OpenVPN server, … or not and if not should I look into the oscgroups client implementation to check if anything is obviously missing?
Do you happen to use the same subnet as they are? If yes you could go with a subnet like 198.18.0.0/16 or 100.64.0.0/10. The former IP space is used for testing only, so noone will use it and it won’t conflict with any lokal routes.
Since 30-50 clients might push a lot of traffic and audio “stuff” is mostly sensitive to latency, I would like to push you towards a mesh VPN like tailscale, Zerotier, headscale, Nebula or WireGuard in general. With those VPNs every node will talk directly to another node, which means that the traffic won’t have to be relayed by the VPN server and thus latency reduced! Performance will be better also of course.
.