This is such an interesting marketing strategy, I had never thought of selling B2B production infrastructure under the aesthetic of, “Can you believe this shit actually works?”
Yes! This person gets it.
SSH and User-Mode IP WireGuard
51–60 of 104 posts
Re: SSH and User-Mode IP WireGuard
#52> Normally, this big balloon thingy would be an elaborate scheme to get you to check out our product, but here it's just pointing out some new source code we haven't talked about elsewhere. I really enjoy this style of writing from a company. Regarding the article, it seems like Fly has pulled off some insane networking nonsense, but I don’t know enough about networking yet to understand it. Saving this page for late…
> Regarding the article, it seems like Fly has pulled off some insane networking nonsense Fly is essentially building a Tailscale-esque infrastructure to service one part of their cloud offering. It is indeed insane the amount of heavy-lifting they do to make it all work. They seem like a cross between packetfabric, gitops, docker, and hashicorp but with way less engineers on the team.
The technical heavy lift is rarely the success determinant, so having a company implement half-baked (enough for internal use, but without the edges polished off that are needed to support it with external customers) versions of N related (but not yet mature) technologies is pretty normal (if they are full of good engineers) and getting advantage from it.
Most of the time these implementations are too tightly tied to the rest of the company's infra to be useful standalone. When one of those companies succeeds a common pattern is for engineers to cash out, leave, and build a new startup around one technology from the success story.
I would not be surprised if this is one of the forces that drives the consumer -> infra -> consumer -> infra cycle. A consumer wave leads to inventing lots of interesting but bespoke infra while it is growing like crazy. When it plateaus, folks spin out the interesting infra bits until the next consumer wave (generally larger) starts rising.
Re: SSH and User-Mode IP WireGuard
#53The prefix for ssh command looks good for commandline. However, is there a way to hide with some settings in .ssh/config so one can have normal-looking "ssh host" cmdline without special prefixes?
Re: SSH and User-Mode IP WireGuard
#54The prefix for ssh command looks good for commandline. However, is there a way to hide with some settings in .ssh/config so one can have normal-looking "ssh host" cmdline without special prefixes?
"flyctl ssh issue" will get you all setup for normal ssh access, and even store credentials in an agent if you have one running.
Re: SSH and User-Mode IP WireGuard
#55This is such an interesting marketing strategy, I had never thought of selling B2B production infrastructure under the aesthetic of, “Can you believe this shit actually works?”
This is going to be a great tweet for me and I will totally not give you credit.
Re: SSH and User-Mode IP WireGuard
#56I added some example code to the post, because, again, I kind of can't get over how easy this turns out to be. And if you follow the link into Jason's `wireguard-go` code, until you hit gVisor itself, it's not much more complicated under the hood. Having complete control of TCP/IP in userland like this, with so little code, is so valuable I feel like there needs to be some special name for the technique. The whole th…
This is awesome! In the post you mention "For a couple hundred lines of code (not counting the entire user-mode Linux you’ll be pulling in from gVisor, HEY! Dependencies! What are you gonna do!) ..."
I'll note that while all of gVisor's user-mode Linux is in the same Go module, we've actually gone to decent lengths to keep the network stack logically separate from the rest of the user-mode Linux code.
So while go.sum might look a bit frightening, Brad's depaware shows that the extra code you pull in to binaries by using netstack is actually quite minimal: https://github.com/tailscale/tailscale/commit/5aa5db89d6a9a6....
Re: SSH and User-Mode IP WireGuard
#57Earlier quoted context omitted.
Ok thanks – this has been one of the rare things that some of those clients seem to care about (whether they're right or wrong, or rather, more conservative). I had another question – this seems similar to what Hashicorp is doing with Boundary. Have you looked at Boundary and how this potentially compares with that, from an architecture standpoint? Of course there are parts of this that are bespoke to your infrastruc…
There is a lot of Hashi in our stack already; we orchestrate with Nomad (we have our own Firecracker task driver), we backend our certificate system --- which is awesome, certificates just work for Fly apps --- with Vault, and we use a lot of Consul. I think our take on end-user access management is lower-level than what Boundary is trying to do. Boundary, as I understand it, sees the world the way an IdP RP does, mo…
Thanks. I actually feel like if Boundary had an experience more like Tailscale does, but on top of their stack (wireguard network, secrets in vault, server/service discovery in consul, etc), that would be really powerful and a no-brainer for those of us who also use a lot of Hashicorp products.
But I'm still trying to fully understand what they're doing with Boundary. The abstractions just feel a bit off to me unlike other Hashicorp products (it's odd to me that you have to tell boundary to treat a database connection differently rather than just giving me any TCP or UDP access).
But their team does great work and has elegant designs so I trust it's more likely that the lightbulb just hasn't gone off in my head yet with Boundary.
Re: SSH and User-Mode IP WireGuard
#58I know it's not really an HN thing to say, but this is just cool . Reverse ssh tunnels on Wireguard through my VPN are cool enough; the amount of magic here (albeit I think perhaps not totally strictly required magic…) is definitely interesting++.
This morning I set up openSSH + wsl + minicom to configure my router over LAN. Why? Because I could. Computers are fun.
Also, it saves moving cables around when I break stuff.
Re: SSH and User-Mode IP WireGuard
#59I read this but I didn't get it at all. I can't see the forest for all the excited talk about particular trees. In simple words, what problem are they trying to solve?
You need WireGuard to SSH to machines at Fly (that's a good thing). You don't have WireGuard installed on a particular machine. That's OK, because there's a portable, userland, Golang implementation of not only WireGuard but all of TCP/IP that can be imported into any Go program. Go programs can BYO network stacks. That's crazy. The end.
Why is userland TCP/IP stack needed? I didn't get this part of the story.
Re: SSH and User-Mode IP WireGuard
#60Earlier quoted context omitted.
You need WireGuard to SSH to machines at Fly (that's a good thing). You don't have WireGuard installed on a particular machine. That's OK, because there's a portable, userland, Golang implementation of not only WireGuard but all of TCP/IP that can be imported into any Go program. Go programs can BYO network stacks. That's crazy. The end.
Why is userland TCP/IP stack needed? I didn't get this part of the story.
Work through it. You need WireGuard to talk to SSH on our instances; that can't change, it's a security rule. You can get userland WireGuard; that's how most people WireGuard. But you can't create an OS tun device: you need root to do that; you might as well just install WireGuard. Ok: you handshaked a WireGuard connection in Go. What's next?
Let's simplify it: from your Go WireGuard connection, just do an HTTP GET. What's your next step?