6 ms·
Nebula is such a great tool. If you haven't tried it yet, you should really give it a shot. It's easy to self host and to set up, and has been absolutely rock s
by dave78 3y ago
Nebula is such a great tool. If you haven't tried it yet, you should really give it a shot. It's easy to self host and to set up, and has been absolutely rock solid. I have it on all my devices, plus several Raspberry Pis set up at unattended remote sites that I rarely have access to serving as gateways to internal LANs and they all just work, all the time.
Tailscale gets most of the attention on HN, and I'm sure that it's a wonderful product too, but Nebula is a nice, simple, "do one thing well" product.
- SadTrombone 3y agoI've tried Defined recently and it did the job just fine, but the thing about Tailscale (and others in the space like ZeroTier) that put it ahead of something like Defined/Nebula for me is that I don't have to run my own servers/infrastructure for lighthouses and relays. I understand that everyone has their own preferences and some might want to host this themselves for privacy reasons and whatnot, but for me as a single end user I'm glad Tailscale just handles all the infra for me.
- rhuber 3y agoThat's totally reasonable, and I agree that using something hosted entirely by a 3rd party makes sense for some use cases. Our reason goes a bit beyond security concerns, in this case. We built Nebula for large scale deployments, and because of that, we have made decisions that lean into that model for hosting. Our decision to leave lighthouse hosting in the hands of users has one primary rationale: We want users to have complete control their network availability. Any downtime of our service should not impact their network availability. You can even host some of your lighthouses inside of network boundaries to ensure that an internal network functions properly if its connection to the internet is interrupted. Other overlay options may continue to work for some time, but new connections are often not possible, and the network can degrade rapidly. Relays are are a similar story, but with an additional reason: We don't have to limit our customers' relay bandwidth due to cost. When hosting relays on behalf of others, we would be transiting a lot of traffic, which has an associated (sometimes unpredictable) cost. By letting our customers host relays, they can ensure relay traffic is just as fast as direclt connections.
- nine_k 3y agoThis is indeed understandable. For me, the fact that I can run my own lighthouses and depend on / trust no third party is the big plus. Both cases (third-party and self-hosted) are in demand.
- the-smug-one 3y agoI don't understand why I should use something like Nebula or Tailscale. I've got a Wireguard setup where all of my users connect into a VPN. What does Nebula give me?
- code_biologist 3y agoProbably not much? I tried to set up Wireguard to my home network before traveling for the holidays last year. I was too dumb to do it, or at least in a way that didn't feel fragile. I had Tailscale up with subnet routing set up the way I wanted in 15 minutes.
- xoa 3y agoI think mesh networks start to become more valuable when you want/need various users or sites to be able to talk directly to each other with significant bandwidth, or when latency might be constraining, and start to scale up. To take my own examples, I've got my main Site A which has a fixed IPv4, then I have a Site B which is the primary offsite but still "local" (<1hr drive) backup location with a few hundred terabytes of redundant spinning rust and no fixed IP, and then small sites C through M that also have their own local NAS. All are within a few hundred miles of each other. Everything is managed from A, so WireGuard would be fine for handling all remote access, even if I'm in another country since there isn't really a significant extra latency hit from bouncing through A. But I want C-M to backup to B as well, and in a hub/spoke that would mean all that traffic must also go through A. Obviously if I rented a fixed IP for B, I could then set B up as a new hub and add new VPNs and rules for C-M for B as well as A. But that's already a certain amount of extra work or setting up automation, and if down the road I had a B2 or B3 that'd multiply. Even automation though won't solve the problem of latency if things spread out further, if A was a thousand miles away from some new site, now bouncing through A starts to add a potentially really noticeable latency hit for no reason. Having a mesh means only the lighthouses need fixed IPs, and then everything can talk directly with no extra work. That is significantly more scalable, adding a new client requires nothing from any of the other clients. And it cuts out unnecessary legs in the trip and the traffic and latency that involves. Wireguard is awesome and it sounds like you probably don't need to bother in your use case, but if you start providing distributed services not funneling through hubs starts to be worth considering. Particularly if you start caring about one service site going down affecting others.