Federated wireguard network idea
Any feedback welcome.

Let’s keep things stupidly simple and simply hash the domain name to get a unique IPv6 ULA prefix.

Then we would need a stupidly simple backend application to automatically fetch pubkeys and endpoints from DNS and make a request to add each others as peers.

Et voilà, you got a worldwide federated wireguard network resolving private ULA addresses. Sort of an internet on top of the internet .

The DNS entries with the public IPv4 / IPv6 addresses could even be delegated to other domains / endpoints which would act as reverse proxy (either routing or nesting tunnels) for further privacy.

Maybe my approach is too naïve and there are flaws I haven’t considered, so don’t be afraid to comment.

Exact use cases? Idk, but it sounds nifty.

#privacy #networking #VPN #wireguard #infosec

cc: @fediverse

  • Wander ΘΔ :verified_paw:@packmates.orgOP
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    @fediverse I’ve read that this is called an overlay network. Unfortunately many of the ones I’ve seen documented focus on keeping things in their own private networks which is okay but not fun.

    ULA addresses require no permission and were designed precisely to knit together private networks. We can just use domain names and convert them via checksum into a static ULA /48 prefix. DNS can be used to announce routes, or eventually something more BGP-like given that ownership of a domain can be verified and thus authorization to announce routes.

    If domains ever become a bottleneck one could use private TLDs with some consensus mechanism and even create multi-layer networks this way where packmates.layer.1 and packmates.layer.2 are two different networks even though they might have the same address range.

    Anyways, I’ll go out and touch some grass now.

  • trymeout@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    https://github.com/ivpn/desktop-app/issues/290

    I made this feature request to IVPN. I doubt IVPN will make it happen but I also did it to get the idea out there. I do think IVPN clients are the best FOSS VPN clients on the market and the idea was to fork IVPN desktop and mobile clients and modify them to bee these universal VPN clients were any VPN provider can integrate these clients into their service. This way a user can subscribe to a few or several VPN providers and access them all in one client, easy to add providers in the client. All a user needs to do is add a URL or IP address in the subscription settings of the VPN client, and login to the VPN account and from there the VPN client will import the VPN servers that VPN providers has and always keep them up to date when the VPN providers adds or remove servers.

    Also such an idea will ensure there is a one, secure and fully open source VPN client that works with many VPN providers, and VPN providers do not need to spend time and money developing their own clients for desktop and mobile, and can instead spend time and money on their service and servers. VPN providers can contribute to the universal VPN client if they so wish.

    • Wander ΘΔ :verified_paw:@packmates.orgOP
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 year ago

      @breadsmasher I have no idea how Tor works. In this case I would say most peers would have no problem disclosing a public IP, but it could have benefits in making resources in a private network accessible and as long as the endpoint can be reached those resources would be hosting provider agnostic.

      I would say this is less about hiding user activity than it is about logical networks, abstracting away the hosting provider and allowing to knit together self hosted services, regardless of where they are hosted.

      • tony@lemmy.hoyle.me.uk
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Routing would be the hard bit I expect… if the person you were communicating was 10 hops away how to find the route? Things like BGP do that naturally, but really you don’t want to burden potentially nontechnical users with BGP…