Jak The Social Dork tworzy bloker reklam Pi-hole z ZimaBoard 2

Dziękujemy The Social Dork | Cyber Security za udostępnienie projektu z Pi-hole i Tailscale, który filtruje zapytania DNS w domu i na telefonie poza domem. ZimaBoard 2 uruchamia usługi, Pi-hole sprawdza żądane domeny, a Tailscale zapewnia prywatne połączenie z serwerem. Obejrzyj oryginalny poradnik w serwisie YouTube, aby zobaczyć pełną demonstrację.

Obejrzyj przed lekturą: Ten ośmiominutowy film przyda się, jeśli chcesz zrozumieć, jak filtrowanie reklam na poziomie sieci wpisuje się w całość, zanim zmienisz ustawienia DNS w domu. Twórca instaluje Pi-hole w ZimaOS, testuje klienta Windows, dodaje listy blokowania, a następnie łączy telefon przez Tailscale.

Rezultatem jest wielokrotnego użytku usługa filtrowania DNS. Twórca pokazuje mniej widocznych reklam na przykładowej witrynie oraz aktywność zapytań na zdalnym telefonie. Te obserwacje pokazują, że w tej konfiguracji filtrowanie działa; nie dowodzą, że każda reklama, moduł śledzący czy złośliwe połączenie zostanie zablokowane.

Dowiedz się, co filtruje Pi-hole, zanim wybierzesz sprzęt

Wyjaśnienie zaczyna się od witryny, która ładuje treści z kilku domen. Pi-hole odbiera zapytania DNS klienta i sprawdza żądane nazwy zgodnie ze skonfigurowanymi zasadami. Dozwolone nazwy mogą być rozwiązywane przez nadrzędny resolver; zablokowane otrzymują odpowiedź blokującą. Kluczowym punktem kontroli jest zapytanie DNS — zanim klient spróbuje pobrać treści z danej domeny.

Ten zakres wyznacza też ograniczenia. Filtr DNS nie potrafi odróżnić reklamy od pożądanej treści, jeśli obie korzystają z tej samej nazwy hosta. Klienci korzystający z innego resolvera mogą ominąć wybraną ścieżkę. Tytuł filmu „blokowanie wszystkich reklam” potraktuj jako motywację do realizacji projektu, a nie gwarancję uniwersalnego rezultatu. Filtrowanie treści w przeglądarce i filtrowanie DNS działają na różnych warstwach i mogą się uzupełniać.

Prześledź jedno zapytanie od początku do końca, zanim zmienisz ustawienia całej sieci. Klient pyta o nazwę hosta; Pi-hole stosuje swoje zasady; dozwolone zapytanie może trafić do nadrzędnego resolvera; odpowiedź wraca do klienta. Późniejsze połączenie z witryną to osobny przepływ. Dlatego licznik zablokowanych domen jest przydatnym dowodem aktywności DNS, ale nie mierzy każdego połączenia nawiązywanego przez aplikację.

Zapewnij usłudze DNS stabilne miejsce w sieci domowej

The Social Dork używa urządzenia ZimaBoard 2 i instaluje Pi-hole ze sklepu z aplikacjami ZimaOS pokazanego w filmie. Twórca wspomina też o istniejącym laptopie jako alternatywnym hoście. W praktyce potrzebne jest urządzenie, które może być dostępne zawsze, gdy klienci polegają na nim jako serwerze DNS; demonstracja nie uzasadnia zakupu wariantu z największą ilością pamięci wyłącznie do filtrowania.

Podłącz hosta, przypisz punktowi końcowemu DNS stabilny adres lub rezerwację DHCP i sprawdź, czy jest dostępny z urządzenia testowego. Sieć kontenera i mapowanie portów wpływają na to, jakiego adresu powinny używać urządzenia klienckie. Sprawdź, czy Twoja instalacja rzeczywiście odpowiada na zapytania DNS pod tym adresem, zamiast zakładać, że dostępna strona panelu administracyjnego oznacza gotowość usługi DNS.

Zapisz adresy przed zmianą ustawień urządzenia

W przypadku instalacji kontenerowej sprawdź dostępność usługi DNS zarówno przez TCP, jak i UDP. Oficjalny przykład Dockera Pi-hole udostępnia oba protokoły na porcie 53 i zachowuje katalog konfiguracji. Te szczegóły mają znaczenie nawet wtedy, gdy sklep z aplikacjami ukrywa konfigurację kontenera za przyciskiem „Zainstaluj”. Przed zmianą usługi hosta, która może już korzystać z tego samego portu, sprawdź rzeczywistą konfigurację aplikacji.

