W tym wpisie dowiesz się, jak zagrać na nosie reklamodawcom, jak wyciąć ich niezbyt radosną twórczość (nie, reklam na YouTube nie usuniesz tym), jak działa DNS, dlaczego warto mieć własny serwer DNS i mieć nad tym jakąś kontrolę.

Dodam jednocześnie, że funkcjonowanie DNS jest dość proste i cholernie przydatne, a po chwili okiełznania – bardzo wygodne. Ta wiedza przyda się potem przy rejestracji domen, użycia ich w ramach swojego środowiska a nawet w trakcie diagnozowania problemów z siecią. To zaskakujące, jak bardzo prosty jest ten protokół, a jaki jednocześnie potężny.

Co to jest DNS?

Kojarzysz zapewne coś takiego, jak adres www. Zdarzyło ci się nawet pewnie wpisać taki w adres przeglądarki, nie wiem, jakiś google.com? A może tylkowentylatory.com? Niezależnie od tego, podałeś adres, który korzysta z jakiejś domeny i wykonuje coś pod maską. Spójrz na jakieś tutoriale związane z uruchamianiem stron na własnym komputerze, każdy z nich kończy się w zasadzie wpisem pokroju „wpisz w przeglądarce adres 192.168.1.56:8080 i jeśli wyświetli się coś, to fajrant, koniec kursu”. Dlaczego więc taki Google działa z domeną google.com a Twoja ciężko skopiowana z kursu strona na 192.168.1.56:8080? Przecież, jak przeczytałeś w jednym z poprzednich wpisów, maszyny raczej preferują posługiwanie się adresami IP, a jakieś tam literki są dla humanoidalnych zboczeńców.

To, co spina to ze sobą, to właśnie DNS, który w pewien sposób tłumaczy google.com na adres IP gdzieś w internetach i pod maską pozwala na przekazanie Twojego zapytania o stronę internetową do serwera, który w zamian odeśle pachnącą nowością stronę, nie gubiąc jej po drodze.

Jak on działa?

Ty, jako klient wysyłasz zapytanie z jakąś domeną. Niech to będzie google.com. Jak wygląda schemat? Prześledźmy drogę od momentu wciśnięcia klawisza enter:

– [Komputer]: O nie, nie mam bladego pojęcia, gdzie ta cała google.com się podziewa. Rozwiązywacz Nazw Domenowych! Na stanowisko! Szybko!

– [Lokalny DNS] (np. router, DNS operatora, Cloudflare, Google – zależy od ustawień): Spoko, szefie, ogarniam. Zaraz coś znajdę.

– [LD] (szepcząc do Sieciowego Posłańca): Ej, zaniesiesz to do root serwera, zapytaj go, gdzie szukać .com. Tylko szybko – komputerek już sapie.

– [Posłaniec] (czyli pakiet DNS lecący przez internet): Dzień dobry, Root Serwerze! Gdzie znajdę coś o .com?

– [Root Serwer]: Ha! Sam nie wiem, co to google.com, ale powiem ci, gdzie są serwery obsługujące .com. Masz tu listę – idź do nich.

– [Posłaniec] (już zadyszany): Serwerze .com, masz może namiary na google.com?

– [Serwer TLD .com]: IP? Nieee… ale wiem, kto wie. Idź do autorytatywnego serwera DNS dla google.com. Proszę bardzo – ns1.google.com.

– [Posłaniec] (ostatkiem sił): Panie ns1.google.com, błagam – gdzie jest google.com?

– [Autorytatywny DNS dla google.com]: No wreszcie ktoś mnie pyta konkrety. Masz – google.com to 108.177.122.102. Zanieś to do tego twojego lokalnego DNS-a.

– [Posłaniec wraca do Lokalnego DNS]: Mam IP! Mam IP! 108.177.122.102!

– [LD] (dumnie, jakby sam znalazł): Komputerze, proszę bardzo – oto adres google.com. Możesz już wysłać tam swoje żądania HTTP, gołębiem, rakietą czy czym tam chcesz.

A co, jak trafimy na wyjątek od reguły?

• Któryś z serwerów może powiedzieć: „Nie znam takiej domeny” → wraca błąd DNS, np. NXDOMAIN.
• Może też nie odpowiedzieć wcale → dostajesz timeout.
• Albo… może odpowiedź już była w cache’u – wtedy lokalny DNS od razu rzuca IP jak z rękawa. Nikt nie musi biegać.

