AdGuard Home beantwortet WireGuard-Clients von Ihrer LAN-Adresse

Der Tunnel ist aktiv, die Firewall erlaubt Port 53, AdGuard Home läuft, und dennoch werden für den WireGuard-Client keine Namen aufgelöst. Die Anfrage kommt normalerweise an und eine Antwort verlässt normalerweise den Server, sodass die Paketzähler auf dem Resolver gesund aussehen und der Dienst unschuldig erscheint. Was schiefläuft, ist die Quelladresse dieser Antwort: sie kommt von einer lokalen Adresse, die der Client nie angefragt hat, und der Stub-Resolver des Clients verwirft sie. Eine Liste in der Konfiguration von AdGuard Home entscheidet darüber, und ihr üblicher Standard überlässt die Entscheidung dem Kernel.

Die Anfrage kommt an, die Antwort verlässt [das System] von einem anderen Ort

Ein Client, der 10.6.0.1 als seinen Resolver konfiguriert hat, sendet eine UDP-Anfrage an 10.6.0.1 Port 53. Dieses Paket überquert den Tunnel und landet auf dem Host, und AdGuard Home beantwortet es. Auf dem Kabel ist die Antwort jedoch ein neues Paket, dessen Quelladresse vom Stack des Hosts gewählt wird, nicht nach den Erwartungen des Clients.

Wenn der Resolver des Clients ein verbundenes Socket ist, was von systemd-resolved, dnsmasq und den meisten Stub-Resolvern verwendet wird, akzeptiert er nur Antworten von der exakten Adresse, an die er gesendet hat. Eine Antwort, die von 192.168.1.10 auf eine an 10.6.0.1 gesendete Anfrage stammt, wird abgeblockt, bevor eine Analyse stattfindet. Der Resolver protokolliert eine erfolgreiche Antwort, der Client protokolliert ein Timeout, und beide sagen die Wahrheit.

Also lügen die Zähler nicht und auch der Kunde lügt nicht. Die Beweise, die Sie benötigen, befinden sich an drei Orten, in dieser Reihenfolge: der Adresse, an die der Listener gebunden ist, der Route, die der Kernel zurück zum Client verwenden würde, und der Quelladresse im tatsächlichen Antwortpaket.

Wie der Kernel die Antwortquelle auswählt

Ein an ... gebundener UDP-Socket0.0.0.0hat keine eigene Quelladresse, daher löst jede ausgehende Antwort eine Routenabfrage für das Ziel aus. Der Kernel nimmt dann die Quelle von dieser Route: die durch die Route festgelegte Adresse oder die primäre Adresse der ausgehenden Schnittstelle. Nichts über die Zieladresse der Abfrage wird gespeichert.

Auf einem einzelnen Host ist dies unsichtbar, weil es nur eine plausible Antwort gibt. Auf einem Rechner, der eine LAN-Adresse, eine WireGuard-Adresse und eine Management-Adresse hat, sind mehrere Antworten plausibel, und der Gewinner hängt von der Routing-Tabelle in diesem Moment ab. Fügen Sie eine zusätzliche Route hinzu, eine zweite Adresse auf derselben Schnittstelle, eine NAT-Umleitung vor dem Resolver oder starten Sie AdGuard in einem Container mit eigenem Namespace, und die gewählte Quelle kann sich von derjenigen unterscheiden, die der Client abgefragt hat.

ss -lunp | grep :53zeigt, in welchem Spiel Sie sich befinden. Ein Listener auf0.0.0.0:53ist der Wildcard-Fall; ein Listener auf10.6.0.1:53hat die Antwort bereits festgelegt. Das Lesen des Sockets ist schneller als das Lesen der YAML und spiegelt wider, was tatsächlich läuft, anstatt was zuletzt gespeichert wurde.

Was bind_hosts tatsächlich steuert

AdGuard Homesdns.bind_hostsist die Liste der lokalen Adressen, die der DNS-Listener verwendet. Der ausgelieferte Standard ist das Platzhalterzeichen (*), was bedeutet, dass auf jeder lokalen Adresse akzeptiert wird und der Kernel für jede Antwort die Quelladresse auswählt. Das Ersetzen des Platzhalters durch die Adresse, die die Clients abfragen, ändert den Socket und damit die Quelladresse jeder Antwort.