Film pokazuje instalację z poziomu sklepu z aplikacjami ZimaOS twórcy. Twoja wersja aplikacji i tryb sieciowy mogą być inne. Zachowaj ustawienia określające, w jaki sposób aplikacja łączy się z siecią: jej adres, opublikowane porty, lokalizację danych, resolver nadrzędny i sposób ponownego uruchamiania. Taka krótka notatka ułatwi późniejszą weryfikację migracji lub ponownej instalacji.

Przetestuj jedno urządzenie przed zmianą DNS dla całego domu

W poradniku laptop z systemem Windows pozostaje połączony z domową siecią Wi-Fi, gdy ustawienie DNS IPv4 zostaje zmienione na adres Pi-hole. Następnie autor sprawdza aktywność zapytań. To prosty pierwszy test: jeśli przeglądanie stron przestanie działać, wystarczy przywrócić ustawienia tylko na tym kliencie, a reszta domowników może nadal korzystać z dotychczasowej konfiguracji.

Aby objąć filtrowaniem więcej urządzeń, instrukcja konfiguracji Pi-hole po instalacji wyjaśnia, jak DHCP może przekazywać klientom adres DNS Pi-hole. Odnów dzierżawę klienta lub połącz się ponownie, a następnie sprawdź, z którego resolvera faktycznie korzysta. Sprawdź też ustawienia DNS IPv6 oraz szyfrowanego DNS w przeglądarce lub systemie operacyjnym; zmiana jednego pola IPv4 nie gwarantuje, że każde zapytanie będzie korzystać z tego serwera.

Drugi, niefiltrowany resolver również może zakłócić oczekiwany rezultat. Klienci mogą korzystać z innego skonfigurowanego resolvera zamiast traktować go wyłącznie jako awaryjny. Zdecyduj, czy priorytetem jest ciągłość działania, czy spójne filtrowanie, i przetestuj zachowanie systemu, gdy host Pi-hole jest niedostępny. Zachowaj zapis pierwotnych ustawień, aby łatwo cofnąć eksperyment z DNS.

Przeprowadź powtarzalny test lokalny

1. Zapisz bieżącą konfigurację DNS laptopa oraz adres Pi-hole, którego zamierzasz użyć.
2. Wyślij do Pi-hole jawne zapytanie o dozwoloną domenę, a następnie znajdź odpowiadający mu wpis w logu.
3. Przetestuj domenę znajdującą się na aktywnej liście blokowanych adresów i sprawdź, czy została zablokowana.
4. Ustaw Pi-hole jako preferowany serwer DNS klienta i powtórz test, nie wybierając jawnie resolvera.
5. Zanim wprowadzisz zmianę przez DHCP, odwiedź kilka zwykłych usług, w tym stronę logowania.

Na przykład nslookup example.com PIHOLE_LAN_IP testuje wskazany resolver; zastąp PIHOLE_LAN_IP adresem swojego serwera. To jawne zapytanie sprawdza sam punkt końcowy. Następnie nslookup example.com sprawdza standardową ścieżkę resolvera systemowego. Żaden z tych testów sam w sobie nie potwierdza, że przeglądarka z własnymi ustawieniami DNS korzysta z tej samej ścieżki, więc sprawdź też nowe zapytanie z tej aplikacji.

Szukając przyczyny awarii, sprawdź osobno dostępność adresu i rozwiązywanie nazw. Urządzenie może nadal być połączone z Wi-Fi, a mimo to nie otwierać stron, jeśli jego serwer DNS jest niedostępny. Zachowaj pierwotne ustawienia klienta, dopóki nowy resolver nie będzie działać niezawodnie. Po zmianie DHCP odnów dzierżawę lub połącz się ponownie i sprawdź ustawienia faktycznie otrzymane przez klienta.

Dodawaj listy blokowania tak, by dało się diagnozować problemy

Następnie twórca importuje dodatkowe listy blokowania i pokazuje, jak rośnie łączna liczba zablokowanych domen. Ta liczba opisuje bazę zasad, a nie jakość korzystania z internetu. Większa lista może obejmować więcej niepożądanych domen, ale może też zakłócać logowanie, odtwarzacze multimedialne lub inne funkcje zależne od współdzielonej usługi.