Jak widać, nie jest to skomplikowane i po chwili można się w tym odnaleźć.

Co ma do tego Adguard?

Reklamy, które widzisz na stronach internetowych, w aplikacjach czy też innych miejscach, są osiągalne na konkretnych domenach, pod konkretnymi adresami. Twój komputer wysyła zapytania także i po nie, ale co, gdyby nie otrzymał na nie odpowiedzi? No i tutaj wchodzi Adguard Home cały na biało. Posiada listę domen, które mają nie zostać rozwiązane a przez to nie wyświetlone. Na tym polega to blokowanie – pilnowanie, aby nie rozwiązać DNS dla reklam, przez co się nie wyświetlą.

Przygotowanie

Przygotuj jedną maszynę z Debianem (czy czymkolwiek tam chcesz) i zainstaluj na niej Dockera. Zadbaj także, aby ta maszyna miała stały adres IP z routera (jeśli to VirtualBox, wybierz odpowiedni tryb pracy karty sieciowej), który będzie osiągalny z poziomu innego urządzenia w sieci (z telefonu, laptopa, peceta… po prostu wyślij ping na adres maszyny z Debianem, jak odpowie, jesteśmy w domu). Warto mieć jeszcze pod ręką jakieś inne urządzenie, jak telefon czy tablet, aby zobaczyć, czy wszystko prawidłowo działa na innej maszynie, niż pecet. Nie, że to ma znaczenie, po prostu zajebiście jest widzieć, że takie rzeczy żyją i działają.

Kontener z Adguard Home

Przyjrzyj się poniższemu plikowi docker-compose.yml. To moja aktualna konfiguracja blokowacza reklam, który lata radośnie od kilku lat w mojej sieci. Oczywiście, że nie napisałem go samodzielnie od zera, a został zajumany pożyczony i docięty pod moje preferencje. To IT, szanujmy się 🙂

version: '3'
services:
  adguardhome:
    container_name: adguardhome
    image: adguard/adguardhome
    restart: unless-stopped
    ports:
      - 53:53/udp
      - 8066:80/tcp
      - 4433:443/tcp
      - 3000:3000
    volumes:
      - ./appdata/adguardhome/conf:/opt/adguardhome/conf
      - ./appdata/adguardhome/work:/opt/adguardhome/work

Pierwsze linijki wskazują na to, jakiego obrazu mamy użyć (image: adguard/adguardhome), jak się kontener ma nazywać (container_name: adguardhome) a także ważna rzecz, jaką jest linijka restart.

Co ona robi? Wskazuje na zachowanie kontenera, gdy ten wywali się na plecy i aplikacja nie będzie funkcjonować. Jeśli nie wskażemy tego zachowania zawczasu, wówczas możemy obudzić się z niedziałającym internetem, na co wskaże partnerka terkotając coś o niedziałającym instagramie. Oczywiście internet będzie, ale DNS nie będzie rozwiązywać nazw, przecież to takie oczywiste…

Wracając do tematu, dopisując restart: unless-stopped kontener po awarii sam wystartuje jak gdyby nigdy nic. Dlaczego jednak nie wgrzmocić tutaj restart: always? Przecież taki kontener się też ponownie uruchomi po awarii. Różnica jest jednak taka, że jeśli ręcznie zatrzymamy kontener, unless-stopped będzie dalej położony, a always będzie na siłę starać się wystartować, potencjalnie robiąc nam srogi bałagan w pracy, którą będziemy wykonywać.

Przyjrzyj się sekcji ports. Tutaj dzieje się magia, która jest dla nas istotna. DNS jako taki (w ramach IPv4) działa na porcie 53/UTP i nie jest to możliwe do zmiany. Nie zmienia się portu nasłuchu DNS (jak ma to miejsce w innych uruchamianych aplikacjach), bo to po prostu nie zadziała. Hosty nie będą wysyłać zapytań o rozwiązanie nazw domen na inny port. Nie, zapomnij o tym, nie drąż, idziemy dalej. A co to UTP? Pakiety, które są wysyłane, nie wymagają potwierdzenia dotarcia (jak ma to miejsce w TCP). To tak, jakbyś krzyknął za kierownicą „ty prąciu nieprosty!” do innego kierowcy – może usłyszy, może nie, ale w sumie nie ma to znaczenia, komunikat poszedł i tyle. W przypadku TCP oczekiwałbyś, że nastąpi wymiana informacji na temat poziomu prowadzenia samochodu, czyli będzie jakaś forma potwierdzenia otrzymania komunikatu – kierowca odpowie „odnoszę wrażenie, że twoja rodzicielka!”.

