Vielen Dank an The Social Dork | Cybersicherheit für das Teilen eines Pi-hole- und Tailscale-Projekts, das DNS-Anfragen zu Hause und unterwegs über ein Smartphone filtert. ZimaBoard 2 betreibt die Dienste, Pi-hole prüft angefragte Domains und Tailscale stellt eine private Verbindung zum Server her. Sieh dir die Originalanleitung auf YouTube für die vollständige Demonstration an.
Vor dem Lesen ansehen: Dieses achtminütige Video ist hilfreich, wenn du verstehen möchtest, wo netzwerkbasierte Werbefilterung ansetzt, bevor du die DNS-Einstellungen deines Haushalts änderst. Der Ersteller installiert Pi-hole in ZimaOS, testet einen Windows-Client, fügt Blocklisten hinzu und verbindet anschließend ein Smartphone über Tailscale.
Das nützliche Ergebnis ist ein wiederverwendbarer DNS-Filterdienst. Der Ersteller zeigt weniger sichtbare Werbung auf einer Beispielwebsite und DNS-Abfrageaktivitäten des entfernten Smartphones. Diese Beobachtungen zeigen, dass der Filterweg in dieser Konfiguration funktioniert; sie belegen nicht, dass jede Werbung, jeder Tracker oder jede schädliche Verbindung blockiert wird.
Verstehe, was Pi-hole filtert, bevor du die Hardware auswählst
Die Erklärung beginnt mit einer Website, die Inhalte von mehreren Domains lädt. Pi-hole empfängt die DNS-Anfragen des Clients und prüft die angefragten Namen anhand der konfigurierten Richtlinien. Erlaubte Namen können über einen Upstream-Resolver aufgelöst werden; blockierte Namen erhalten eine blockierende Antwort. Der entscheidende Kontrollpunkt ist die DNS-Abfrage, bevor der Client versucht, Inhalte von dieser Domain abzurufen.
Dieser Geltungsbereich setzt zugleich Grenzen. Ein DNS-Filter kann eine Werbeanzeige nicht von gewünschten Inhalten unterscheiden, wenn beide denselben Hostnamen verwenden. Clients, die einen anderen Resolver nutzen, können den gewählten Weg umgehen. Betrachte den Titel des Videos „Alle Werbung blockieren“ als Motivation für das Projekt und nicht als allgemeingültiges Ergebnis. Inhaltsfilter im Browser und DNS-Filter arbeiten auf unterschiedlichen Ebenen und können sich ergänzen.
| Komponente | Aufgabe im Projekt | Was du noch überprüfen musst |
|---|---|---|
| Pi-hole | Wendet Domainrichtlinien auf DNS-Anfragen an, die den Dienst erreichen. | Der tatsächlich von jedem Client verwendete Resolver. |
| Upstream-Resolver | Beantwortet erlaubte Abfragen, die Pi-hole nicht lokal beantworten kann. | Erreichbarkeit und Weiterleitungsweg. |
| Tailscale | Stellt eine private Verbindung zwischen registrierten Geräten her. | Erreichbarkeit des Nameservers und DNS-Einstellungen des Clients. |
| Browser oder App | Ruft Inhalte ab, nachdem das Ziel aufgelöst wurde. | Jede unabhängig konfigurierte verschlüsselte DNS-Verbindung und jede zwischengespeicherte Antwort. |
Verfolge eine einzelne DNS-Abfrage durch das System, bevor du ein ganzes Netzwerk umstellst. Ein Client fragt einen Hostnamen ab; Pi-hole wendet seine Richtlinien an; eine erlaubte Anfrage kann den Upstream-Resolver erreichen; die Antwort geht an den Client zurück. Die anschließende Webverbindung ist ein separater Datenfluss. Deshalb ist ein Zähler für blockierte Domains ein nützlicher Hinweis auf DNS-Aktivitäten, misst aber nicht jede Verbindung, die eine Anwendung herstellt.
Gib dem DNS-Dienst einen festen Platz im Heimnetzwerk
The Social Dork verwendet ZimaBoard 2 und installiert Pi-hole über den im Video gezeigten ZimaOS-App-Store. Der Ersteller erwähnt außerdem einen vorhandenen Laptop als alternative Hostmaschine. Entscheidend ist, dass das Gerät verfügbar bleibt, wenn Clients auf seine DNS-Dienste angewiesen sind. Die Demonstration liefert keinen Grund, nur für die Filterung die größte Arbeitsspeicher-Option zu kaufen.
Verbinde den Host, gib dem DNS-Endpunkt eine stabile Adresse oder DHCP-Reservierung und überprüfe, ob der Dienst von einem Testclient aus erreichbar ist. Container-Netzwerk und Portzuordnungen beeinflussen, welche Adresse Clients verwenden sollten. Vergewissere dich, dass deine Installation an diesem Endpunkt tatsächlich DNS-Abfragen beantwortet. Eine erreichbare Administrationsseite allein beweist nicht, dass der DNS-Dienst einsatzbereit ist.

