search

tonarino / innernet

A private network system that uses WireGuard under the hood.
https://blog.tonari.no/introducing-innernet
MIT License
4.99k stars 185 forks source link

Client option to route traffics to server or other peer #210

Open himekifee opened 2 years ago

himekifee commented 2 years ago

I used vanilla wireguard to build a small private network for device communications. I had a central server as a wireguard gateway to route all my device's traffic through that. This server also forward traffics within the private network so I can have communications between peers (not peer to peer though). With the help of innernet, communications between peers can be optimized since they can be peer to peer. However, there is one functionality lacking which is to route traffics through server or other peers. I'd imagine this can be done by adding an ip route just like wg-quick does. It would also be quite helpful to add PostUp, PostDown hooks to customize settings by users. One more point, in this scenario, I want to use the old wireguard gateway server as the new coordination server since it is the only peer with a public IP address. In this case, will it be more elegant to create a peer within the child cidr and install another wg interface on the server, or just left it and use the unique innernet-server peer?

esbeeb commented 2 years ago

I too expected the innernet-server to "magically" route between peers within the same CIDR (not the infra, or root CIDR, but the same child CIDR, the example given in the docs is called "humans"). I mean, what was the point of making them "peers" within the same child-CIDR, if you can't do that peer-to-peer routing? It's just to conveniently and wireguarded-ly connect to the innernet-server, that's all new peers really gain, IMHO.

At present, peers can talk to each other if they are on the same LAN (and very efficiently so, with very low latency), but no "firewall punching" goodness happens to communicate to other peers (magically routing through the innernet-server) within the same CIDR, but not in the same LAN.

So a given peer can only talk to fellow peers (using internal innernet hostnames/IP addresses) in the same child-CIDR, and same LAN. That's no super-power, since these peers were in the same LAN anyway.

Don't get me wrong: innernet has several things to really like, such as:

However...

The initial animated image showing "jake" pinging "grandma" - yeah, that only worked because jake and grandma needed to be in the same (non-innernet) LAN anyway! No magic there! No firewalls got "punched" between jake and grandma.

BTW: I'm confused as to whether I install both innernet-server and innernet on the cloud innernet server, or just innernet-server on the cloud innernet server, at first. I assumed the latter.