Oczywiście w ramach IPv6 należy spodziewać się innego portu. Z racji, że nie używam IPv6, nie podejmuję rękawicy w tłumaczeniu tego wymysłu kurtyzany i czarta.

Porty, których potrzebujemy obligatoryjnie to:

– 53/UDP – jak wyżej, tutaj dzieje się magia z DNS

– 80/TCP – do panelu WWW z zarządzaniem, u mnie przekierowane na 8066, bo domyślny jest zajęty już przez coś

– 443/TCP – jak wyżej, ale z HTTPS/SSL, tak samo przekierowany, bo domyślny już jest zajęty

– 3000 – potrzebny do instalacji i pierwszej konfiguracji Adguarda

Oczywiście jest tego do skonfigurowania więcej, można wskazać na porty DHCP (tak, Adguard z jakiegoś powodu może być serwerem DHCP i ponoć są ludzie, którzy z tego korzystają), można walnąć sobie DNS z szyfrowaniem, można wrzucić to wszystko na IPv6… ale nie to jest teraz istotne. Więcej tego znajdziesz na samym końcu wpisu.

Linijki pod volumes wskazują, gdzie mają znajdować się dane tego kontenera, takie jak configi, logi, pliki tymczasowe i inne pierdolety. Skonfiguruj to jednak, bo jak zapomnisz, kontener wystartuje, ale po restarcie może sobie zapomnieć ustawień (a pamiętasz o niedziałającym instagramku?).
Wbij na maszynę po ssh czy inną znaną sobie metodą. Następnie utwórz nowy katalog i wejdź w niego:

mkdir Adguard && cd Adguard

i w nim utwórz plik docker-compose.yml:

touch docker-compose.yml

Użyj dowolnego edytora tekstu, aby tam wkleić zawartość configa:

nano docker-compose.yml

Wklej zawartość schowka, następnie zapisz to klawiszami CTRL+o, zatwierdź (użycia entera i czytania ze zrozumieniem nie muszę tłumaczyć), następnie wyjdź klawiszami CTRL+x.

No i wielka chwila, startujemy!

docker-compose up -d

lub:

docker compose up -d

Jeśli wszystko poszło po naszej myśli, zobaczysz coś takiego:

Jeśli nie, zweryfikuj wszystkie kroki ponownie.

Sprawdź, czy kontener po starcie się nie przewrócił, przy użyciu komendy:

docker ps -a

Kontener pracuje, status na to wskazuje (od około minuty nie przewrócił się).

Konfiguracja Adguard Home.

Jeśli na tym etapie nie znasz adresu IP swojej maszyny (bo robiłeś konfigurację w oknie VirtualBoxa jak pizda, zamiast legitnie przez SSH), wpisz w tym cholernym okienku polecenie

ip addr sh

i przeczytaj ze zrozumiem output, tam znajdziesz swój adres IP:

Wpisz w przeglądarce internetowej adres składający się z http://IP maszyny:3000, na przykład:

http://192.168.10.23:3000

co powinno zaowocować takim widokiem:

W następnym kroku przyjdzie nam konfigurować aplikację. Niech nie przyjdzie ci do głowy zmiana portu z 80 na inny! W docker-compose.yml wskazałeś, że port 80 mapujesz na coś innego i jeśli to zmienisz, stracisz zarządzanie! Właściwie to możesz zostawić domyślne ustawienia.

W następnym kroku skonfiguruj hasłologię do swojego panelu zarządzania.

Idąc dalej, po naciśnięciu przycisku Zakończ odbijesz się od komunikatu, że nie można otworzyć strony. Jak myślisz, dlaczego?

3…

2…

1…

Spójrz na pasek adresu w przeglądarce. Przekierowało cię na adres http://192.168.cośtam.cośtam. Domyślnie to http:// wskazuje na port 80 (TCP). A w configu na jaki port wskazałeś? No właśnie.

Wskakuj w takim razie na adres:

http://TwójIP:8066

I wpisz ustawione wcześniej login i hasło.

Brawo, właśnie uruchomiłeś swój pierwszą utylitarną aplikację.

Praktyka