Adressen notieren, bevor du einen Client änderst
| Adresse oder Einstellung | Verwendung | Häufige Verwechslung |
|---|---|---|
| Pi-hole-LAN-Endpunkt | DNS für Geräte im Heimnetzwerk. | Eine interne Docker-Adresse ist möglicherweise vom Laptop aus nicht erreichbar. |
| Tailscale-Adresse des Servers | Privater DNS-Zugriff von registrierten Geräten, die nicht zu Hause sind. | Die LAN- und Tailscale-Adressen sind unterschiedliche Endpunkte. |
| DNS-Upstream-Ziel | Von Pi-hole weitergeleitete zulässige Abfragen. | Wenn du als Ziel einen Resolver einträgst, der Anfragen an Pi-hole weiterleitet, entsteht eine Schleife. |
| Administrations-URL | Richtlinien und Abfrageaktivität anzeigen. | Dass eine Webseite geladen wird, beweist nicht, dass DNS-Port 53 erreichbar ist. |
Prüfe bei einer Container-Installation, ob der DNS-Dienst sowohl über TCP als auch über UDP erreichbar ist. Das offizielle Docker-Beispiel von Pi-hole stellt beide Protokolle über Port 53 bereit und speichert das Konfigurationsverzeichnis dauerhaft. Diese Details sind wichtig, auch wenn ein App-Store die Container-Konfiguration hinter einer Schaltfläche „Installieren“ verbirgt. Lies die tatsächliche App-Konfiguration, bevor du einen Hostdienst änderst, der möglicherweise bereits denselben Port verwendet.
Das Video zeigt die Installation über den ZimaOS-App-Store des Erstellers. Deine aktuelle App-Version und dein Netzwerkmodus können abweichen. Bewahre die Einstellungen auf, aus denen hervorgeht, wie die App das Netzwerk erreicht: ihre Adresse, veröffentlichte Ports, den Speicherort, den Upstream-Resolver und das Neustartverhalten. Diese kurze Dokumentation erleichtert es, eine spätere Migration oder Neuinstallation zu überprüfen.
Einen Client testen, bevor du den DNS für den Haushalt änderst
In der Anleitung bleibt ein Windows-Laptop mit dem heimischen WLAN verbunden, während seine IPv4-DNS-Einstellung auf die Pi-hole-Adresse geändert wird. Anschließend prüft der Ersteller die Abfrageaktivität. Das ist ein überschaubarer erster Test: Falls das Surfen nicht mehr funktioniert, muss nur dieser Client zurückgesetzt werden, während der Rest des Haushalts seine bisherige Konfiguration beibehält.

