Så bygger The Social Dork en Pi-hole-annonsblockerare med ZimaBoard 2

Eva Wong är teknisk skribent och händig hemmabyggare på ZimaSpace. Som tekniknörd sedan barnsben med ett brinnande intresse för hemlabb och programvara med öppen källkodspecialiserar hon sig på att göra komplexa tekniska koncept begripliga genom praktiska, praktiska guider. Eva tycker att självhosting ska vara roligt, inte avskräckande. Genom sina handledningar hjälper hon communityn att göra hårdvaruinstallationer mindre mystiska, från att bygga sin första NAS till att bemästra Docker-containrar.

Tack till The Social Dork | Cybersäkerhet för att ha delat ett Pi-hole- och Tailscale-projekt som filtrerar DNS-förfrågningar hemma och när du använder telefonen utanför hemmet. ZimaBoard 2 kör tjänsterna, Pi-hole kontrollerar efterfrågade domäner och Tailscale tillhandahåller en privat anslutning tillbaka till servern. Se den ursprungliga genomgången på YouTube för hela demonstrationen.

Titta innan du läser: Den här åtta minuter långa videon är användbar om du vill förstå var nätverksbaserad annonsfiltrering passar in innan du ändrar hushållets DNS-inställningar. Skaparen installerar Pi-hole i ZimaOS, testar en Windows-klient, lägger till blocklistor och ansluter sedan en telefon via Tailscale.

Resultatet är en DNS-filtreringstjänst som kan återanvändas. Skaparen visar färre synliga annonser på en exempelwebbplats och förfrågningsaktivitet från fjärrtelefonen. Observationerna visar att filtreringsvägen fungerar i den konfigurationen; de fastställer inte att alla annonser, spårare eller skadliga anslutningar kommer att blockeras.

Förstå vad Pi-hole filtrerar innan du väljer hårdvara

Förklaringen börjar med en webbplats som laddar innehåll från flera domäner. Pi-hole tar emot klientens DNS-förfrågningar och kontrollerar de efterfrågade namnen mot den konfigurerade policyn. Tillåtna namn kan slås upp via en uppströmsresolver; blockerade namn får ett blockeringssvar. Den viktiga kontrollpunkten är DNS-förfrågan, innan klienten försöker hämta innehåll från domänen.

Den här omfattningen sätter också gränsen. Ett DNS-filter kan inte skilja en annons från önskat innehåll när båda använder samma värdnamn. Klienter som använder en annan resolver kan kringgå den valda vägen. Se videons titel ”Blockera alla annonser” som projektets motivation, inte som ett universellt resultat. Innehållsfiltrering i webbläsaren och DNS-filtrering fungerar på olika lager och kan komplettera varandra.

Komponent Vad den gör i det här projektet Det du fortfarande behöver kontrollera
Pi-hole Tillämpa domänpolicy på DNS-förfrågningar som når den. Den resolver som varje klient faktiskt använder.
Uppströmsresolver Besvarar tillåtna förfrågningar som Pi-hole inte kan besvara lokalt. Nåbarhet och vidarebefordringsvägen.
Tailscale Tillhandahåller privat anslutning mellan registrerade enheter. Namnserverns nåbarhet och klientens DNS-inställningar.
Webbläsare eller app Begär innehåll efter att destinationen har slagits upp. Eventuell oberoende konfiguration av krypterad DNS eller cachat svar.

Följ en DNS-förfrågan genom systemet innan du ändrar ett helt nätverk. En klient frågar efter ett värdnamn; Pi-hole tillämpar sin policy; en tillåten förfrågan kan nå den uppströmsliggande resolveraren; svaret skickas tillbaka till klienten. Den efterföljande webbanslutningen är ett separat flöde. Därför är räknaren för blockerade domäner ett användbart tecken på DNS-aktivitet, men den mäter inte alla anslutningar som ett program gör.

Ge DNS-tjänsten en stabil plats i hemnätverket

The Social Dork använder ZimaBoard 2 och installerar Pi-hole via appbutiken i ZimaOS som visas i videon. Skaparen nämner också en befintlig bärbar dator som alternativ värd. Det praktiska kravet är en maskin som kan vara tillgänglig när klienterna behöver den för DNS; demonstrationen visar inte att det finns någon anledning att köpa det största minnesalternativet enbart för filtrering.