Aplikacja działa. Ustaw w swoim systemie serwer DNS wskazując maszynę, na której jest uruchomiony Adguard. Spójrz na poniższy screenshot:

1. W Linuksie w pliku /etc/resolv.conf znajdują się informacje o DNS, w tym właśnie wpis związany ze wskazaniem serwera. To tutaj wskazany został serwerek z Adguardem
2. W jakiś sposób trzeba było wysłać zapytanie wymagające rozwiązania domen. Najprostszy jest ping. Użyłem go, jak widać domena wp.pl została rozwiązana na odpowiedni adres
3. W Dzienniku zapytań w konsoli zarządzania Adguardem pojawiły się wpisy związane z tym zapytaniem
4. Adres IP maszyny pingującej to 192.168.10.24, i taki (5) właśnie jest adres IP klienta w logach dla danego zapytania.

Brawo. Działa, opanowałeś to. Piwko się należy.

To teraz spróbuj powtórzyć to na telefonie lub tablecie. W najgorszym przypadku wrócisz do poprzednich ustawień, spokojnie.

Prawda, że to fajnie wygląda, gdy to działa jak należy i to żyje?

Zmiana DNS w sieci

To ten, opcja dla odważnych, ale skoro tutaj jesteś (i nie jebłeś iksa na zakładce) to chyba taki jesteś, nie? No nie masz psychy do ustawienia tego w całej sieci, no weź…

…ale jeśli masz, to wejdź w ustawienia routera i zmień adres DNS na ten z Adguarda.

Ale zanim to zrobisz, pamiętaj o kilku rzeczach:

• Nie możesz wskazywać alternatywnych serwerów DNS! Jeśli je wskażesz, reklamy mogą się pojawiać nadal!
• Jeśli wyłączysz maszynę z Adguardem, zdejmujesz serwer DNS – instagramek skarbie nie działa… – pamiętaj o tym!

Blokowanie reklam i malware na poważnie

Zajrzyj w linki pod wpisem. Znajdziesz tam wiele źródeł do list z blokadą wkurzających rzeczy na stronach. Aby je zastosować, idź do zakładki Filtry -> Listy zablokowanych DNS.

Pomyszkuj także w ustawieniach filtrów. Znajdziesz tam wiele ciekawych ustawień, jak blokowanie całych usług (jak tego biednego imstagramka czy inne tylkowentylatory). Przydatne przy dzieciakach, które nie ogarniają DNS.

Konkluzja

Nie będzie przesadą stwierdzenie, że uruchomiłeś lokalny serwer DNS. Masz nad nim pełną kontrolę i otwiera to przed tobą ogromne pokłady możliwości (wycinanie reklam, myszkowanie kto na co tam zaglądał, blokowanie całych usług, etc) ale także i wiąże się, jak każda wielka moc, z odpowiedzialnością. Zatem korzystaj z tego odpowiedzialnie, bo DNS, pomimo swojej dość wręcz prymitywnej budowy, jest potężnym narzędziem, będącym mieczem obosiecznym w rękach kogoś, kto nie powinien mieć w ręce nawet metalowej kulki, bo i taką zepsuje.

A piHole?

Używałem w domu kilka lat, obecnie zostawiłem w paru mniej ważnych środowiskach. Ma swoje bolączki, ale działa na chyba wszystkim, co ma CPU. Niemniej zdarzyło mi się doświadczyć rozsypanych configów (nie pamiętał hasła do admina, bo tak i nie zadawaj pytań), albo puszczał wszystko, nie blokując niczego. Jednak nadmienię, że to było dawno temu i te problemy mogły zostać załatane jakieś 30 razy. Zachęcam do sprawdzenia.

Przydatne linki i źródła

• Adguard Home (link do projektu) https://hub.docker.com/r/adguard/adguardhome
• Adguard https://adguard.com
• Cloudflare – What is DNS? https://www.cloudflare.com/learning/dns/what-is-dns/
• Cloudflare – DNS Records https://www.cloudflare.com/learning/dns/dns-records/
• piHole (projekt) https://pi-hole.net/
• Sekurak – cały potężny artykuł o piHole i o blokowaniu reklam/malware/czegokolwiek na poziomie DNS https://sekurak.pl/zabezpieczamy-domowa-siec-przed-stronami-wyludzajacymi-od-nas-dane-konfiguracja-pi-hole/
• Generator list z blokowaniem reklam https://blocklist.sefinek.net/
• Kolejne listy do blokowania https://github.com/adguardteam