VPN-DNS-Filter: Namen zu sperren blockiert keine Werbung

Eine einzige dnsmasq-Zeile kann einen Namen mit NXDOMAIN beantworten, und das ist der ganze Mechanismus. Sie liest nie HTML, prüft nie einen Anforderungspfad und sieht nie, was eine Anwendung mit einer Verbindung tut, die sie bereits geöffnet hat. Ein Vergleich mit einer Browsererweiterung ist daher ein Vergleich zweier verschiedener Aufgaben. Die eine entscheidet, ob ein Name aufgelöst wird; die andere entscheidet, was danach geschieht.

Was ein Namensfilter tatsächlich steuert

Die Option address=/metrics.example/, ohne alles nach dem letzten Schrägstrich, lässt den Resolver für diesen Namen und seine Subdomains NXDOMAIN zurückgeben. Die Adresse leer zu lassen ist der wichtige Teil: So werden Clients nicht an einen unabhängigen Ersatzserver geschickt und eine Loopback-Adresse wird nicht als echtes Ziel ausgegeben. Das dnsmasq-Handbuch beschreibt diese Form als negative Antwort und nicht als Weiterleitung.

Alles, was die Regel leisten kann, folgt aus dieser einen Entscheidung. Ein Client, der diesen Resolver fragt, erhält eine negative Antwort; ein Client, der einen anderen Resolver fragt, erhält, was jener Resolver sagt. Der Filter weiß nichts darüber, welchen Pfad, welche Abfragezeichenkette oder welches Konto die Anwendung verwendet hätte.

Diese Feinheit zählt, weil ein Hostname oft mehreren Zwecken dient. Anmeldeendpunkte, Bilder und Tracking können sich eine Domain teilen, und eine Regel, die den ganzen Namen entfernt, kann einen Arbeitsablauf mitentfernen. Eine Richtlinie auf Namensebene muss diesen Kompromiss akzeptieren oder engere Namen wählen.

Wo sich ein Blocker im Client unterscheidet

Eine Browsererweiterung sieht die Anforderung, bevor sie das Gerät verlässt, und kann daher einen URL-Pfad abgleichen, eine bestimmte Anforderung abbrechen und das Element ausblenden, das das Ergebnis angezeigt hätte. Sie kann example.com/article erlauben und example.com/ads/ ablehnen, was keine DNS-Antwort ausdrücken kann. Diese Sicht auf Pfadebene ist die Fähigkeit, die ein Resolver schlicht nicht hat. Deshalb verhält sich eine Filterliste, die für ein Werkzeug gebaut wurde, im anderen selten gleich.

Der Preis ist die Reichweite. Dieser Schutz lebt in einem Browser, in einem Profil, auf einem Gerät, und er verschwindet, wenn der Nutzer zu einer anderen Anwendung wechselt. Ein DNS-Filter, der am Gateway konfiguriert ist, deckt jedes Gerät ab, das den Resolver des Gateways verwendet, auch Geräte, auf denen sich keine Erweiterung installieren lässt.

Keine der beiden Anordnungen ist für sich vollständig. Ein DNS-Filter kann keine Kennung entfernen, die eine Seite bereits gesendet hat, und eine Browsererweiterung kann keine Anwendung schützen, die sie nie lädt.

Der Resolver-Pfad entscheidet, ob davon überhaupt etwas greift

Ein VPN kann einen DNS-Server ankündigen und trotzdem nicht jede Abfrage erhalten. Ein Browser mit konfiguriertem verschlüsseltem DNS, eine Anwendung mit eigenem Resolver oder ein Gerät auf einem Netzwerkpfad, der das Gateway ausschließt, schauen alle woanders nach. Mobile Plattformen bieten zunehmend eine Einstellung für privates DNS, die still überschreibt, was der Tunnel vorschlägt.

Testen Sie also den Pfad und nicht die Richtlinie. Fragen Sie den vorgesehenen Resolver direkt vom Gateway, fragen Sie ihn dann von einem Client und vergleichen Sie, und beobachten Sie dann, ob ein Name, der blockiert werden sollte, in der Anwendung, die der Nutzer ausführt, tatsächlich fehlschlägt.

Zwischengespeicherte Antworten und offene Sockets machen das unübersichtlich. Eine Seite, die ihre Ressourcen bereits geladen hat, funktioniert nach der Regeländerung weiter, daher ist eine frische Verbindung ein besserer Test als das Neuladen eines alten Tabs.

Testen Sie beide Richtungen, bevor Sie ein Ergebnis behaupten

Verwenden Sie einen absichtlich gesperrten Dokumentationsnamen, einen erlaubten öffentlichen Namen und einen privaten Namen, den der Dienst braucht:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Eine leere Antwort für den gesperrten Namen, eine normale Adresse für den öffentlichen und eine private Adresse für den internen zeigen zusammen, dass Filterung, Auflösung über den vorgelagerten Server und lokale Einträge alle funktionieren. Wenn alle drei fehlschlagen, sehen Sie ein Problem beim vorgelagerten Server oder beim Listener und nicht beim Filter.

Halten Sie die Behauptung eng in allem, was Sie intern veröffentlichen. Das ist Domänenfilterung auf einem Resolver, keine Inhaltsprüfung, keine Pfadfilterung und kein Versprechen, dass niemand verfolgt wird. Nennen Sie den Verantwortlichen der Richtlinie, den Ausnahmeweg und die Aufbewahrungsfrist für Abfragen neben den Regeln, denn ein Filter, der jede Anfrage protokolliert, hat seine eigenen Datenschutzkosten.