So for the past few years (?) I have been using wireguard to vpn into (effectively) my firewall and a dynamic dns setup to access that remotely. But with the shitshow that is google domains and the like, this seems like a good opportunity to look into a few of the alternatives. I am not entirely opposed to just going in and changing the dns server once I figure out what I am going to do on that front, but wireguard has always been a bit of a mess to set up for less “tech savvy” people who need access to the home network.

Every so often I see some cloud based solutions get suggested. Which is sketchy but I already have a few alerts set up to be able to remotely shut my network down if wireguard is acting up when it shouldn’t be and shutting down a VM is a lot less of a “do I really need to do this?” than shutting off the entire network. But most of those solutions seem built around selling seats which means they want you to add individual devices rather than just setting up a tunnel.

So is wireguard still the gold standard? Or is there a more user friendly solution that will let me compromise a bit but also have a setup that doesn’t require me to be physically on site to fix the inevitable hiccups because it takes hours of reading articles to understand the setup?

Thanks

  • danA
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    4
    ·
    edit-2
    10 months ago

    Their proprietary server doesn’t really do a lot, and most of the logic is in the clients. The server mostly handles configuration (both setting things up and distributing the configs to the clients), public key exchange, and various auxiliary features.

    Your VPN nodes will almost always communicate directly with each other, either by establishing a direct connection, or by UDP hole punching. Tailscale has relay servers that help nodes connect when both are behind restrictive firewalls or NAT, and this is open-source.

    The fact that the data itself is sent peer-to-peer without going through Tailscale’s servers means that it’s an acceptable tradeoff for many use cases.

    • Atemu@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      Hmm, their BE still does a bit as it facilitates the connection of two devices with another. The clients are independently connected to it and if two want to talk with another, they first talk to the BE to coordinate the firewall piercing on both ends.

      Still, given that an OSS re-implementation exists and is in no danger of being canned (TS went ahead and hired the person who made it lol), it being proprietary isn’t a big deal.

      • danA
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        they first talk to the BE to coordinate the firewall piercing on both ends.

        This is the NAT hole punching I mentioned in my post, which as far as I know uses the relay servers (which are open-source) and not their proprietary server. Sometimes systems can reach each other directly (for example, if you forward port 41641) in which case they can directly connect and you don’t need a relay at all.