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

Spis treści
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.

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.