Für eine umfassendere Abdeckung erklärt Pi-holes Anleitung nach der Installation, wie DHCP den Clients die Pi-hole-DNS-Adresse mitteilen kann. Erneuern Sie die Lease des Clients oder verbinden Sie ihn erneut und prüfen Sie, welchen Resolver er tatsächlich verwendet. Überprüfen Sie außerdem die IPv6-DNS-Einstellungen sowie verschlüsselte DNS-Einstellungen im Browser oder Betriebssystem. Die Änderung eines einzelnen IPv4-Felds beweist nicht, dass jede Abfrage darüber läuft.
Auch ein zweiter, ungefilterter Resolver kann das erwartete Ergebnis beeinträchtigen. Clients verwenden möglicherweise einen anderen konfigurierten Resolver, statt ihn ausschließlich als Notfalloption bereitzuhalten. Entscheiden Sie, ob Ausfallsicherheit oder einheitliche Filterung Vorrang hat, und testen Sie das Verhalten, wenn der Pi-hole-Host nicht verfügbar ist. Notieren Sie die ursprünglichen Einstellungen, damit sich ein DNS-Experiment leicht rückgängig machen lässt.
Einen wiederholbaren lokalen Test durchführen
- Notieren Sie die aktuelle DNS-Konfiguration des Laptops und den vorgesehenen Pi-hole-Endpunkt.
- Senden Sie eine erlaubte Abfrage explizit an Pi-hole und suchen Sie anschließend die passende Anfrage im Protokoll.
- Testen Sie eine Domain, die in Ihrer eigenen aktiven Sperrliste steht, und prüfen Sie, ob sie blockiert wird.
- Legen Sie Pi-hole als bevorzugten DNS-Server des Clients fest und wiederholen Sie den Test, ohne explizit einen Resolver auszuwählen.
- Rufen Sie einige übliche Dienste auf, darunter auch einen Anmeldevorgang, bevor Sie die Änderung über DHCP ausrollen.
Zum Beispiel testet nslookup example.com PIHOLE_LAN_IP einen bestimmten Resolver; ersetzen Sie PIHOLE_LAN_IP durch die Adresse Ihres Servers. Diese explizite Abfrage prüft den Endpunkt selbst. Ein anschließendes nslookup example.com prüft den gewöhnlichen Resolver-Pfad des Systems. Keiner der beiden Tests allein beweist, dass ein Browser mit eigenen DNS-Einstellungen denselben Weg verwendet. Prüfen Sie daher auch eine neue Anfrage aus dieser Anwendung.
Wenn Sie nach einem Fehler suchen, prüfen Sie die Erreichbarkeit der Adresse getrennt von der Namensauflösung. Ein Gerät kann weiterhin mit dem WLAN verbunden sein und trotzdem keine Websites öffnen, weil sein DNS-Endpunkt offline ist. Lassen Sie die ursprünglichen Client-Einstellungen unverändert, bis der neue Resolver zuverlässig funktioniert. Erneuern Sie nach einer DHCP-Änderung die Lease oder verbinden Sie sich erneut und prüfen Sie die Einstellungen, die der Client tatsächlich erhalten hat.

Füge Sperrlisten so hinzu, dass du Fehler beheben kannst
Anschließend importiert der Ersteller weitere Sperrlisten und zeigt, wie die Gesamtzahl blockierter Domains steigt. Diese Zahl beschreibt die Richtliniendatenbank, nicht die Qualität des Surferlebnisses. Eine größere Liste kann zwar mehr unerwünschte Domains umfassen, aber auch Anmeldevorgänge, Mediaplayer oder andere Funktionen stören, die auf einen gemeinsam genutzten Dienst angewiesen sind.
Füge jeweils eine gepflegte Liste hinzu, aktualisiere die Filterdatenbank und teste anschließend die Dienste, die du tatsächlich verwendest. Wenn etwas nicht funktioniert, ermittle anhand des Abfrageprotokolls den betroffenen Namen und teste einen eng gefassten Zulassungslisteneintrag. In der Dokumentation zur Domain-Datenbank von Pi-hole wird erklärt, wie Zulassungs- und Sperreinträge zusammenwirken. Versuche nicht, eine einzelne fehlerhafte Anmeldung zu beheben, indem du eine nicht zugehörige Domain-Sammlung pauschal zulässt.