Anslut värden, ge DNS-slutpunkten en stabil adress eller DHCP-reservation och bekräfta att tjänsten går att nå från en testklient. Containernätverk och portmappningar påverkar vilken adress klienterna ska använda. Kontrollera att installationen faktiskt besvarar DNS-frågor på den slutpunkten i stället för att anta att en åtkomlig administrationssida betyder att DNS-tjänsten är redo.

Anslutning av Ethernet-kablar till ZimaBoard 2 som används för Pi-hole
Skaparen ansluter ZimaBoard 2 till hemnätverket innan DNS konfigureras. Servern måste ha en stabil adress som går att nå innan klientinställningarna ändras. Videobild vid ungefär 3:25, med tillstånd av The Social Dork.

Anteckna adresserna innan du ändrar en klient

Adress eller inställning Används för Vanlig förväxling
Pi-holes LAN-slutpunkt DNS från enheter i hemnätverket. En intern Docker-adress kanske inte går att nå från den bärbara datorn.
Serverns Tailscale-adress Privat DNS-åtkomst från anslutna fjärrenheter. LAN-adressen och Tailscale-adressen är olika slutpunkter.
DNS-adress uppströms Tillåtna frågor som vidarebefordras av Pi-hole. Om du pekar tillbaka den mot en resolver som vidarebefordrar till Pi-hole skapas en loop.
Administrationsadress Visa policy och frågeaktivitet. Att en webbsida laddas bevisar inte att det går att nå DNS-port 53.

Kontrollera att DNS-tjänsten är nåbar via både TCP och UDP vid en containerinstallation. Pi-holes officiella Docker-exempel exponerar båda protokollen på port 53 och sparar konfigurationskatalogen mellan omstarter. De detaljerna spelar roll även när en appbutik döljer containerkonfigurationen bakom en Installera-knapp. Läs den faktiska appkonfigurationen innan du ändrar en värdtjänst som kanske redan använder samma port.

Videon visar installation från skaparens appbutik i ZimaOS. Din nuvarande appversion och nätverksläge kan skilja sig. Spara inställningarna som visar hur appen ansluter till nätverket: dess adress, publicerade portar, lagringsplats, uppströms DNS-resolver och omstartsbeteende. Den här korta dokumentationen gör det enklare att verifiera en senare migrering eller ominstallation.

Testa en klient innan du ändrar DNS för hushållet

I genomgången är en Windows-bärbar dator ansluten till hemmets Wi-Fi medan IPv4-DNS-inställningen ändras till Pi-hole-adressen. Skaparen kontrollerar sedan frågeaktiviteten. Det här är ett hanterbart första test: om surfandet slutar fungera behöver bara den klienten återställas, medan resten av hushållet behåller sin befintliga konfiguration.

Inställningar för Windows-nätverkskort under konfigureringen av Pi-hole-klienten
Installationen av Windows-klienten börjar med inställningarna för nätverkskortet. Kontrollera vilken resolver din egen klient faktiskt har fått eller valt. Videobild runt 4:10, med tillstånd av The Social Dork.

För bredare täckning förklarar Pi-holes guide efter installationen hur DHCP kan annonsera Pi-holes DNS-adress till klienter. Förnya klientens lease eller anslut igen och kontrollera sedan vilken resolver den faktiskt använder. Granska även IPv6-DNS och eventuella krypterade DNS-inställningar i webbläsaren eller operativsystemet; att ändra ett IPv4-fält bevisar inte att alla DNS-förfrågningar går via det.

En andra, oblockerad resolver kan också motverka det förväntade resultatet. Klienter kan använda en annan konfigurerad resolver i stället för att strikt hålla den som reserv. Bestäm om driftskontinuitet eller konsekvent filtrering är viktigast och testa beteendet när Pi-hole-värden inte är tillgänglig. Spara de ursprungliga inställningarna så att DNS-experimentet enkelt kan återställas.

