-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
same network discovery #3
Comments
This depends on the behavior of the gateway device. Some of the gateways I've played with will not forward traffic coming in on the "internal" interface with a destination address of the "external" interface that translates back to the "internal" interface.
I think that the WebRTC approach defined in ICE RFC5245 gives us some ideas. ICE gathers what it calls "candidates" (IP address + port) and attempts to establish connectivity over all candidates. There are different types of candidates, one of which could be learned via STUN (similar to what we do in this project), another could be a local interface. In this case of two peers behind the same layer 3 gateway, ICE will ultimately have them choose the local interface candidate, assuming it is prioritized over the others. We can't exactly implement ICE since we exist outside of WireGuard, but we can borrow some of its concepts. Candidates are SRV+A/AAAA record pairs. Right now we just have one candidate per peer, which is discovered from the tunnel with the Registry. SRV records can have priorities just as ICE candidates do. We just need a way to "push" host candidates to wgsd. This could be the responsibility of the client. I haven't looked much into the various methods available for pushing DNS updates, but I imagine there is a standard for this. So long as wgsd could verify the push came from peer that the update is intended to modify SRV records for, this could work. |
Any updates about "candidates" implementation? |
What happens if both peers are on the same network, i.e. behind the same router/gateway/nat?
Would it be possible to figure this out by e.g. adding something unique about the network (gateway mac address? gateway public ip?) to the dns record and resolving to the all LAN IP addresses on that network so that peers could try to discover each other in a LAN?
Another option would be SSDP but then you would have to patch into a systems SSDP server like avahi.
The text was updated successfully, but these errors were encountered: