Live data from Hacker News

Nebula, Slack's Open Source Global Overlay Network

slack.engineering

1–10 of 71 posts

Re: Nebula, Slack's Open Source Global Overlay Network

#4

How does this differ from WireGuard?

Like wireguard, Nebula is using the Noise Protocol Framework[1], but it seems that Nebula is using a ca-cert authority to tie together the peers in the same Nebula network[2]

[1] https://www.noiseprotocol.org/noise.html#introduction [2] https://github.com/slackhq/nebula#3-a-nebula-certificate-aut...

Re: Nebula, Slack's Open Source Global Overlay Network

#5

How does this differ from WireGuard?

It sounds like encryption was a necessary but not a sufficient requirement for Nebula.

In addition to VPN, Nebula added traffic filtering and spanning different clouds and data centers. I don't think Wireguard had those as goals.

They serve very different purposes. I use WireGuard to encrypt my mobile traffic but I wouldn't have picked it to connect the various hosts in my network at work. Nebula, however, might do the trick.

Re: Nebula, Slack's Open Source Global Overlay Network

#7
I feel like I don't totally follow how you would set this up for, say, a company that has infra in two cloud providers (but no office network or datacenter or anything)... I think the answer is you set up one or more lighthouses with stable IPs on the public internet, and you make sure all your ephemeral cloud machines have IPs on the public internet? And all your ephemeral cloud machines get RFC-1918 addresses that are effectively in a giant flat subnet with no broadcast / no L2 domain and no implied structure?

It feels a little different from Wireguard, in that with Wireguard your engineers would be able to connect from behind a NAT, but my reading of how it works is that machines route directly at each other. Which is good for a production network where you care deeply about routing (bandwidth, latency, costs, debugging, etc.), but it seems that here your engineers would still need to connect to a bastion host or something, i.e., it isn't a VPN in the sense of being able to join the corporate network directly.

I guess if you've also got the lighthouse node internally routable by all your machines (e.g. you have an internal datacenter network and something like AWS Direct Connect) it would work too?

It'd be nice to see a sample network design.

Re: Nebula, Slack's Open Source Global Overlay Network

#8
post #6

> We tried a number of approaches to this problem, but each came with trade-offs in performance, security, features, or ease of use. I wonder if they tried ZeroTier. It sounds really like what they wanted.

They may have decided that ZT's encryption isn't proven well enough for their needs. It's also posssible they rejected ZT because they didn't want to use ZT's centralized infrastructure. Two years ago was long before ZT started working on making that optional.

Re: Nebula, Slack's Open Source Global Overlay Network

#10
post #8
post #6

> We tried a number of approaches to this problem, but each came with trade-offs in performance, security, features, or ease of use. I wonder if they tried ZeroTier. It sounds really like what they wanted.

They may have decided that ZT's encryption isn't proven well enough for their needs. It's also posssible they rejected ZT because they didn't want to use ZT's centralized infrastructure. Two years ago was long before ZT started working on making that optional.

ZT allows you to run your own "Moons", meaning you dont need their infrastructure... bit more config required on the client end, but less reliance on Zerotier....
Post reply on HN