| Beobachtung | Was es aussagt | Nächste sinnvolle Prüfung |
|---|---|---|
| Eine passende blockierte Abfrage wird angezeigt. | Die Abfrage erreichte Pi-hole und wurde von der Richtlinie erfasst. | Prüfe, ob die sichtbare Seite denselben Hostnamen verwendet hat. |
| Auf der Seite wird weiterhin Werbung angezeigt. | Das visuelle Ergebnis weicht vom ausgewählten DNS-Test ab. | Suche nach einem anderen Hostnamen, einer zwischengespeicherten Antwort oder Inhalten vom selben Host. |
| Eine Anmeldung oder ein Player funktioniert nicht mehr. | Möglicherweise wurde eine Abhängigkeit blockiert. | Prüfe die letzten Abfragen des Clients und teste eine eng gefasste Ausnahme. |
| Es wird keine neue Abfrage angezeigt. | Es gibt noch keinen passenden aktuellen Protokolleintrag. | Prüfe den Resolver-Pfad, den Client-Cache und die Datenschutzeinstellungen des Protokolls. |
Halte den Grund für eine neue Liste oder Ausnahme zusammen mit der Änderung fest. Eine sinnvolle Richtlinie sollte eine Woche normalen Betriebs überstehen und nicht nur einen einzigen erfolgreichen Screenshot liefern. Wenn du den Filter für andere pflegst, gib ihnen eine Möglichkeit, einen nicht funktionierenden Dienst und den ungefähren Zeitpunkt des Ausfalls zu beschreiben. Das ist hilfreicher als eine allgemeine Meldung wie „Das Internet ist ausgefallen.“
Mit Tailscale denselben Filter auch unterwegs nutzen
In der zweiten Hälfte werden Tailscale auf dem Server und einem Smartphone eingerichtet. In den DNS-Einstellungen des Tailnets trägt The Social Dork die Tailscale-Adresse des Servers als Nameserver ein, verbindet dann das Smartphone und prüft erneut die Pi-hole-Aktivität. Der DNS-Endpunkt bleibt zu Hause, während das autorisierte Smartphone ihn über das private Netzwerk erreichen kann.

Tailscale’s official Pi-hole integration walkthrough provides the current setup details. Confirm that Pi-hole accepts queries arriving over the intended private interface and that tailnet access policy permits DNS traffic. Where you want supported clients to prefer the configured tailnet nameserver, review Tailscale’s DNS override behavior and verify the setting on the actual client.
Wenn du über Tailscale einen DNS-Resolver zu Hause verwendest, wird dadurch nicht automatisch der gesamte Webdatenverkehr über den Anschluss zu Hause geleitet. Der gesamte Internetverkehr über einen Exit-Node zu Hause ist eine separate Konfiguration. Bei diesem Projekt ist nur eine private Route zum DNS-Dienst erforderlich; ein öffentlicher DNS-Resolver oder seine Verwaltungsseite muss nicht dem Internet ausgesetzt werden.
Validiere den privaten DNS-Pfad schrittweise
- Vergewissere dich, dass Server und Smartphone im vorgesehenen Tailnet angemeldet sind und einander erreichen können.
- Füge den erreichbaren Pi-hole-Endpunkt als vorgesehenen Tailnet-Nameserver hinzu.
- Prüfe, ob der Client Tailscale DNS verwendet und wie die Einstellung zum Überschreiben des Nameservers das gewünschte Verhalten beeinflusst.
- Prüfe, ob der Pi-hole-Listener und die Zugriffsrichtlinie DNS-Anfragen über diesen privaten Pfad zulassen.
- Trenne die WLAN-Verbindung zu Hause und wiederhole auf dem Smartphone eine erlaubte und eine blockierte Abfrage.
Ein Listener, der so konfiguriert ist, dass er nur ein bestimmtes lokales Netzwerk akzeptiert, kann erklären, warum Clients zu Hause funktionieren, ein Tailscale-Client jedoch nicht. Pi-holes Referenz zur Konfiguration des DNS-Listeners beschreibt die verfügbaren Modi. Wähle einen Modus, der mit deinem Container und privaten Netzwerk kompatibel ist, und beschränke den eingehenden Zugriff weiterhin auf die vorgesehenen Clients. Weit gefasste Listener-Einstellungen erfordern eine ebenso klare Firewall-Begrenzung.

