search

jwhited / wgsd

A CoreDNS plugin that provides WireGuard peer information via DNS-SD semantics
https://www.jordanwhited.com/posts/wireguard-endpoint-discovery-nat-traversal/
MIT License
806 stars 74 forks source link

same network discovery #3

Open heeen opened 4 years ago

heeen commented 4 years ago

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.

jwhited commented 4 years ago

What happens if both peers are on the same network, i.e. behind the same router/gateway/nat?

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.

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?

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.

yinheli commented 1 year ago

Any updates about "candidates" implementation?