Använd ett repeterbart lokalt test

  1. Anteckna den bärbara datorns nuvarande DNS-konfiguration och den avsedda Pi-hole-slutpunkten.
  2. Skicka en tillåten DNS-förfrågan direkt till Pi-hole och leta sedan upp motsvarande fråga i loggen.
  3. Testa en domän som finns i din egen aktiva blockeringslista och bekräfta att den blockeras.
  4. Ställ in Pi-hole som klientens vanliga DNS-server och upprepa testet utan att uttryckligen välja en resolver.
  5. Besök några vanliga tjänster, inklusive ett inloggningsflöde, innan du inför ändringen via DHCP.

Till exempel testar nslookup example.com PIHOLE_LAN_IP en angiven resolver; ersätt PIHOLE_LAN_IP med serverns adress. Den uttryckliga frågan kontrollerar själva slutpunkten. Därefter kontrollerar nslookup example.com systemets vanliga resolverväg. Inget av testen bevisar ensamt att en webbläsare med egna DNS-inställningar använder samma väg, så kontrollera även en ny begäran från det programmet.

När du letar efter ett fel ska du skilja mellan nåbarhet till adresser och namnuppslagning. En enhet kan fortfarande vara ansluten till Wi-Fi och ändå inte kunna öppna webbplatser eftersom dess DNS-server är nere. Behåll klientens ursprungliga inställningar tills den nya resolvern fungerar tillförlitligt. Efter en DHCP-ändring förnyar du en lease eller ansluter igen och kontrollerar vilka inställningar klienten faktiskt har fått.

Pi-holes officiella kontrollpanel med frågor, blockerade frågor och klientaktivitet
Exempel på Pi-holes officiella kontrollpanel: antal frågor och klientaktivitet hjälper dig att kontrollera vilka enheter som använder DNS-filtret. Källa: Pi-hole. Klicka på bilden för att visa den i originalstorlek.

Lägg till blockeringslistor så att du kan felsöka dem

Innehållsskaparen importerar sedan fler blockeringslistor och visar hur antalet blockerade domäner ökar. Siffran beskriver policydatabasen, inte kvaliteten på webbläsarupplevelsen. En större lista kan innehålla fler oönskade domäner, men den kan också störa inloggningsflöden, mediaspelare eller andra funktioner som är beroende av en delad tjänst.

Lägg till en underhållen lista i taget, uppdatera filtreringsdatabasen och testa om de tjänster du faktiskt använder fungerar. När något slutar fungera kan du använda frågeloggen för att identifiera det berörda namnet och testa en snävt avgränsad post i tillåtelselistan. Pi-holes dokumentation om domändatabasen förklarar hur poster i tillåtelse- och blockeringslistorna samverkar. Undvik att lösa ett problem med en enstaka inloggning genom att tillåta en bred, orelaterad samling domäner.

Yahoo-sidan som används i innehållsskaparens demonstration av annonsfiltrering med Pi-hole
Innehållsskaparen använder en exempelwebbplats för att jämföra resultatet i webbläsaren efter att filtreringen aktiverats. Jämför det visuella testet med klientens DNS-frågor; en enda sida bevisar inte att annonser blockeras överallt. Videobild runt 5:10, med tillstånd av The Social Dork.
Observation Vad det visar Nästa användbara kontroll
En matchande blockerad fråga visas. Uppslaget nådde Pi-hole och matchades av policyn. Kontrollera om den synliga sidan använde samma värdnamn.
Sidan visar fortfarande en annons. Det visuella resultatet skiljer sig från det valda DNS-testet. Leta efter ett annat värdnamn, ett cachelagrat svar eller innehåll från samma värd.
En inloggning eller spelare slutar fungera. Ett beroende kan ha nekats. Granska klientens senaste frågor och testa ett snävt undantag.
Ingen ny fråga visas. Det finns ännu ingen ny matchande loggpost. Kontrollera resolverkedjan, klientens cache och sekretessinställningarna för loggar.

Spara anledningen till en ny lista eller ett undantag tillsammans med ändringen. En genomtänkt policy bör fungera efter en veckas normal användning, inte bara ge en lyckad skärmbild. Om du underhåller filtret åt andra, ge dem ett sätt att beskriva en tjänst som slutat fungera och ungefär när det hände. Det är mer användbart än en allmän rapport om att ”internet ligger nere”.

Använd Tailscale för att nå samma filter när du inte är hemma

