Kierowanie klientów OpenVPN na resolver Pi-hole na innym hoście

Wpisanie adresu Pi-hole do profilu OpenVPN nie tworzy ścieżki do niego, nie daje prawa do odpytywania go ani nie gwarantuje, że klient go użyje. Gdy Pi-hole działa na osobnym komputerze w sieci LAN, cztery rzeczy muszą się zgadzać: trasa od klienta, przekazywanie z bramy, ścieżka powrotna do puli i polityka odbioru na samym Pi-hole. Każda awaria wygląda w logu inaczej. Przejście przez nie w tej kolejności jest szybsze niż naprawianie ostatniej jako pierwszej. Zwykły skrót, otwarcie rekurencji dla każdego źródła, zamienia mały problem na trwały.

Co robi, a czego nie robi wypychana opcja DNS

Serwer ogłasza resolver poniższą dyrektywą, zakładając, że 192.168.50.53 to host Pi-hole. Klient odbiera opcję i, w zależności od platformy i integracji resolvera , stosuje ją do interfejsu tunelu albo ignoruje na rzecz lokalnego stuba. Linia trasy liczy się tak samo jak linia DNS, bo resolver, do którego klient nie dociera, nie jest żadnym resolverem. Nic z tego nie jest widoczne od strony serwera.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Odebranie opcji to nie to samo co jej użycie. Klient Linuksa z menedżerem resolvera może zaakceptować wypychany serwer i wysyłać do niego tylko wybrane domeny; klient, który sam zarządza DNS, może całkowicie nadpisać ustawienie. Wypychane trasy są też ograniczone na niektórych platformach, co pozostawia resolver nieosiągalnym, mimo że opcja została zaakceptowana. Sprawdzaj na kliencie, który serwer odpowiada, a nie na serwerze, co zostało wysłane.

Opcja nie mówi też nic o stronie serwera. Ruch DNS nadal musi wędrować od klienta do bramy i od bramy do Pi-hole, zanim jakakolwiek opcja zacznie mieć znaczenie. Brakująca trasa i odrzucone zapytanie wyglądają z perspektywy klienta tak samo, więc najpierw potwierdź przekazywanie na bramie.

Ścieżka powrotna z Pi-hole do puli

Jeśli adres źródłowy klienta jest zachowany, Pi-hole odpowiada na adres wewnątrz puli VPN. Jego własna tablica routingu prawdopodobnie nic nie wie o tej puli, więc odpowiedź trafia do jego bramy domyślnej i znika. Dziennik zapytań pokazuje żądanie bez pasującej odpowiedzi, co łatwo pomylić z problemem zapory.

Daj routerowi LAN statyczną trasę do puli z bramą OpenVPN jako następnym skokiem albo tłumacz źródło na bramie przed przekazaniem do Pi-hole. Pierwsze rozwiązanie utrzymuje adresy poszczególnych klientów widoczne w dzienniku zapytań Pi-hole. Drugie usuwa wymóg trasy powrotnej, ale sprawia, że każde zapytanie wygląda, jakby pochodziło z bramy. Żadne nie jest błędne; odpowiadają na różne pytania.

Jeśli raportowanie lub polityka per klient mają znaczenie, statyczna trasa jest lepszą wymianą. Jeśli siecią LAN zarządza ktoś inny i trasa nie jest dostępna, tłumaczenie jest opcją pragmatyczną, a utrata tożsamości klienta wymaga zapisania. Zanotuj, którą wybrałeś, bo każde późniejsze pytanie o logi od tego zależy.

Tryb nasłuchu Pi-hole dla klientów routowanych

Lista rozwijana zachowania nasłuchu interfejsów na stronie ustawień w sekcji DNS decyduje, którym źródłom Pi-hole odpowiada. Najsurowsza opcja akceptuje tylko klientów w sieciach podłączonych bezpośrednio; opcja dopuszczająca urządzenia co najwyżej o jeden skok dalej rozszerza to na podsieci za sąsiednim routerem, a tak właśnie wygląda routowany klient VPN. Pakiet faktycznie dociera na interfejs LAN, ale jego adres źródłowy należy do innej podsieci. To odmowa polityki, a nie awaria routingu, i ta różnica ma znaczenie przy czytaniu logów.

Przewodnik Pi-hole po nasłuchu oddziela źródła podłączone lokalnie od źródeł routowanych, a interfejs przybycia nie jest kryterium. Wybierz tryb, który dopuszcza pulę VPN bez dopuszczania całego internetu, a potem połącz go z regułą zapory akceptującą DNS tylko z puli.

Otwarcie rekurencji dla wszystkich źródeł, aby pierwsze zapytanie zadziałało, to zła naprawa. Zamienia prywatny resolver w otwarty, a poprawką jest uprawnienie o zawężonym zakresie, nie globalne.

Dopasuj odpowiedź do dziennika zapytań

Zapytaj klienta, potem sprawdź serwer i porównaj oba. Na kliencie systemd-resolved poniższe polecenia pokazują, który resolver wytworzył odpowiedź i jakie serwery są skonfigurowane dla każdego łącza. Użyj nazwy, którą zna tylko Pi-hole, bo bezpośrednie zapytanie na adres Pi-hole dowodzi osiągalności, a nie konfiguracji.

resolvectl query intranet.example.lan
resolvectl dns

Oczekiwana odpowiedź wskazuje 192.168.50.53 jako serwer i zwraca adres, który znałby tylko ten resolver. Potem spójrz na widok samego Pi-hole: pihole -t śledzi dziennik zapytań na żywo, a każdy wiersz niesie adres źródłowy. Jeśli źródłem jest adres tunelu klienta, trasa puli jest nienaruszona. Jeśli to adres LAN bramy, w grę wchodzi tłumaczenie źródła i własny adres klienta nigdy się nie pojawi.

Jeśli w logu nie pojawia się nic, zapytanie nigdy nie dotarło do Pi-hole, a następną rzeczą do sprawdzenia jest przekazywanie na bramie. Jeśli zapytanie się pojawia, a odpowiedź nie wraca, problemem jest ścieżka powrotna, czyli poprzednia sekcja. Rozdzielenie awarii w ten sposób chroni przed pomyleniem błędu routingu z regułą zapory.

Sprawdź regułę przekazywania bramy

Brama musi przekazywać pakiety DNS klienta w stronę Pi-hole, a regułę, która to robi, warto przeczytać zamiast zakładać. Poniższe polecenia listują reguły dotyczące portu 53 wraz z licznikami, na hoście nftables i na hoście iptables. Reguła, która istnieje, ale pokazuje zero dopasowań, jest sygnałem, że ruch jest odrzucany, zanim zostanie przetłumaczony.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Czytaj liczniki, nie tylko reguły. Reguła, która nigdy nie pasuje, oznacza, że pakiet wychodzi innym interfejsem albo klient nigdy go nie wysłał. Reguła, która pasuje przy każdym zapytaniu, oznacza, że przekazywanie działa, a problem jest dalej na ścieżce.

Niezależnie od narzędzia używanego przez hosta, utrzymuj sprawdzenie wąskie: pula jako źródło, port 53 jako cel i Pi-hole jako jedyny dozwolony cel. Szeroka reguła przekazywania, która dopuszcza też port 80, to inny problem czekający na wystąpienie.