51–60 of 169 posts
How do they manage their mesh? I've just been doing research on setting up my own wireguard mesh (currently using a spoke/hub setup with pi-hole/pivpn). I found https://github.com/HarvsG/WireGuardMeshes today which is awesome, but I'm curious what fly.io / other readers here may be using.
Fly.io's blog posts are incredible, they really seem to really enjoy what they do and want to share what they've made with everyone else. I love them for that. I wish that more companies could be like this and skip the corporate BS, it shows that they really have something outstanding to offer.
I think their super power here is employing a renowned security expert who is an incredibly good communicator! (And happens to be a top HN contributor)
Back in the day (nearly 30 years ago) people would run a user-mode stack to obtain Internet connectivity via a (dial-up) Unix shell account. The program was "slirp" which was named after SLIP/CSLIP, but then upgraded to support PPP once that became a thing. https://en.wikipedia.org/wiki/Slirp
Earlier quoted context omitted.
It sounds like we could have a generic userspace tool that proxies any connection to a WireGuard server. Similar to ssh -L, it would listen on a TCP/UDP port locally (or talk the SOCKS protocol) and convert that to IP packets over the WireGuard connection (using a userspace TCP or UDP implementation for that side). It looks like Fly.io has all the bits, they just need to be packaged as a stand-alone tool rather than…
Tailscale will do this! tailscaled --tun=userspace-networking --socks5-server=localhost:1081
I should try to recreate the logs and issue for the tailscale folks.
Because 'sho_hn brought this up, here's a stab at a pro/con list of building TCP/IP directly into our API the way `flyctl` does: Pro: + Can just run "native" SSH directly over it (or, in our case, use x/crypto/ssh, without modification). + Lets `flyctl` offers a `flyctl proxy` command to users, so they can plug their own programs into whatever application they need to use, without asking us to change some proxy we ru…
While on the topic, we're also eagerly awaiting improved autoscaling (e.g., more responsive, using additional metrics, and scaling down properly). I'd be really curious if you could leverage the more detailed access to instance-level metrics to implement some cool new queue-theoretic modeling: You know roughly how long it takes for an app to launch, you know the current request rate, and you know the time to service requests. You could apply a lightweight Markov model to predict the probability of a given queueing delay in each region within the average launch time and, if so, preemptively launch a new instance before queueing delays even occur. This could be configured to balance a client's tolerance for queueing delays with over-provisioning budget.
Because 'sho_hn brought this up, here's a stab at a pro/con list of building TCP/IP directly into our API the way `flyctl` does: Pro: + Can just run "native" SSH directly over it (or, in our case, use x/crypto/ssh, without modification). + Lets `flyctl` offers a `flyctl proxy` command to users, so they can plug their own programs into whatever application they need to use, without asking us to change some proxy we ru…
We recently moved our entire app deployment over to Fly and are mostly loving it, but one of the mildly janky features is hallpass. For instance, (1) connections often fail if you have X forwarding enabled (even if you did no specifial config on the machine), and (2) port forwarding doesn't work. While these aren't really a big deal since (1) you can just disable X forwarding in ssh_config and (2) port forwarding is…
If you like, you can roll a Dockerfile that runs OpenSSH directly on your internal network address (bind it to `fly-local-6pn`), and then use native WireGuard to talk to it.
I've got a branch on hallpass that does port forwarding, but I never merge it, because you're right: using port forwarding on Fly.io is weird, because we already provide you direct access to any port you're exposing, and you can't talk to any of this stuff without WireGuard already. I think it would just confuse people more if I made port forwarding work.
Because 'sho_hn brought this up, here's a stab at a pro/con list of building TCP/IP directly into our API the way `flyctl` does: Pro: + Can just run "native" SSH directly over it (or, in our case, use x/crypto/ssh, without modification). + Lets `flyctl` offers a `flyctl proxy` command to users, so they can plug their own programs into whatever application they need to use, without asking us to change some proxy we ru…
Earlier quoted context omitted.
1. Tailscale is amazing. I hate them so much. (We use Tailscale and are very happy with it.) 2. Tailscale is user-mode WireGuard. 3. "User-mode WireGuard" in the sense this post uses the term is a misnomer and refers to the fact that we run TCP/IP itself in userland (Tailscale normally runs through a tunnel device and uses your native TCP/IP stack). 4. But Tailscale also has code to do user-mode TCP/IP (they've got i…
Last I heard[0] they were experimenting but hadn't shipped it. AFAIK their client still requires root, no? Running on wasm sounds awesome. This[1] looks like it. Do you know how they're doing the actual networking? WebRTC tunnel? [0]: https://news.ycombinator.com/item?id=24483173 [1]: https://twitter.com/bradfitz/status/1451423386777751561?lang...
Tailscale's gvisor/netstack-based userspace networking mode has been supported and in wide use for quite some time. It's the default on Synology DSM7, for instance.
You don't need root when you run tailscaled with `--tun=userspace-networking`.
Peers can still connect inbound to the non-root tailscaled, but to connect _out_ to other peers, you need to use tailscaled's HTTP or SOCKS5 proxy, which are also flags to tailscaled, to specify what port they listen on.
Earlier quoted context omitted.
1. Tailscale is amazing. I hate them so much. (We use Tailscale and are very happy with it.) 2. Tailscale is user-mode WireGuard. 3. "User-mode WireGuard" in the sense this post uses the term is a misnomer and refers to the fact that we run TCP/IP itself in userland (Tailscale normally runs through a tunnel device and uses your native TCP/IP stack). 4. But Tailscale also has code to do user-mode TCP/IP (they've got i…
I think Tailscale uses user-mode TCP/IP (also gVisor netstack) for some client devices, like iOS? But could be wrong here.
(iOS 15 bumped the Network Extension memory limit to 50 MB, but we still need to be super trim for iOS 14's 15 MB limit)