11–20 of 118 posts
This was better solved by tinc about 20 years ago. All tinc nodes can work as relays (but you can disallow that if you want), it does not rely on a centralized server, and works fine without access to the internet. It is a true mesh. The world would be better served by porting tinc to wireguard and some memory safe language instead of reimplementing parts of its functionality from scratch.
How does this interact with machines that are shared from one Tailnet to another? Is there specific syntax to grant the appropriate permission to a user or device that accesses the destination via sharing? The docs also say: > As a rule of thumb, the src devices in the grant policy should typically be devices in a stable physical location behind a strict NAT or firewall that prevents direct connections. This typicall…
I was also a bit confused on the meaning of src/dst in the grants. The naming didn't match my thinking.
How does this interact with machines that are shared from one Tailnet to another? Is there specific syntax to grant the appropriate permission to a user or device that accesses the destination via sharing? The docs also say: > As a rule of thumb, the src devices in the grant policy should typically be devices in a stable physical location behind a strict NAT or firewall that prevents direct connections. This typicall…
In your example the src would be the "machine that is behind a NAT". That's the one the peer relay enable access to. And then all your other devices (that laptop) can reach it through the peer relay. I was also a bit confused on the meaning of src/dst in the grants. The naming didn't match my thinking.
This was better solved by tinc about 20 years ago. All tinc nodes can work as relays (but you can disallow that if you want), it does not rely on a centralized server, and works fine without access to the internet. It is a true mesh. The world would be better served by porting tinc to wireguard and some memory safe language instead of reimplementing parts of its functionality from scratch.
Wireguard can do what you're describing.
I wonder if the next step could be to have all tailscale clients automatically able to accept forwarding requests between any two machines within the tailnet, so that the mesh seamlessly auto-routes around any breaks within the mesh?
How does this interact with machines that are shared from one Tailnet to another? Is there specific syntax to grant the appropriate permission to a user or device that accesses the destination via sharing? The docs also say: > As a rule of thumb, the src devices in the grant policy should typically be devices in a stable physical location behind a strict NAT or firewall that prevents direct connections. This typicall…
With Tailscale Peer Relays, the available relay bindings can be seen by the devices on either side of a connection; as such it should work out of the box with a sharing relationship between tailnets.
I wonder if the next step could be to have all tailscale clients automatically able to accept forwarding requests between any two machines within the tailnet, so that the mesh seamlessly auto-routes around any breaks within the mesh?
Yeah, such extension is natural and it comes up frequently in the context of overlay networks. The defining question here is if you are OK with relaying other people's CP traffic.