[jasonvorhe]

If you can, do so. This reminds me of claiming to be able to build Dropbox in a weekend with existing tools. You can, but it most likely won't work as well, won't be as integrated and well, you'll have to build it yourself which won't be as easy as you think it is, then add monitoring and paging and, depending on your requirements, high availability.

I'd certainly be interested in a blog post about this, if it's as easy. But considering that Tailscale took this long to launch, I have doubts that this is as easy to build.

[dfcarney]

(Co-founder of Tailscale here) To that end, we started publishing a "blueprint" for people who want to DIY. There's more to explain (and questions encouraged). Please check it out: https://tailscale.com/blog/how-tailscale-works/

[zackmorris]

Thanks for this. From the link:

My teammate Dave Anderson is writing a post about all the insanity that is NAT traversal. That alone will probably be as long as this entire article. Stay tuned!

I've watched countless p2p projects fail due to NAT difficulties, and spent months/years banging my head against it only to fail too. I've heard that NAT is tragically still a thing with IPv6 as well.

Please, if you all make it big, start a cross-platform open source, drop-in library that completely solves the NAT problem. The unit test for it would be that an app using it can accept inbound connections with zero configuration. That might require a central server though. I think the crux of the problem is how to share IP addresses with each other through that central server securely for STUN/ICE so that nobody can eavesdrop. Would you consider making your DERP servers free and open for that purpose? Apologies if I'm glossing over this or missed something, this is just something that has vexed me for almost 20 years. Thanks!

[dave_universetf]

IPv6 by and large solves the NAT problem per se, but doesn't solve the stateful firewall traversal problem. Fortunately that one is _much_ simpler, especially now that we have QUIC as a robust stream protocol over UDP. IPv6 also introduces complexity while IPv4 is still around, because you have to detect and handle NAT64 in order to get a v6-only node (with NAT64) and a v4-only node talking to each other.

Completely solving NAT... I've tried a couple of times over the last 10 years, bunch of false starts. You can see one of the older attempts at https://github.com/danderson/nat (don't use it, it's very basic and fails at a lot of NATs). One of the tricky parts is that to make it work right, you really need control of the wire protocol you're using, because you have to inject frames and do all kinds of weird things to help with the NAT part, while ignoring all that noise at the "upper protocol" layer. You can make it generic with some careful layering, but it turns a simple API into a complicated one.

You absolutely need a coordination server for NAT traversal to work. That's unfortunately one of the great unsolved problems for fully decentralized p2p. But it can be _any_ low-bandwidth channel you have available (one of my first implementations piggybacked over XMPP messages), and it doesn't have to be a trusted part of the system (although making it trusted simplifies a ton of stuff). And you also need some kind of data plane relay (like DERP) for when NAT traversal fails, which still happens a fair bit. Without that extra layer of relaying, you'll only ever hit 95-99% connectivity, not 100%.

I'm (slowly) writing an article on NAT traversal that covers all this. It's a thorny problem, and I'd love to solve it once and for all (which is sort-of why I work at Tailscale - I think I have a shot of solving it once and for all at the IP layer, so that all the other layers can just stop caring)

[apenwarr]

(Tailscale co-founder) I'm with you on this! The NAT problem drives me nuts. That's one of the core concepts behind tailscale. Unfortunately I don't think the "open source NAT traversal as a library" idea will work; it's been tried before, but NAT is just so fiddly that the library invariably "doesn't quite work" in some weird condition and the app developer is left trying to debug NATs, which they don't know how to do.

With Tailscale we want to take full responsibility for connectivity, so that app developers can work on apps that just assume the connectivity+security is there, and users can complain to us instead of them when their computers won't connect. At least, that's the dream. How best to package that up, I'm not quite sure.

Regarding DERP, the server code is open source: https://github.com/tailscale/tailscale/tree/master/cmd/derpe... and if you look closely, you can see that DERP servers are fully anonymous (pseudonymous?) and will route traffic between any two DERP connections based on their public keys. We rate limit traffic to keep costs under control, and we'll let paying customers boost their speeds, but we intend to always let our DERP network be usable at "reasonable throughput" for free. And since the code is open source, you can write your own tools that do it.

Lots of things to work on. Hope this helps!

[ptman]

Does tailscale work in China? Does DERP penetrate the great firewall? How does tailscale protect / work against nation state actors? Are you incorporated in the US? How does Tailscale help against wide-reaching legislation like EARN IT?