Unterscheide außerdem DNS-Einstellungen vom Internetzugang. Ein Nameserver kann Abfragen filtern, ohne als Exit-Node zu fungieren. Wenn du zusätzlich einen Exit-Node aktivierst, prüfe dessen DNS-Verhalten erneut. Tailscale dokumentiert dieses Zusammenspiel in der Referenz zu DNS und Nameservern. Ein erfolgreicher Test über das WLAN zu Hause ersetzt keinen Test desselben Smartphones über mobile Daten.
Richte den Abschlusstest auf den Verbindungsweg aus, nicht nur auf einen Zähler
Wiederhole den Test über eine andere Verbindung, zum Beispiel über mobile Daten bei ausgeschaltetem WLAN. Prüfe, ob eine neue Abfrage vom Smartphone in Pi-hole erscheint, eine erlaubte Website weiterhin geöffnet wird und der ausgewählte blockierte Name eine Filterantwort erhält. Eine steigende Gesamtzahl kann auch Anfragen von anderen Geräten enthalten. Nutze den betreffenden Client und die Zeitstempel, um die Beobachtung deinem Test zuzuordnen.
Der nächste Schritt in der Serie dieses Creators ist eine OPNsense-Firewall mit Pi-hole-DNS für WLAN-Clients. Ein umfassenderes Beispiel für die Organisation von Anwendungen und Fernzugriff zeigt Kabutos modularer Homelab-Aufbau und wie diese Dienste in eine gepflegte physische Umgebung integriert werden können. Beginne mit einem funktionierenden Client und erweitere dann die Filterrichtlinie, sobald die lokalen und externen Verbindungen überprüft sind. Kehre zur ursprünglichen Schrittfolge zurück: die Pi-hole- und Tailscale-Demonstration von The Social Dork.
Die erste fehlerhafte Ebene überprüfen
| Symptom | Zuerst prüfen | Zu sammelnde Nachweise |
|---|---|---|
| Funktioniert lokal, schlägt aber über mobile Daten fehl. | Tailnet-Verbindung, Listener und DNS-Zugriffsrichtlinie. | Erreichbarkeit des Servers und eine neue Abfrage vom Smartphone. |
| Abfragen werden protokolliert, aber eine Website lädt nicht. | Das Richtlinienergebnis und die Auflösung durch den Upstream-Server. | Eine erlaubte Abfrage, mögliche blockierte Abhängigkeiten und die Antwort. |
| Die Filterung fällt nach einer Lease-Erneuerung aus. | Per DHCP bereitgestellte Resolver und IPv6-Einstellungen. | Das erneuerte Gateway und die DNS-Konfiguration des Clients. |
| Einstellungen verschwinden nach einem App-Update. | Der persistente Speicher und der tatsächlich verwendete Ersatzcontainer. | Die Volume-Zuordnung und gespeicherte Konfiguration der App. |
| Das Surfen funktioniert nach einem Neustart des Hosts nicht mehr. | DNS-Abhängigkeit und Dienststart. | Ob der Resolver antwortet und Clients ihn abfragen können. |
Sobald andere Geräte den Dienst nutzen, sollten Sie ihn als wichtige Abhängigkeit des Haushalts behandeln. Sichern Sie die Konfiguration, bewahren Sie einen funktionierenden Satz Richtlinienquellen auf und testen Sie ein Update zuerst mit einem Client. Überprüfen Sie nach einem Neustart des Hosts erneut eine zulässige und eine blockierte Abfrage. Dass das App-Symbol wieder im Dashboard erscheint, ist erst der Anfang dieser Überprüfung.
Die Dokumentation zur Containerkonfiguration von Pi-hole erläutert Optionen für Persistenz und Netzwerke. Bewahren Sie diese Dokumentation zusammen mit Ihrer gewählten Konfiguration auf, statt sich auf einen Screenshot mit der Adresse einer anderen Person zu verlassen.
FAQ
Entfernt Pi-hole jede YouTube-Werbung?
Die DNS-Filterung kann gewünschte Videos und Werbung nicht zuverlässig voneinander trennen, wenn sie denselben Hostnamen verwenden. Betrachten Sie dieses Projekt als Filterung auf Domainebene und überprüfen Sie die von Ihnen verwendeten Anwendungen, statt ein werbefreies Ergebnis überall zu versprechen.
Benötigt jedes Gerät im Haushalt Tailscale?
Heimgeräte können über ihre DNS-Einstellungen einen erreichbaren Pi-hole-Endpunkt im lokalen Netzwerk verwenden. Bei diesem Projekt stellt Tailscale die private Verbindung für Geräte bereit, die auch unterwegs denselben Resolver nutzen müssen.
Brauche ich für diese Einrichtung einen Tailscale-Exit-Node?
Nicht nur, um den privaten DNS-Dienst zu erreichen. Ein Exit-Node ändert die Route des Internetverkehrs und ist eine separate Konfiguration mit eigenem DNS-Verhalten.
Warum lässt sich die Pi-hole-Seite öffnen, während DNS nicht funktioniert?
Die Weboberfläche und der DNS-Dienst verwenden unterschiedliche Ports und können unterschiedliche Container-Portzuordnungen oder Zugriffsregeln haben. Testen Sie eine DNS-Abfrage direkt an die vorgesehene Adresse und prüfen Sie den passenden Protokolleintrag.
Warum kann ein anderer DNS-Server den Filter umgehen?
Clients behandeln einen zweiten konfigurierten Nameserver nicht unbedingt als Ausweichlösung, die nur im Notfall verwendet wird. Wenn eine einheitliche Filterung wichtig ist, überprüfen Sie alle bekannt gegebenen Resolver und das tatsächliche Verhalten des Clients.
Was sollte ich vor dem Update der App speichern?
Speichern Sie die funktionierende App-Konfiguration, die Speicherorte der persistenten Daten, die Richtlinienquellen und die Clienteinstellungen für einen erfolgreichen Test. Wiederholen Sie diesen Test nach dem Update und vergewissern Sie sich, dass die Einstellungen erhalten geblieben sind.
Fazit
Das Projekt von The Social Dork verbindet drei Entscheidungen: wo DNS läuft, welche Clients es nutzen und wie ein autorisiertes Smartphone von einem anderen Netzwerk aus darauf zugreift. Bei einer guten Bereitstellung sind diese Entscheidungen nachvollziehbar und überprüfbar. Die überzeugendsten Belege sind eine passende Client-Abfrage, die erwartete Richtlinienreaktion und normales Surfen, das weiterhin funktioniert.
Beginnen Sie mit einem Client, erweitern Sie die Konfiguration nach einem erfolgreichen lokalen Test auf DHCP und überprüfen Sie Tailscale über eine tatsächlich separate Verbindung. Betreiben Sie den Filter anschließend als Dienst, auf den sich der Haushalt verlässt. Halten Sie das ursprüngliche Pi-hole- und Tailscale-Video für die Abfolge des Erstellers neben der aktuellen offiziellen Dokumentation der installierten Versionen verfügbar.
Zima-Kampagnenzentrale
Mehr zum Lesen

ZimaSpace Black-Friday-Kaufratgeber 2026: Angebote, Cluster und Geschenke
Vergleiche die Black-Friday-Angebote für ZimaBoard 2, SE und ZimaCube 2, Cluster mit drei Boards und Produktgeschenke. Erfahre, wie du zeitlich begrenzte Warenkorbgeschenke einlösen und...

Wie The Social Dork eine OPNsense-Firewall für zu Hause baut
Entdecke den OPNsense-Firewall-Aufbau von The Social Dork auf dem ZimaBoard 2, einschließlich virtueller Schnittstellen, WLAN-Zugangspunkten, DHCP und Pi-hole-DNS-Filterung.

Ich habe KI gekauft, um Zeit zu sparen. Dann begann ich, ihre Grenzen zu umgehen.
Ich begann, meine Abende nach KI-Credits und Codex-Resets zu planen. Als ich einige alltägliche Aufgaben auf lokale KI verlagerte, konnte ich meinen Arbeitstag anders...



