Comment by niz4ts | Hacker News Reader

Comment by niz4ts | Hacker News Reader

When I read this, I got a little too excited and thought they managed to get wireguard connections happening in the browser with webassembly (this isn't impossible, but the only attempt[0] I know of so far only works because of extra things tailscale has). It's an idea I've had for a project, but one I haven't had time to dedicate to (yet).

In any case, really cool write-up! I wonder if they thought about making `flyctl` do a check with their API for any command that requires talking over wireguard to ensure the keys would be installed in the gateway. Since `flyctl` knows when the last command was run with it, it could do this only after some inactivity. And on the gateway machines, they'd just clean up any inactive peers with a cron (which they seem to be doing already).

Not a solution as elegant as the one they reached (which is super cool), but I'm assuming the considerably lower effort would make it appealing.

[0]: https://labs.leaningtech.com/blog/webvm-virtual-machine-with...

WebAssembly is not magic, the simple reality is that browsers do not expose low level socket interfaces, so they cannot connect to arbitrary services on the wider internet.

We choose to use Tailscale since they allow WebSocket-based connections via their DERPs.

It is interesting that, originally, DERPs were intended to be a solution for machines in extremely limited networking environment where nothing but HTTP is allowed. Turns out browsers are exactly one of those extremely limited networking environments.

> We choose to use Tailscale since they allow WebSocket-based connections via their DERPs.

Some context that I wasn't initially aware of: apignotti is the CTO of Leaning Technologies, which is where the article GP linked is from.

For Chromium-based browsers, an option is to use BrowZer (built on OpenZiti, Apache 2.0). Enables you to connect into a full mesh private network (mTLS, e2e encrypted, no TLS man in middle inspection). 3 examples below with well known apps. Disclosure, I work on the project.

MSFT RDP (video):https://youtu.be/1NMrxRIowog

Private network for Grafana (video):https://youtu.be/l5ktiI-j3eg

Private network for Plex (blog post)https://blog.openziti.io/its-a-zitiful-life

Basically you decide what 'app' you want to deliver via the overlay, e.g. Grafana, Plex, RDP. For those destinations, a (one time) bootstrapping process (invisible to end user) results in your browser receiving a <script> tag which includes some configuration when the browser attempts to connect to the destination (Grafana etc). This ultimately results in the browser downloading some JavaScript and WA, and registering a service worker (the wasm contains the PKI bits).

After successful auth, your browser can then open a websocket to your private OpenZiti overlay network (distributed, OpenZiti overlay network software routers, deployed where you want them), and ultimately hit the app (which no longer needs to listen to anything other than the overlay network; becomes private).

Desktop Chrome is the most tested, followed by Android Chrome.

Tailscale already got all this stuff working in WebAssembly in the browser. :)

The way we think about things, if we were going to try to provide a browser experience of doing something with WireGuard, we'd probably just fork off a tiny Fly Machine VM to run it on. Just a different vibe here.

That's a separate blog post, and it definitely is pretty cool.

https://tailscale.com/blog/ssh-console

https://www.npmjs.com/package/@tailscale/connect

Reply on news.ycombinator.com