You are rebuilding tailscale but requiring a centralised hub. I did the same in 2016 (pre-tailscale?) https://web.archive.org/web/20160304013451/https://wormhole....
I am not sure WireGuard existed at the time, and I used SoftEther and based it all on doing outbound tunnels to TCP/443* to avoid firewall blocks in corporate networks.
You could explore full P2P by leveraging UDP hole punching: https://cloudnetworking.pro/firewall-bypass-series-1-2/ https://cloudnetworking.pro/firewall-bypass-encapsulating-tr...
(WireGuard may already do it, dunno)
Also, fun fact, tela is also Spanish for fabric. Given the Filipino history, I guess it comes from there.
* I know I know, TCP in TCP is a bad idea https://cloudnetworking.pro/tcp-over-tcp-is-a-bad-idea/
Thanks! Yes, Tela already does UDP hole-punching. I made Tela because I wasn't allowed to install Tailscale on my new corporate laptop, and no other available solution seemed to tick the right boxes. It started as a simple way to RDP to my home workstation, but then I realised that if I could do that, I could finally pull my ad-hoc home cloud into one tool. The hub model is very much by design, for organisational purposes. The hole-punching feature gives me the P2P speed (and even STUN, if available). An upcoming version will allow hub-to-hub topologies.
It should have occurred to me that tela is also Spanish, since about every third word I hear in a Tagalog sentence seems to be of Spanish origin.
Does tela create an L3 network? if that's the case, what do you do to avoid IP addressing clashes? In Wormhole I decided by default to use CGNAT addressing (100.64.0.0/10)
I did not go too far unfortunately, so I did not face problems such as discoverability (do you have to know/remember all the IP addresses from the devices connected? DNS? etc).
No, it doesn't create an L3 like Tailscale. A client (a machine running the tela CLI) connects to an agent (a machine running telad) via a hub (a machine running telahubd), but once they connect they negotiate a P2P route if they can. That's all managed by Wireguard an gVisor. The remote service is forwarded to a port on localhost, so SSH to a VM somewhere else would just be ssh to, say, localhost:10022. I'm investigating a local DNS so that users can instead type `ssh paul@dev-vm` instead of `ssh -p 10022 paul@localhost`.
Very nice!