search

freifunkMUC / wg-access-server

An all-in-one WireGuard VPN solution with a web ui for connecting devices
MIT License
606 stars 33 forks source link

Generate DNS entries for connected hosts. #66

Closed gravypod closed 2 years ago

gravypod commented 2 years ago

It would be awesome if you could generate DNS names for clients connected to the network. For a given search domain of vpn it would be great if <machine>.<user>.vpn would resolve to the IP address of the client. It would be even better if you could have a wildcard DNS setup for <application>.my-machine.admin.vpn this way you could use vhosts on a machine to forward many applications.

DasSkelett commented 2 years ago

Where should the DNS records be generated, for whom should they be visible? Intercepting the requests in the proxy, and serving a dynamic record (to VPN clients and others who can reach the proxy) could be doable, for more complex scenarios reading the database with external tooling and using that to configure a true authoritative server might be the better way to go.

gravypod commented 2 years ago

Hey! Sorry it's taken me a while to get back @DasSkelett. Ideally it could be built directly into the dnsproxy. You could also add Domain to the wireguard config to configure a search domain. This would let you support the following domain names:

  1. <device>.<user>.vpn.example.com
  2. <device>.<user>.vpn
  3. <device>.vpn

This would mean you would only need one component to be alive to have DNS entries (and one cache to invalidate).

DasSkelett commented 2 years ago

Working on this now: https://github.com/freifunkMUC/wg-access-server/compare/master...DasSkelett:feature/generate-client-dns I went with vpn.home.arpa. as default domain, as per RFC 8375.

I'm not yet sure whether <device>.vpn will work, as device names are not guaranteed to be unique across users. So this would only work if it's running with a single user, which needs to be detected first.

So far it worked fine in testing. It probably violates a few dozen RFCs (my biggest concern is the lack of SOA records, especially for negative answers), but I think it works good enough.

The queries/responses aren't cached yet, every query causes a lookup for the device in the database. I'm still thinking on how a possible cache should be designed. One option would be a "packet cache" like the existing one for the proxy, where the response message for each query is stored. Alternatively, we could cache the device addresses after looking them up from the database. Or a third option, the most complex one but maybe also the cleanest, is pregenerating the "zone" (map of device/owner names->addresses or similar) and "pushing" it to the auth handler. This might also be the easiest to invalidate/update on device changes.