I den andra halvan läggs Tailscale till på servern och en telefon. I tailnets DNS-inställningar anger The Social Dork serverns Tailscale-adress som namnserver, ansluter sedan telefonen och kontrollerar Pi-hole-aktiviteten igen. DNS-slutpunkten finns kvar hemma, medan den behöriga telefonen kan nå den via det privata nätverket.

Tailscale DNS-inställningar som visar avsnittet för globala namnservrar
Tailscales namnserverinställningar ansluter fjärrklienter som är anslutna till tailnet till hemmets DNS-tjänst. Använd den nåbara adressen till din egen Pi-hole-server och verifiera med mobildata. Videobildruta nära 6:40, med tillstånd av The Social Dork.

Tailscales officiella guide för Pi-hole-integrering innehåller aktuell information om konfigurationen. Bekräfta att Pi-hole tar emot frågor via det avsedda privata gränssnittet och att åtkomstpolicyn för tailnet tillåter DNS-trafik. Om du vill att klienter som stöds ska föredra den konfigurerade namnservern för tailnet kan du granska hur Tailscales åsidosättning av DNS fungerar och kontrollera inställningen på den faktiska klienten.

Att använda en hem-DNS-resolver via Tailscale innebär inte automatiskt att all webbtrafik går via hemmets anslutning. Full internettrafik via en exitnod hemma är en separat konfiguration. Det här projektet behöver bara en privat väg till DNS-tjänsten; det kräver inte att en offentlig DNS-resolver eller dess administrationssida exponeras för internet.

Verifiera den privata DNS-vägen steg för steg

  1. Bekräfta att servern och telefonen är anslutna till avsett tailnet och kan nå varandra.
  2. Lägg till den nåbara Pi-hole-slutpunkten som avsedd namnserver för tailnet.
  3. Granska klientens användning av Tailscale DNS och inställningen för åsidosättning av namnserver för att få det beteende du vill ha.
  4. Kontrollera att Pi-hole-lyssnaren och åtkomstpolicyn tillåter DNS från den privata nätverksvägen.
  5. Koppla från hemmets Wi-Fi och gör om ett tillåtet och ett blockerat uppslag från telefonen.

En lyssnare som konfigurerats för att endast ta emot anslutningar från ett visst lokalt nätverk kan förklara varför klienter hemma fungerar medan en Tailscale-klient misslyckas. Pi-holes referens för konfiguration av DNS-lyssnare beskriver de tillgängliga lägena. Välj ett läge som fungerar med din container och ditt privata nätverk, samtidigt som inkommande åtkomst begränsas till de avsedda klienterna. Bredare inställningar för lyssnaren kräver lika tydliga gränser i brandväggen.

Officiell Tailscale-animation som visar konfiguration av en anpassad global namnserver och åsidosättning av DNS
Officiell Tailscale-animation som visar konfiguration av en anpassad namnserver och åsidosättning av DNS. Använd adressen till din egen Pi-hole-värd. Källa: Tailscales dokumentation. Klicka på bilden för att visa den i originalstorlek.

Skilj också DNS-inställningar från internettrafik. En namnserver kan filtrera DNS-uppslagningar utan att bli en utgångsnod. Om du aktiverar en utgångsnod separat bör du kontrollera DNS-beteendet igen. Tailscale beskriver samspelet i sin referens för DNS och namnservrar. Ett lyckat test via hemmets Wi-Fi ersätter inte ett test av samma telefon via mobildata.

Låt det slutliga testet handla om anslutningsvägen, inte bara en räknare

Upprepa testet från en annan anslutning, till exempel via mobildata med Wi-Fi avstängt. Kontrollera att en ny sökning från telefonen visas i Pi-hole, att en tillåten webbplats fortfarande öppnas och att det valda blockerade namnet får ett filtreringssvar. Enbart en ökande totalsumma kan även omfatta förfrågningar från andra enheter. Använd den relevanta klienten och tidsstämplarna för att koppla observationen till ditt test.

Nästa steg i den här kreatörens serie är en OPNsense-brandvägg med Pi-hole-DNS för trådlösa klienter. För ett bredare exempel på hur man organiserar appar och fjärråtkomst visar kabutos modulära homelab-bygge hur de tjänsterna kan ingå i en väl underhållen fysisk installation. Börja med en fungerande klient och utöka sedan filtreringspolicyn när de lokala och fjärranslutna anslutningsvägarna har verifierats. Gå tillbaka till The Social Dorks demonstration av Pi-hole och Tailscale för den ursprungliga ordningsföljden.