Dodawaj po jednej aktualizowanej liście, odświeżaj bazę filtrowania i ponownie testuj usługi, z których faktycznie korzystasz. Gdy coś przestanie działać, użyj dziennika zapytań, aby ustalić, której nazwy dotyczy problem, a następnie przetestuj wąski wpis na liście dozwolonych. W dokumentacji bazy domen Pi-hole wyjaśniono, jak współdziałają wpisy zezwalające i blokujące. Nie rozwiązuj problemu z pojedynczym niedziałającym logowaniem, zezwalając szeroko na niepowiązany zestaw domen.

Zachowaj uzasadnienie dodania nowej listy lub wyjątku wraz ze zmianą. Rozsądna polityka powinna sprawdzać się przez tydzień zwykłego użytkowania, a nie tylko na jednym udanym zrzucie ekranu. Jeśli zarządzasz filtrem dla innych osób, zapewnij im sposób opisania niedziałającej usługi i przybliżonego czasu awarii. To bardziej użyteczne niż ogólne zgłoszenie, że „internet nie działa”.

Używaj Tailscale, aby korzystać z tego samego filtra poza domem

W drugiej części autor dodaje Tailscale do serwera i telefonu. W ustawieniach DNS tailnetu The Social Dork wpisuje adres Tailscale serwera jako serwer nazw, a następnie łączy telefon i ponownie sprawdza aktywność Pi-hole. Punkt końcowy DNS pozostaje w domu, a uprawniony telefon może łączyć się z nim przez sieć prywatną.

Oficjalna instrukcja integracji z Pi-hole od Tailscale zawiera aktualne szczegóły konfiguracji. Upewnij się, że Pi-hole akceptuje zapytania przychodzące przez zamierzony interfejs prywatny, a zasady dostępu tailnetu zezwalają na ruch DNS. Jeśli chcesz, aby obsługiwane klienty preferowały skonfigurowany serwer nazw tailnetu, zapoznaj się z informacjami o sposobie działania zastępowania DNS w Tailscale i sprawdź to ustawienie na używanym kliencie.

Korzystanie z domowego resolvera DNS przez Tailscale nie powoduje automatycznie, że cały ruch internetowy przechodzi przez domowe łącze. Pełna łączność z internetem przez domowy węzeł wyjściowy wymaga osobnej konfiguracji. Ten projekt wymaga jedynie prywatnej trasy do usługi DNS; nie wymaga udostępniania publicznego resolvera DNS ani jego strony administracyjnej w internecie.

Sprawdź prywatną ścieżkę DNS etapami

1. Upewnij się, że serwer i telefon są przypisane do właściwego tailnetu i mogą się wzajemnie osiągać.
2. Dodaj osiągalny punkt końcowy Pi-hole jako zamierzony serwer nazw tailnetu.
3. Sprawdź, czy klient korzysta z DNS Tailscale oraz jak zachowuje się przy włączonym ustawieniu zastępowania serwerów nazw.
4. Sprawdź, czy nasłuchiwanie Pi-hole i zasady dostępu akceptują zapytania DNS z tej prywatnej ścieżki.
5. Wyłącz domowe Wi-Fi i ponownie sprawdź w telefonie zapytanie, które powinno być dozwolone, oraz takie, które powinno być zablokowane.

Nasłuchiwanie skonfigurowane tak, by akceptować połączenia tylko z określonej sieci lokalnej, może wyjaśniać, dlaczego urządzenia w domu działają, a klient Tailscale nie. Dokumentacja konfiguracji nasłuchiwania DNS Pi-hole opisuje dostępne tryby. Wybierz tryb zgodny z kontenerem i siecią prywatną, ograniczając jednocześnie dostęp przychodzący do zamierzonych klientów. Szerokie ustawienia nasłuchiwania wymagają równie jasno określonych reguł zapory.

Rozróżnij też ustawienia DNS od wyjścia do internetu. Serwer nazw może filtrować zapytania bez pełnienia funkcji węzła wyjściowego. Jeśli osobno włączysz węzeł wyjściowy, ponownie sprawdź działanie DNS; Tailscale opisuje tę zależność w dokumentacji DNS i serwerów nazw. Pomyślny test w domowej sieci Wi-Fi nie zastępuje sprawdzenia tego samego telefonu przez sieć komórkową.

Końcowy test powinien sprawdzać ścieżkę, a nie tylko licznik

Powtórz test z innego połączenia, na przykład przez sieć komórkową przy wyłączonym Wi-Fi. Sprawdź, czy nowe zapytanie z telefonu pojawia się w Pi-hole, czy dozwolona strona nadal się otwiera i czy dla wybranej blokowanej nazwy otrzymujesz odpowiedź wskazującą na filtrowanie. Sam wzrost łącznej liczby zapytań może obejmować żądania z innych urządzeń; dopasuj klienta i znaczniki czasu do swojego testu.

