LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Przegląd bloga /Raspberry Pi / Blokowanie reklam i bezpieczeństwo na poziomie DNS:...
Ten artykuł w innych językach:

Blokowanie reklam i bezpieczeństwo na poziomie DNS: Pi-hole i AdGuard Home w sieci UniFi

Blokowanie reklam i bezpieczeństwo na poziomie DNS: Pi-hole i AdGuard Home w sieci UniFi
Spis treści
  1. Jednoznaczna ścieżka DNS między VLAN-ami
  2. Szyfrowane przekazywanie zapytań
  3. Granice wymuszania ustawień
  4. Weryfikacja i utrzymanie
  5. Pytania i odpowiedzi
  6. Źródła

Pi-hole i AdGuard Home filtrują zapytania DNS: odpytywanie nazw domen można zablokować przed nawiązaniem połączenia. Pozwala to ograniczyć reklamy i śledzenie korzystające z oddzielnych domen na wielu urządzeniach. Filtr nie analizuje treści stron i nie usuwa wybiórczo reklam z tej samej domeny co potrzebna zawartość. Bezpośrednie połączenia z adresami IP, inne resolwery i tunele mogą ominąć filtrowanie DNS.

Reguła portu 53 nie analizuje całego ruchu internetowego.
Filtrowanie DNS kontroluje zapytania o domeny na skonfigurowanej ścieżce. Szyfrowany upstream nie gwarantuje korzystania z tej ścieżki przez wszystkie urządzenia.

Jednoznaczna ścieżka DNS między VLAN-ami

Oddzielny VLAN serwerowy jest możliwym miejscem dla resolwera, a nie warunkiem segmentacji. Stały adres lub rezerwacja DHCP zapewniają przewidywalny dostęp do usługi. Każda objęta filtrowaniem sieć może przekazywać adres resolwera przez DHCP. IPv6 również wymaga spójnych ustawień DNS za pomocą mechanizmów obsługiwanych przez urządzenia i bramę; samo ustawienie IPv4 nie obejmuje IPv6.

Reguły zapory powinny umożliwiać sieciom klienckim dostęp wyłącznie do zatwierdzonych adresów resolwerów na portach UDP i TCP 53. Celem jest strefa serwera, nie automatycznie strefa Gateway. Starsze reguły UniFi używają nazw takich jak LAN IN; obecne reguły strefowe rozróżniają strefę źródłową i docelową. Panel administracyjny resolwera powinien pozostać dostępny tylko dla uprawnionych urządzeń zarządzających.

Sam resolwer musi również przyjmować zapytania z routowanych sieci. Domyślny tryb lokalny Pi-hole może odrzucać inne VLAN-y mimo poprawnej reguły zapory. Odpowiedni tryb nasłuchiwania i ograniczenia zapory wymagają wspólnej konfiguracji. Udostępnianie usługi DNS w internecie nie jest potrzebne w tym układzie.

Szyfrowane przekazywanie zapytań

Upstream to serwer, do którego lokalny filtr przekazuje zapytania bez gotowej odpowiedzi. AdGuard Home bezpośrednio obsługuje szyfrowane serwery nadrzędne. Pi-hole może korzystać z odpowiedniej lokalnej usługi przekazującej; starsze instrukcje z cloudflared proxy-dns nie są już aktualną metodą instalacji.

DoT wykorzystuje TLS, zwykle na porcie TCP 853. DoH przesyła zapytania przez HTTPS, najczęściej na porcie 443. Oba rozwiązania chronią skonfigurowane połączenie, a nie każdy odcinek rozwiązywania nazwy. Wybrany dostawca nadal otrzymuje zapytania. Szyfrowanie nie jest walidacją DNSSEC, która sprawdza podpisane dane DNS. DoH bywa trudniejszy do odróżnienia od innego ruchu HTTPS, ale nie jest niewidoczny ani niemożliwy do zablokowania. Niskie opóźnienie nie jest gwarantowane.

Granice wymuszania ustawień

DHCP przekazuje ustawienia DNS, lecz nie zmusza aplikacji do korzystania z tych ustawień. Polityka może zezwalać na zatwierdzone resolwery i blokować pozostały nieszyfrowany ruch DNS klientów. Blokada może spowodować błąd aplikacji zamiast przełączenia na dozwolony serwer. Połączenia resolwerów z serwerami nadrzędnymi wymagają oddzielnego zezwolenia.

Destination NAT może przekierować pasujący nieszyfrowany ruch DNS, o ile wersja bramy i topologia obsługują potrzebną regułę. Wyjątki dla wszystkich dozwolonych resolwerów, droga powrotna oraz zachowanie IPv4 i IPv6 wymagają osobnej kontroli. Przekierowanie portu 53 nie obejmuje DoH, DoT, VPN ani połączeń pozostających w podsieci bez przechodzenia przez bramę.

Listy znanych szyfrowanych serwerów DNS zapewniają częściowe pokrycie i wymagają aktualizacji. Blokowanie współdzielonych adresów CDN może zakłócić inne usługi. Zarządzane polityki przeglądarek lub ograniczony dostęp do internetu w wydzielonej sieci urządzeń mogą być bardziej przewidywalne, lecz muszą odpowiadać potrzebom aplikacji. Własny Content Filter UniFi także przekierowuje DNS; połączenie obu filtrów wymaga przemyślanej konfiguracji i sprawdzenia nazw lokalnych.

Weryfikacja i utrzymanie

Testy z każdego VLAN-u powinny obejmować dozwoloną domenę, celowo zablokowaną domenę testową, nazwy wewnętrzne, DNS przez TCP i UDP oraz skonfigurowaną ścieżkę IPv6. Dziennik zapytań pokazuje, który resolwer faktycznie obsłużył żądanie. Odpowiedzi w pamięci podręcznej i istniejące połączenia mogą działać jeszcze przez pewien czas po zmianie reguły. Sam wysoki odsetek blokad nie dowodzi ani skutecznej ochrony prywatności, ani usterki aplikacji.

Pytania i odpowiedzi

Co nastąpi po awarii resolwera?

Nowe zapytania mogą zawodzić, podczas gdy zapisane odpowiedzi i istniejące połączenia nadal działają. Drugi filtrowany resolwer poprawia dostępność tylko wtedy, gdy urządzenia i zapora rzeczywiście umożliwiają dostęp do tej instancji. Publiczny drugi resolwer może omijać politykę; wybór klienta nie musi oznaczać ścisłego przełączania z serwera głównego na zapasowy.

Czy domena canary Firefoksa wymusza filtrowanie?

Negatywna odpowiedź dla use-application-dns.net sygnalizuje Firefoksowi wyłączenie automatycznie aktywowanego DoH w udokumentowanych warunkach. Nie zmienia to świadomego włączenia DoH przez użytkownika i nie wymusza filtrowania w całej sieci.

Jak postępować z błędnymi blokadami?

Powtarzalny błąd, dziennik zapytań danego urządzenia i wąski tymczasowy wyjątek pomagają ustalić właściwą domenę. Po teście wyjątek wymaga przeglądu. Dzienniki DNS ujawniają informacje o odwiedzanych usługach, dlatego dostęp i czas przechowywania powinny odpowiadać potrzebom utrzymania sieci.

Lukas Wójcik

Lukas Wójcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Masz pytanie lub pomysł na projekt internetowy? Napisz krótko, o co chodzi. Formularz korzysta z reCAPTCHA do ochrony przed spamem.

Napisanie komentarza

Doświadczenia z innymi modelami i pytania o konfigurację są tu mile widziane.

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.