hosts-Datei gegen Routerfilter: eine Seite über VPN sperren

Ein Eintrag in der hosts-Datei und ein Routerfilter blockieren dieselbe Seite aus völlig unterschiedlichen Gründen, deshalb funktioniert das eine unter einer VPN weiter und das andere hört still auf. Die hosts-Datei beantwortet einen Namen, bevor irgendein Paket die Maschine verlässt. Der Routerfilter prüft Verkehr, der ihn durchquert. Legen Sie einen Tunnel zwischen diese beiden Punkte, und der zweite verliert die Sicht, während der erste nichts bemerkt.

Wo der Name aufgelöst wird, entscheidet alles

Jede Sperre beginnt mit einer Frage: Wer macht den Namen zu einer Adresse? Auf einem normalen Desktop antwortet der System-Resolver, der seine konfigurierte Reihenfolge abgeht und üblicherweise die hosts-Datei liest, bevor er DNS fragt. In einem gefilterten Netz kann der Router antworten, der die Anfrage nur sieht, wenn der Client sie ungeschützt durch ihn schickt. Ändern Sie den Weg, und Sie ändern, wer antworten darf.

Eine VPN tut hier zwei Dinge gleichzeitig: Sie verschiebt die Standardroute und kann ihren eigenen DNS-Server vorgeben. Jede der beiden Änderungen reicht aus, um die Namensauflösung von dem Gerät wegzubewegen, das die Sperre durchsetzte.

Das ist der Mechanismus hinter der bekannten Klage, der Filter funktioniere, bis die VPN sich verbindet.

Ein hosts-Eintrag antwortet, bevor der Tunnel existiert

Eine Zeile wie 127.0.0.1 www.example.com liest der lokale Resolver, also entsteht die Antwort auf der Maschine ohne Netzwerk. Tunnel verbinden, DNS-Server ändern, Netz wechseln: Der Eintrag liefert weiterhin loopback. Deshalb ist eine hosts-Sperre die einzige der beiden, die davon unberührt bleibt, wo die VPN endet.

Ihre blinden Flecken sind ebenso lokal. Eine Anwendung, die ihren eigenen Resolver mitbringt, DNS over HTTPS spricht oder sich mit einer wörtlichen Adresse verbindet, fragt das System nie, also wird der Eintrag nicht herangezogen. Eine zwischengespeicherte Adresse in einem laufenden Prozess hat denselben Effekt, bis dieser Prozess neu startet.

Bestätigen Sie die Antwort mit getent ahosts unter Linux oder Resolve-DnsName unter Windows, statt einem Browser-Tab zu vertrauen.

Ein Routerfilter sieht nur, was ihn durchquert

Ein Inhalts- oder URL-Filter auf einem Heimrouter gleicht Namen und Anfragen ab, die ihn in lesbarer Form passieren. Baut der Client einen verschlüsselten Tunnel zu einem Server anderswo auf, sieht der Router einen einzelnen Fluss zu diesem Server und nichts darin. Der Filter hat keinen Namen zum Abgleichen, also lässt er den Verkehr durch, und das wirkt, als hätte der Filter versagt, nicht als wäre er umgangen worden.

Die Topologie, die funktioniert, ist die andere: Der Router hält den Tunnel selbst, entschlüsselt am Endpunkt und wendet den Filter dort an. In diesem Entwurf sitzt der Filter dort, wo der Klartext erscheint.

Endet der Tunnel auf dem Laptop, liegt der Router per Definition außerhalb des geschützten Wegs, egal wie die Regel geschrieben ist.

Vier Durchsetzungspunkte und was jedem entgeht

Vier Stellen können eine Sperre durchsetzen, und jede scheitert anders. Lesen Sie die Liste als Abdeckungskarte, nicht als Rangfolge.

• hosts-Datei oder lokaler Resolver: funktioniert offline und unter jedem Tunnel, wird aber von einem mitgelieferten Resolver oder einer fest eingetragenen Adresse umgangen.
• DNS-Filterung am VPN-Gateway: deckt Clients ab, die den vorgegebenen Resolver nutzen, und verfehlt Clients, die DNS überschreiben.
• Gateway-Ausgangsregeln nach Adresse oder SNI: unabhängig vom DNS des Clients, aber blind für Namen, die es nicht lesen kann, und für Adressen, die es nicht gelernt hat.
• Verwaltete Browser- oder Geräterichtlinie: stark auf verwalteter Hardware, fehlend auf privaten Geräten.

Nichts davon ist eine Sicherheitsgrenze gegen einen entschlossenen Nutzer auf einem unverwalteten Gerät. Es sind Richtlinienkontrollen, und eine ehrliche Beschreibung sagt, welchen Verkehr jede tatsächlich abdeckt.

Wählen Sie die Ebene, die zur Absicht passt: häuslicher Komfort gehört aufs Gerät, eine organisatorische Regel gehört ans Gateway.

Testen Sie beide Zustände, bevor Sie es fertig nennen

Führen Sie dieselben drei Befehle mit verbundener und getrennter VPN aus: getent ahosts für die Antwort des Resolvers, nslookup dafür, was die Anfrage zurückgibt, und curl -I gegen die Seite dafür, ob eine Verbindung noch zustande kommt. Wenn der erste loopback zurückgibt, während der dritte die echte Adresse erreicht, hat etwas den Resolver umgangen, und der hosts-Eintrag ist nicht die Kontrolle, für die Sie ihn halten.

Lesen Sie am Router die Filterzähler vor und nach einer Anfrage. Ein Zähler, der sich nie bewegt, bedeutet, dass der Verkehr den Filter nie erreichte, und das ist eine Routing-Antwort, keine Regel-Antwort.

Notieren Sie das Ergebnis zusammen mit der Topologie, denn die nächste VPN-Änderung verschiebt den Weg erneut.