Felsök det första lagret som fallerar

Symptom Kontrollera först Samla in bevis
Fungerar lokalt, men inte via mobildata. Tailnet-anslutning, lyssnare och DNS-åtkomstpolicy. Serverns nåbarhet och en ny sökning från telefonen.
Sökningar loggas, men en webbplats laddas inte. Policyresultatet och uppströms DNS-uppslagning. En tillåten sökning, eventuella blockerade beroenden och svaret.
Filtreringen försvinner när lånet förnyas. Resolvers som tillhandahålls via DHCP och IPv6-inställningar. Klientens förnyade gateway- och DNS-konfiguration.
Inställningarna försvinner efter en appuppdatering. Beständig lagring och den faktiska ersättningscontainern. Appens volymmappning och sparade konfiguration.
Det går inte att surfa när värden startas om. DNS-beroenden och tjänstens uppstart. Om resolvern svarar och klienterna kan göra sökningar mot den.

Behandla tjänsten som något hushållet är beroende av när andra enheter väl använder den. Säkerhetskopiera konfigurationen, behåll en fungerande uppsättning policykällor och testa en uppdatering med en enda klient först. Kontrollera återigen en tillåten förfrågan och en blockerad förfrågan efter omstart av värddatorn. Att appikonen visas på instrumentpanelen igen är bara början på verifieringen.

Pi-holes dokumentation om containerkonfiguration förklarar alternativ för beständig lagring och nätverk. Spara den dokumentationen tillsammans med din egen valda konfiguration i stället för att förlita dig på en skärmbild av någon annans adress.

Vanliga frågor

Tar Pi-hole bort all YouTube-reklam?

DNS-filtrering kan inte på ett tillförlitligt sätt skilja mellan önskad video och reklam när de delar värdnamn. Bedöm det här projektet som domänfiltrering och verifiera de specifika appar du använder i stället för att utlova reklamfri användning överallt.

Behöver alla enheter i hushållet Tailscale?

Enheter hemma kan använda en nåbar Pi-hole-adress på det lokala nätverket via sina DNS-inställningar. I det här projektet tillhandahåller Tailscale den privata anslutningen för enheter som behöver använda samma namnserver när de är hemifrån.

Behöver jag en Tailscale-exitnod för den här konfigurationen?

Inte bara för att nå den privata DNS-tjänsten. En exit-nod ändrar internettrafikens väg och är en separat konfiguration med ett eget DNS-beteende.

Varför öppnas Pi-hole-sidan när DNS inte fungerar?

Webbgränssnittet och DNS-tjänsten använder olika portar och kan ha olika portmappningar eller åtkomstregler i containern. Testa en DNS-förfrågan direkt till den avsedda adressen och kontrollera motsvarande loggpost.

Varför kan en annan DNS-server kringgå filtret?

Klienter behandlar inte nödvändigtvis en andra konfigurerad namnserver som en reserv som bara används i nödfall. Om konsekvent filtrering är viktigt bör du verifiera alla annonserade namnservrar och klientens faktiska beteende.

Vad bör jag spara innan jag uppdaterar appen?

Spara appens fungerande konfiguration, platserna för beständiga data, policykällorna och klientinställningarna som användes för ett test som fungerade. Upprepa testet efter uppdateringen och bekräfta att inställningarna finns kvar.

Slutsats

The Social Dorks projekt förenar tre beslut: var DNS körs, vilka klienter som använder det och hur en behörig telefon når det från ett annat nätverk. En användbar driftsättning gör besluten synliga och möjliga att testa. De tydligaste beläggen är en matchande klientförfrågan, det förväntade policyresultatet och att vanlig surfning fortfarande fungerar.

Börja med en klient, utöka till DHCP när det lokala testet har lyckats och verifiera Tailscale via en helt separat anslutning. Underhåll sedan filtret som en tjänst hushållet förlitar sig på. Se till att den ursprungliga Pi-hole- och Tailscale-videon finns kvar för att följa skaparens upplägg, tillsammans med den aktuella officiella dokumentationen för dina installerade versioner.

Zima-kampanjhubben

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.