Homelab #13: lokalny DNS - od Pi-hole do AdGuard Home

Witam, w tej części chciałbym opisać swoje dotychczasowe doświadczenia z lokalnym serwerem DNS, który pozwala na ograniczenie ruchu w całej sieci lokalnej.

Moja historia z homelabem zaczęła się wiele lat temu od Raspberry Pi, na którym była hostowana tylko jedna aplikacja — Pi-hole. Przez długi czas korzystałem z tego serwisu jako z lokalnego DNS. Jednak pewnego dnia postanowiłem coś zmienić. Oto moja historia przejścia z Pi-hole na AdGuard Home.

Pi-hole

Pi-hole to oprogramowanie działające jako lokalny serwer DNS, którego głównym celem jest blokowanie reklam, trackerów i złośliwych domen w całej sieci domowej. Jest to znacznie lepsze rozwiązanie niż AdBlock czy inne podobne rozszerzenia, ponieważ AdBlock blokuje reklamy oraz trackery tylko w zainstalowanej przeglądarce na jednym konkretnym urządzeniu. Lepiej jest uruchomić lokalny DNS.

Największym atutem Pi-hole jest to, że pozwala na blokadę domen na wszystkich urządzeniach w sieci, niezależnie od przeglądarki i systemu operacyjnego.

Jak sama nazwa wskazuje, Pi-hole był pierwotnie projektowany pod Raspberry Pi, ale z czasem projekt wyszedł poza tę platformę. Obecnie można go uruchomić praktycznie na każdej platformie.

Jak działa blokowanie

W dużym uproszczeniu Pi-hole posiada czarne listy (blacklisty), czyli listy domen, które mają zostać zablokowane. Nie trzeba samodzielnie dodawać wszystkich domen do blokady. Istnieje duża społeczność, która tworzy i utrzymuje takie listy. Na przykład polskie listy można znaleźć tutaj.

Blokowanie działa w następujący sposób: gdy urządzenia w sieci wysyłają zapytanie o adres domeny, Pi-hole sprawdza, czy dana domena znajduje się na liście reklam/trackingu. Jeśli tak, zamiast prawdziwego adresu IP zwraca „pusty” adres, dzięki czemu reklama lub tracker nie ładuje się. Jeśli domena nie jest zablokowana, zapytanie przekazywane jest do normalnych serwerów DNS (np. Cloudflare, Google, Quad9).

Dodatkowo istnieje biała lista (whitelist). Pozwala ona na rozwiązanie domen, które znajdują się na czarnej liście, jeśli chcemy je dopuścić.

Przegląd przez lata

Przez wiele lat Pi-hole działał prawie bez zarzutu. Czemu „prawie”? Bo od czasu do czasu pojawiał się problem z jego działaniem. Pierwszy problem, z którym się spotkałem, polegał na tym, że co kilka miesięcy Pi-hole przestawał się uruchamiać. Nie znałem przyczyny, próbowałem naprawiać to różnymi komendami i czytając zgłoszenia na GitHubie. Czasami gravity się psuło, czasami coś przy aktualizacji…

Początkowo było to do zaakceptowania, ale z czasem, po kilku takich sytuacjach, po prostu stawiałem serwis od nowa.

Dodatkowo w momencie gdy ilość aplikacji w sieci zaczęła rosnąć, a ja dodałem SSL, nie chciałem już ręcznie wpisywać lokalnych domen w UI. Chciałem, aby wszystkie domeny *.home.serhiy.io były przekierowywane na reverse proxy. Niestety Pi-hole nie pozwalało na coś takiego bez kombinacji. Finalnie udało się to zrobić, ale niesmak pozostał.

Przez pierwsze kilka lat problem polegał na tym, że Pi-hole przestawał działać, a internet w domu praktycznie nie działał. Rozwiązaniem było postawienie backupowej instancji Pi-hole i dodanie synchronizacji między nimi — najpierw za pomocą Orbital Sync, następnie Nebula Sync. Niestety od czasu do czasu przy synchronizacji jakaś replika się psuła i znowu nic nie działało.

I tak przez wiele lat żyłem z tym. W sumie działało, tylko raz na kilka miesięcy trzeba było coś poprawić, ale generalnie było stabilnie.

Pora na zmianę

Na początku używałem tylko Raspberry Pi, później LXC w Proxmoxie z backupem na Raspberry Pi Zero PoE. Wszystko niby działało, ale problem z Pi-hole nadal powracał. Dodatkowo, czasem wyłączałem lub Proxmox sam się wyłączał podczas eksperymentów, co powodowało, że internet w domu znowu nie działał. Backup na Raspberry Pi powinien pomagać, ale jak wcześniej wspomniałem, nie zawsze działał.