Die Liste kann mehr als einen Eintrag enthalten, was bei einem Resolver, der zwei Netzwerke bedient, wichtig ist. Das Auflisten von10.6.0.1und192.168.1.10ergibt zwei gebundene Sockets, und eine auf einem der beiden ankommende Anfrage wird von der Adresse beantwortet, auf der sie angekommen ist. Das ist das Verhalten, das die meisten Leute dem Platzhalter bereits zuschreiben.

Das YAML ist einfach, und die Adresse darin ist die, die Ihre Tunnel-Clients verwenden sollen, nicht die primäre Adresse des Hosts:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Warum zwei Installationen eines Resolvers unterschiedliche Ergebnisse liefern

Plugin-gesteuert bedeutet in diesem Kontext, dass der Resolver von einem anderen Paket installiert wurde und überwacht wird: ein Router-Firmware-Paket, ein NAS-Paket oder ein Home-Automation-Addon. Dieses Paket liefert normalerweise eine eigene Kopie der YAML-Datei von AdGuard Home und startet den Prozess nach eigenem Zeitplan neu, während eine eigenständige Instanz die vom Anbieter bereitgestellte Binärdatei oder den Container ist, den Sie selbst konfigurieren. In beiden Fällen haben Sie es mit zwei unabhängigen Prozessen mit separaten Konfigurationsdateien und separaten Bind-Optionen zu tun, selbst wenn beide dieselbe Upstream-Liste und dieselben Filterlisten lesen. Einer kann die spezifische Tunneladresse binden, während der andere das Wildcard erbt, und die Weboberfläche sieht von beiden Seiten identisch aus.

Deshalb beweist „der gleiche Resolver funktionierte vor der Migration“ nichts über die aktuelle Bindung. Überprüfen Sie die Socket, dann die Konfigurationsdatei, die der laufende Prozess tatsächlich geladen hat. Eine veraltete Kopie in einem anderen Verzeichnis ist ein häufiger Grund dafür, dass die Änderung keine Wirkung zu haben scheint.

Pinnen Sie es, und testen Sie dann von der Tunnel-Seite

Ändern Siebind_hostsauf die Tunnel-Adresse, starten Sie den Dienst neu und bestätigen Sie, dass die Socket verschoben wurde:ss -lunp | grep :53sollte jetzt10.6.0.1:53und keinen Wildcard-Eintrag anzeigen. Wenn es immer noch0.0.0.0,zeigt, liest der laufende Prozess nicht die Datei, die Sie bearbeitet haben.

Testen Sie dann vom Client aus, denn das ist die einzige Seite, die relevant ist. Eine Abfrage mitdig @10.6.0.1 example.comdurchläuft den Pfad, den der Benutzer nutzt, und eine Erfassung auf dem Host mittcpdump -ni wg0 udp port 53zeigt die Quelladresse der Antwort im Netzwerk. Vergleichen Sie sie mit der Adresse in den Resolver-Einstellungen des Clients; wenn sie gleich sind, ist das Timeout kein Rätsel mehr.

ip route get 10.6.0.2erklärt jede verbleibende Eigenart, da es die Schnittstelle und Quelle ausgibt, die der Host für die Rücksendung an den Client verwenden würde. Wenn diese Ausgabe die LAN-Schnittstelle nennt, ist die Bind-Änderung nicht die vollständige Lösung, und die Routing-Tabelle ist das nächste zu überprüfende Element.

Was die Bind-Einstellung nicht beheben kann

Das Festlegen des Listeners repariert weder eine Zugriffsliste, die das Tunnel-Subnetz weglässt, noch eine Firewallregel, die die Abfrage, aber nicht die Antwort erlaubt, noch eine fehlende Route zurück zum WireGuard-Pool. Diese Fehler treten früher oder später als die Quelladresse auf, und jeder hat einen anderen Verantwortlichen.

Es ändert auch nichtan welchen Upstream-Server der Resolver weiterleitet, ob der Schutz vor Rebinding eine private Antwort für einen privaten Namen ablehnt oder wie der Client seine eigenen Suchdomänen anwendet. Das sind separate Kontrollen. Ändere die Bind-Adresse, wenn die Antwortquelle falsch ist, und ändere etwas anderes, wenn sie es nicht ist.