Kolejnym krokiem w serii tego twórcy jest zapora OPNsense z DNS-em Pi-hole dla klientów sieci bezprzewodowej. Szerszy przykład organizacji aplikacji i dostępu zdalnego przedstawia modułowa konfiguracja homelabu autorstwa kabuto, pokazując, jak te usługi mogą działać w utrzymywanej konfiguracji fizycznej. Zacznij od jednego działającego klienta, a następnie rozszerz zasady filtrowania po zweryfikowaniu połączeń lokalnych i zdalnych. Wróć do demonstracji Pi-hole i Tailscale autorstwa The Social Dork, aby zobaczyć pierwotną kolejność działań.

Rozwiąż problem, zaczynając od pierwszej niedziałającej warstwy

Gdy z usługi zaczynają korzystać inne urządzenia, traktuj ją jako element domowej infrastruktury, od którego zależą domownicy. Utwórz kopię zapasową konfiguracji, zachowaj sprawdzony zestaw źródeł reguł i najpierw przetestuj aktualizację na jednym kliencie. Po ponownym uruchomieniu hosta ponownie sprawdź dozwolone i zablokowane zapytanie. Powrót ikony aplikacji do pulpitu to dopiero początek weryfikacji.

Dokumentacja konfiguracji kontenerów Pi-hole wyjaśnia opcje trwałości danych i sieci. Przechowuj ten opis operacyjny razem z wybraną przez siebie konfiguracją, zamiast polegać na zrzucie ekranu z cudzym adresem.

FAQ

Czy Pi-hole usunie wszystkie reklamy na YouTube?

Filtrowanie DNS nie pozwala niezawodnie oddzielić pożądanych filmów od reklam, gdy korzystają z tej samej nazwy hosta. Traktuj ten projekt jako filtrowanie domen i sprawdź działanie konkretnych używanych aplikacji, zamiast obiecywać brak reklam wszędzie.

Czy każde urządzenie w domu potrzebuje Tailscale?

Urządzenia domowe mogą korzystać z osiągalnego punktu końcowego Pi-hole w sieci LAN, skonfigurowanego w ich ustawieniach DNS. W tym projekcie Tailscale zapewnia prywatne połączenie urządzeniom, które poza domem mają korzystać z tego samego resolvera.

Czy w tej konfiguracji potrzebuję węzła wyjściowego Tailscale?

Nie tylko po to, by uzyskać dostęp do prywatnej usługi DNS. Węzeł wyjściowy zmienia trasę ruchu internetowego i jest osobną konfiguracją z własnym sposobem obsługi DNS.

Dlaczego strona Pi-hole się otwiera, ale DNS nie działa?

Interfejs WWW i usługa DNS korzystają z różnych portów, a ich mapowania kontenerów i reguły dostępu mogą się różnić. Wyślij zapytanie DNS bezpośrednio na wybrany adres i sprawdź odpowiadający mu wpis w dzienniku.

Dlaczego inny serwer DNS może ominąć filtr?

Klienci niekoniecznie traktują drugi skonfigurowany serwer nazw jako zapasowy, używany tylko w nagłych wypadkach. Jeśli zależy Ci na spójnym filtrowaniu, sprawdź wszystkie reklamowane resolvery i rzeczywiste zachowanie klienta.

Co zapisać przed aktualizacją aplikacji?

Zapisz działającą konfigurację aplikacji, lokalizacje trwałych danych, źródła reguł oraz ustawienia klienta użyte w pomyślnym teście. Po aktualizacji powtórz test i sprawdź, czy ustawienia zostały zachowane.

Podsumowanie

Projekt The Social Dorka łączy trzy decyzje: gdzie działa DNS, które klienty z niego korzystają i jak autoryzowany telefon łączy się z nim z innej sieci. Dobrze wdrożone rozwiązanie sprawia, że te decyzje są widoczne i można je przetestować. Najlepszym potwierdzeniem są zgodne wyniki zapytań klienta, oczekiwana odpowiedź zgodna z polityką oraz sprawne zwykłe przeglądanie internetu.

Zacznij od jednego klienta, a po pomyślnym teście lokalnym rozszerz konfigurację na DHCP. Następnie sprawdź działanie Tailscale z rzeczywiście osobnego połączenia. Potem utrzymuj filtr jako usługę, na której polega domowa sieć. Zachowaj oryginalny film o Pi-hole i Tailscale, aby śledzić kolejność kroków twórcy, oraz aktualną oficjalną dokumentację dotyczącą zainstalowanych wersji.