upvote
ah nice. i’ve actually been building something pretty similar on top of wireguard too

my use case is a bit different though. i started because i wanted to give friends access to specific things in my homelab, but very selectively. like “you can use jellyfin on this one machine, but you can’t ssh, and you can’t even see my other devices”

tailscale is honestly amazing for getting devices connected, i still use it a lot. but once i started trying to do these very specific “this machine can talk to that machine only on this port” kind of setups, it started feeling more complex than it should be, at least for personal use. ACL editor is more confusing when it comes to this. i know we have got option for tags and things, but those are very poorly documented and i haven't found a single tutorial that works nicely.

your userspace approach is really interesting btw, especially the no tun / no root part. makes sense to run it on rigit enterprise environments.

reply
Tela has ACLs per machine, but not per service. That's an interesting use case, and I'm shocked that I missed it. I've added it to the pre-1.0 roadmap. Thank you!

Another thing on the release roadmap is a TUN/root story, since there is value in having that layer as well. Tela will always support the user-space approach, however, so that unlike Tailscale it's always accessible.

reply
deleted
reply
I've been working on a similar tool for a while - connet (https://github.com/connet-dev/connet). It builds upon QUIC (instead of wireguard), but I think from an enduser perspective the results ends up looking pretty similar.
reply
Nice! It looks essentially like userspace NAT, only active for particular ports. I'm contemplating a similar setup to handle access to my home machines: when I'm in my home network, some ports are forwarded to 127.x.y.z directly from the remote machine, and when I'm away, the same ports are forwarded via a Wireguard connection. This way, at home I can use the full speed of the LAN, and when away, the speed is limited by the Wireguard gateway, but I still connect to the same host:port, wherever I am.
reply
Very interesting - but I also find it important for solutions to state the trade-offs if they provide a novel approach that doesn't have the same requirements as the main contenders. In your case, what are the trade offs for running in user space ?
reply
That's true. I'd say, probably performance is the first trade-off, weighing kernel against user-space. For the sorts of scenarios I envision for Tela, it's probably not a huge loss (I won't be running Facebook off of a Tela hub, I don't think). Another is that I have to run and tear down the client myself, though I do have support for running the tela client as a service.

It's funny... I've started using so many of the nifty management features of TelaVisor and Awan Saya that I am now considering adding lower-level support for the features that I explicitly wrote for user-space.

reply
> My initial motivation was wanting to RDP and SSH into my home workstation from a locked-down corporate laptop when I travel. I couldn't install Tailscale on the laptop

I'm not sure it would work but did you try running tailscale client through a docker container so it's not installed directly in your host system?

reply
It would work, but this laptop is so locked down that I can't even install Docker without begging for permission (it's for a consultant role, not a dev role, so...). That said, my stop-gap solution while I worked on Tela was a cheap Linode VM with tailscale installed, and using SSH port-forwarding to get to RDP. Even at that tiny price, it grated me.
reply
Pretty cool! I see on enterprise edition you also support a virtual mount, is it FUSE based? I got a similar tool but went the other way around, I wanted to browse files synchronously (and bidirectional sync of edits) between two devices via FUSE mounts, and ended up tunneling TCP for this in the end.
reply
Thanks! The file sharing is part of the base, FOSS Tela. It uses WebDAV rather than FUSE. The tela client runs a local WebDAV server that proxies file operations through the WireGuard tunnel to the agent on the remote machine. You can mount it as a network drive (Windows maps it as a drive letter, Linux/macOS mount it as a directory) or access it via TelaVisor or the tela CLI. It can be configured as read-only or read-write. Certain file extensions can be banned from upload or rename.

I went with WebDAV because it works on all three platforms without a kernel module or extra driver. For my use case (browsing files, grabbing configs, etc.) it works well enough.

Bi-directional sync is an interesting idea. Right now the sharing is one-directional (the agent exposes a directory, the client mounts it), but I could see adding something like that as a layer on top.

reply
I think this is the same as using a cloudflared tunnel?

to access my home desktop machine, I run:

``` $ ssh itake@ssh.domain.me -o ProxyCommand="cloudflared access ssh --hostname %h" ```

and I setup all the cloudflare access tunnels to connect to the service.

reply
If I understand you correctly, you SSH in via cloudflared and then use that tunnel to reach other services through that session. That would work, yes.

Tela takes a little different approach. The agent exposes services directly through the WireGuard tunnel without SSH as an intermediary, so you don't need sshd running on the target. Each machine gets its own loopback address on the client, so there is no port remapping.

The big difference is the relay, though. With cloudflared, Cloudflare terminates TLS at their edge. With Tela, you run the hub yourself and encryption is end-to-end. The hub only ever sees encrypted data (apart from a small header).

reply
Now add an Android client and exit node support and it will completely replace Tailscale for me. :)
reply
Thank you! That means more than you know. :) I've thought about an Android client. It would have the same problem that exit-node support would have: Tela is currently engineered as a user-space alternative to Tailscale. However, as I mentioned in another reply here, I've gotten so fond of a lot of the other features of Tela that I might consider adding support for low-level features that require kernel support. It might not be 1.0, but I'm open to suggestions.
reply
Now that’s cool. I wished I new that when I was trying remote access my computer a few month ago.
reply
Exactly what I was going to build for myself, no need now, very cool
reply
thats awesome. really
reply
This is super cool.
reply
That's very useful!
reply
Sooo freaking cool.
reply
Very cool
reply
Awesome
reply