Pierwsze, co chciałem zmienić, to podejście do hostowania DNS. Bardzo lubię Raspberry Pi, ale niestety nie jest to najbardziej stabilne rozwiązanie 24/7 przez długi czas, głównie ze względu na karty SD i system (chociaż DietPi trochę pomaga). Co więcej, Raspberry Pi Zero 2 okazało się za słabe pod Pi-hole.

Do tej pory główny DNS był hostowany w Proxmox, a zapasowy na Raspberry Pi Zero 2, zasilany PoE. Plan był taki, aby nowy komputer działał jako master DNS, a backup był w Proxmoxie. Idealnie, aby master mógł być zasilany przez PoE i miał więcej mocy niż Raspberry Pi. Nie chciałem iść w Raspberry Pi 4 lub 5. Szukałem czegoś innego i natrafiłem na ultra cienkie komputery biurowe, takie jak Fujitsu Futro czy Dell Wyse.

Dell Wyse 3040

Dell Wyse 3040 to niewielki, energooszczędny komputer zaprojektowany głównie do pracy w środowiskach wirtualnych lub zdalnych pulpitów (np. Citrix, VMware, Microsoft). Nie jest typowym PC‑tem do gier czy zaawansowanych aplikacji lokalnych — jego przeznaczeniem jest raczej praca jako terminal łączący się z serwerami lub usługami w chmurze.

Idealnie pasowało mi to: mały, x86, niski pobór prądu, wydajniejszy niż Raspberry Pi Zero 2 oraz posiada port RJ45 (niestety bez PoE). Najważniejsze — cena. Udało mi się go kupić za 50 zł na Allegro (Raspberry Pi Zero 2 kosztuje ~100 zł).

Szybka instalacja systemu, Docker, Pi-hole i wszystko działało. Do zasilania planuję dokupić przejściówkę RJ45 PoE -> RJ45 + zasilanie, ale nie miałem na to jeszcze czasu.

Nowy komputer trafił do szafy rack, a ostatnie Raspberry Pi zostało usunięte. DNS hostowany w Proxmox teraz służy jako backup.

AdGuard Home

Przez kilka miesięcy po migracji na Dell Wyse nadal używałem Pi-hole, ale problemy pozostały. Pewnego dnia postanowiłem sprawdzić alternatywy i pierwszą, którą wypróbowałem, był AdGuard Home. Ostatecznie pozostałem przy nim, ponieważ idealnie mi pasuje.

AdGuard Home działa na tej samej zasadzie co Pi-hole, ale wymaga mniej konfiguracji, co przekłada się na mniejszą liczbę miejsc, w których coś może się zepsuć. Zmiana polegała głównie na zmianie obrazu w docker-compose.yaml. W samym AdGuard Home jedynie dodałem nowe listy blokowania oraz wpisałem wszystkie serwery w zakładce DNS Rewrites. Rozwiązywanie lokalnej domeny odbywa się łatwo przez wpisanie *.home.serhiy.io.

Co otrzymałem od razu po instalacji, to możliwość wyłączenia lokalnych domen ze statystyk, czego nie dało się zrobić w Pi-hole. Ponieważ wiele lokalnych serwisów działa przez hostname, statystyki byłyby bardzo zaśmiecone. W Pi-hole 90% ruchu generowała maszyna tools, na której działają np. bazy danych.

Do synchronizacji użyłem aplikacji AdGuardHome sync. Działa i tyle.

PS, przykładowy docker-compose.yaml dla AdGuard Home:

services:
  adguardhome:
    image: adguard/adguardhome:latest
    hostname: adguardhome
    restart: unless-stopped
    dns:
      - 1.1.1.1
      - 1.0.0.1
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "853:853/tcp"
      - "8080:8080"
    environment:
      TZ: "Europe/Warsaw"
    volumes:
      - ./adguardhome/work:/opt/adguardhome/work
      - ./adguardhome/conf:/opt/adguardhome/conf
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Podsumowanie

Na moment pisania artykułu korzystam z AdGuard Home od około pół roku i nie było żadnych problemów. Nie wydaje mi się, aby Pi-hole działał przez tyle czasu bez mojej ingerencji.

Jedyny minus AdGuard Home to problem z rozwiązywaniem nazw klientów z UDM, ale na razie nie jest to problematyczne, więc zostawiam to na później. Nie zauważyłem różnicy w blokowaniu reklam, ale stabilność zdecydowanie się poprawiła. Na ten moment zostaję przy AdGuard Home, ponieważ działa dla mnie lepiej.