Can nodes communicate with each other directly even if they're behind NAT, without port mappings or UPnP? I know there are ways to make this happen (e.g. using the techniques from Samy Kamkar's pwnat/chownat), but am not sure whether Nebula is designed to work within this constraint.
Having two nodes communicate to each other when you have a cooperating third-party server (a lighthouse or discovery node) that isn't behind a nat isn't hard. That's what STUN servers and other forms of UDP hole punching accomplish. pwnat is notable because it doesn't require having a public stun-like server, but nebula already assumes there's public servers, so traversing nat is a non-issue. The readme says "Discove…
This is not true. AGPL allows SaaS monetization (you just need to publish the source). BSL does not allow it.
That's why the BSL exists: to stop SaaS companies from monetizing the software without giving anything back to its developers. A SaaS company can get a commercial license.
Or just use Nebula, which is superior in some ways (though presumably not every way) to ZeroTier, and MIT-licensed.
WireGuard is a VPN, and Nebula is an overlay network (also known as a service mesh). They are closely related concepts. VPNs are primarily used for remote access, to get random machines access to closed IP networks. Service meshes synthesize a new network (sometimes IP, sometimes something else) to connect a bunch of related machines, almost always with policy controls for who can talk to what, usually cryptographic.…
Why do you think it is "weird" to use WireGuard for connecting application server with a DB instance? (Backdrop: I have recently moved our various prod servers into a WireGuard based VPN to encrypt the traffic between them. I found it was easier/pragmatic to do this than: * to setup SSL for my DB * to figure out how to encrypt traffic between my application server and Redis or my application server and Nginx )
I like WireGuard and wouldn't blink at a client proposing to use it to create a secure network fabric for their deployment environment, but it is not the norm for people to do stuff like this; in K8s land, this is what service meshes like Istio do, and more generally this is what people use overlay networks for. WireGuard could form the basis of an overlay network, if you added the same bells and whistles Nebula has. But I don't think Jason has in his plans to add those bells and whistles himself, because that's not really WireGuard's charter.
Network virtualization seems to have been extremely slow to be adopted. Even companies pushing "cloud first" seem to be running their physical networks like its 2003.
There has been a big "software defined networking" bandwagon but it's been confined to inside data centers.
Other similar projects that deserve a mention: tinc and yggdrasil. I used to use tinc and have recently switched to yggdrasil, which was much easier to setup. So far it works great!
I suspect that the goals are slightly different. The thing that immediately stands out is the routing. It looks like cjdns is a traditional-ish multi-hop network. The DHT routing table allows you to map out a route to peer A via peer B, R, & D. What wireguard and nebula allow is for the underlying network to figure out most of the routing, and effectively create a massive point to-point network. whilst you can have c…
I think cjdns allows arbitrary peering, so you can certainly set up a full mesh if you want point-to-point traffic, with multiple hops only for cases where the underlying network topology requires it.
I suspect that the goals are slightly different. The thing that immediately stands out is the routing. It looks like cjdns is a traditional-ish multi-hop network. The DHT routing table allows you to map out a route to peer A via peer B, R, & D. What wireguard and nebula allow is for the underlying network to figure out most of the routing, and effectively create a massive point to-point network. whilst you can have c…
I think cjdns allows arbitrary peering, so you can certainly set up a full mesh if you want point-to-point traffic, with multiple hops only for cases where the underlying network topology requires it.
Right, cjdns and Yggdrasil will both forward on behalf of other nodes where no direct paths are available.