Geben Sie Ihrem Heim-VPN eigene DNS-Einträge für nas.home.arpa
Veröffentlichen Sie einen Namen aus dnsmasq, leiten Sie den Resolver durch WireGuard und wählen Sie dann zwischen DNS für den gesamten Client und Split-DNS nur für home.arpa.
Sobald der Tunnel steht, ist der letzte Schritt meist ein Name, der funktioniert, statt einer Adresse, die Sie in ein Lesezeichen einfügen. Ein dnsmasq-Host-Eintrag plus eine Resolver-Adresse, die der Client erreicht, leisten das mit zwei Dateien und ohne Multicast. Die Entscheidung, die wirklich Nachdenken erfordert, ist enger: Schickt der Client alles DNS über den Heim-Resolver, oder nur die Namen unter home.arpa? Alles Folgende setzt ein genehmigtes WireGuard-Setup mit einem Linux-Client und einem Labor-Resolver voraus, den der Heim-Administrator bereits betreibt.
Drei Wege, dem Client einen Resolver zu geben
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
Für ein Laptop, das gelegentlich in den Tunnel kommt, ist Split-DNS die bessere Voreinstellung: Es hält gewöhnliche Internetnamen beim Resolver, dem die Maschine bereits vertraut. Für eine Maschine, die es gibt, um Heimdienste zu erreichen, ist das Durchsetzen des Resolvers einfacher, und die Kosten des Umfangs spielen keine Rolle.
Veröffentlichen Sie den Eintrag bei dem Resolver, der die Zone besitzt
Halten Sie die Rollen auseinander, bevor Sie Konfiguration schreiben: VPN-Client-Adresse, Resolver und Dienst sind drei verschiedene Hosts mit drei verschiedenen Aufgaben. In diesem Labor sind das 10.77.0.2 für den Client, 192.168.50.53 für dnsmasq und 192.168.50.20 für das NAS, wobei der Tunnel das Heim-LAN routet.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20
Die Zeile host-record liefert die Adresse, und die Zeile local= hält unbekannte home.arpa-Fragen in diesem Resolver, statt sie weiterzuleiten. Lesen Sie zuerst Ihre bestehende Konfiguration und gleichen Sie alles ab, was bereits einen Server, eine Schnittstelle oder dieselbe lokale Domain definiert; ein Fragment auf ein widersprüchliches zu stapeln, ergibt einen Resolver, der fröhlich lädt und falsch antwortet. Das dnsmasq-Handbuch definiert beide Direktiven und die Lauschsteuerung.
Prüfen Sie dann den laufenden Dienst, nicht die Datei. Ein Konfigurationstest plus Neustart ist das Minimum, und die effektive Antwort ist das, was eine Abfrage zurückgibt.
Routen Sie den Resolver, nicht nur die Webseite
Die AllowedIPs von WireGuard entscheidet, welche Ziele in den Tunnel gelangen. Fällt die Resolver-Adresse daraus heraus, verlässt die Abfrage die normale Route und erreicht dnsmasq nie, obwohl das NAS selbst erreichbar ist. Nehmen Sie die Adresse des Resolvers auf, oder das LAN-Präfix, das sie enthält, und prüfen Sie die Weiterleitungsrichtlinie des Gateways auf der anderen Seite.
Erlauben Sie UDP und TCP auf Port 53 aus dem autorisierten Tunnelbereich, mit einem Rückweg zur Tunneladresse des Clients. Leiten Sie Port 53 nicht aus dem WAN weiter, um Tests zu erleichtern: Ein offener rekursiver Resolver an einem Heimanschluss wird innerhalb von Stunden gefunden. Das Binden an eine Schnittstelle ist für sich genommen keine Zugriffsrichtlinie.
Prüfen Sie die Antwort vor der Anwendung
Fragen Sie zuerst den Resolver direkt, dann das System, dann die Anwendung. Jeder Schritt isoliert ein Glied in der Kette, und der Unterschied zwischen ihnen ist die Diagnose.
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'
Die TCP-Abfrage lohnt sich, weil eine abgeschnittene UDP-Antwort einen erneuten Versuch erzwingt, und eine Richtlinie, die TCP 53 verwirft, erzeugt Fehler, die sporadisch wirken. Der Schritt getent zeigt, was die Resolver-Konfiguration der Maschine tatsächlich tut, was nicht immer das ist, was Sie ausgerollt haben.
Entscheiden Sie, was passiert, wenn der Tunnel aus ist
Wenn das allgemeine DNS des Clients auf 192.168.50.53 zeigt, hört jede Namensauflösung auf zu funktionieren, wenn der Tunnel nicht steht. Das ist akzeptabel auf einer Maschine, die nur mit dem Tunnel nützlich ist, und inakzeptabel auf einem Laptop, das auch Café-WLAN nutzt. Split-DNS umgeht die Frage ganz, weil nur home.arpa-Abfragen vom Heim-Resolver abhängen.
Denken Sie daran, was der Name ist: home.arpa ist für Wohnnetze reserviert und nicht global eindeutig, also kann ein anderes Netzwerk denselben Namen legitim verwenden. Er ist eine lokale Bequemlichkeit, keine vertrauenswürdige Kennung. Halten Sie den Eintrag aktuell, wenn der Dienst umzieht, und entfernen Sie die Resolver-Richtlinie, wenn das Labor stillgelegt wird, statt ein Laptop zurückzulassen, das auf eine Adresse zeigt, die es nur durch einen Tunnel erreicht, den es nicht mehr gibt.