Submitted ⁨⁨1⁩ ⁨year⁩ ago⁩ by ⁨Wander@packmates.org⁩ to ⁨fediverse@lemmy.world⁩

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

source

Comments

Sort:hotnew top

despotic_machine@lemmy.world ⁨1⁩ ⁨year⁩ ago
veilid.com

source
- Wander@packmates.org ⁨1⁩ ⁨year⁩ ago
  @despotic_machine thank you. This sounds interesting!
  source
Wander@packmates.org ⁨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.
source
breadsmasher@lemmy.world ⁨1⁩ ⁨year⁩ ago
isn’t this just TOR

source
- Wander@packmates.org ⁨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.
  source
  - fenwickrysen@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Here’s how TOR works. It’s amazing.
    
    youtu.be/QRYzre4bf7I?si=gY1e4tORIoxwuRTx
    
    And here’s how Onion hidden services work…
    
    youtu.be/lVcbq_a5N9I?si=PuJwHP0rEPKFkCBb
    
    TOR lets journalists do their job safely from dangerous places, lets whistle-blowers report things we should know, and lets people in oppressive regimes see the rest of the Internet that their government blocks. It’s an amazing tool.
    
    source
    -> View More Comments
trymeout@lemmy.world ⁨1⁩ ⁨year⁩ ago
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.

source
Synthead@lemmy.world ⁨1⁩ ⁨year⁩ ago
What security implications does this involve?

source
nysepho@furry.engineer ⁨1⁩ ⁨year⁩ ago
@Wander @fediverse neat. sounds a bit like dn42, but federated and I am guessing without transit/routing to other users you aren't directly peered with?
source
- Wander@packmates.org ⁨1⁩ ⁨year⁩ ago
  @nysepho @fediverse there would be routing without being peered directly by delegating your endpoint to another peer you trust (this can create an infinitely long routing chain depending on where you latch on so to speak, but you would be in control)
  source
  - tony@lemmy.hoyle.me.uk ⁨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…
    
    source