Dlaczego Pi-hole v6 ignoruje zapytania DNS klientów WireGuard

Pi-hole v6 odbiera zapytanie DNS na porcie 53, a następnie decyduje, czy przybyły pakiet może otrzymać odpowiedź. Na hoście WireGuard ta druga decyzja jest zwykle powodem, dla którego klient dostaje przekroczenie czasu, podczas gdy resolver wygląda zdrowo z LAN-u. Port jest otwarty, FTL działa, a jednak nic nie wraca z 10.90.0.1. Trzy rzeczy współdziałają, zanim odpowiedź wyjdzie: dns.interface, dns.listeningMode oraz zapora przed oboma.

Gniazdo nasłuchujące nie decyduje, kto dostanie odpowiedź

FTL otwiera nasłuchy UDP i TCP na porcie 53. W konfiguracji domyślnej gniazdo jest często wildcard, więc ss -lunp | grep :53 pokazuje 0.0.0.0:53 i [::]:53 niezależnie od tego, czy klienci VPN są obsługiwani. Gniazdo wildcard przyjmuje pakiet, a następnie FTL stosuje swoje reguły interfejsu i źródła, zanim odpowie. Dlatego zdanie „port nasłuchuje” dowodzi bardzo niewiele o kliencie tunelu.

Czytaj działającą konfigurację, a nie plik, który uważasz za aktywny. pihole-FTL --config dns.interface i pihole-FTL --config dns.listeningMode wypisują rzeczywiste wartości i mogą różnić się od pliku hosta, gdy ustawieniem zarządza kontener, zmienna środowiskowa lub menedżer wdrożeń. Dokumentacja konfiguracji Pi-hole FTL wymienia tryby i wskazuje, który z nich opiera się na interfejsie.

LOCAL pyta o podsieć, SINGLE pyta o interfejs

LOCAL, tryb domyślny, odpowiada na zapytania, których adres źródłowy należy do podsieci skonfigurowanej na jednym z interfejsów hosta. Prosty wg0 z 10.90.0.1/24 przechodzi ten test, ponieważ klient pod 10.90.0.2 znajduje się w podsieci tunelu. Klient z routingiem po drugiej stronie peera, albo klient ukryty za NAT-em w innym prefiksie, nie przechodzi go, mimo że pakiet dotarł na wg0, i w logu nie pojawia się żadne zapytanie.

SINGLE zmienia pytanie. Akceptuje zapytania, które przychodzą na interfejs wskazany w dns.interface, z pętlą zwrotną włącznie, i ignoruje podsieć źródłową. To tryb, który przetrwa łańcuchową lub rutowaną topologię VPN. Ustaw oba klucze razem, bo tryb bez wskazanego interfejsu nie jest pełną instrukcją:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND zmienia gniazdo i ma to swoją cenę

BIND nie filtruje gniazda wildcard; wiąże port 53 tylko z adresami, które istnieją na wskazanym interfejsie, więc jądro odrzuca pakiety przychodzące gdzie indziej. Jest surowszy niż SINGLE i nie jest jego synonimem. Cena pojawia się przy starcie: jeśli wg0 nie jest podniesione, gdy FTL startuje, może nie być adresu do powiązania, a resolver może działać bez nasłuchu, dopóki interfejs nie pojawi się i FTL nie zrestartuje.

Wybierz BIND, gdy kontrolujesz kolejność startu, na przykład jednostkę systemd uporządkowaną po interfejsie WireGuard, i gdy chcesz, aby jądro odrzucało zabłąkane pakiety, zanim FTL je zobaczy. Wybierz SINGLE, gdy tunel pojawia się i znika, lub gdy interfejs tworzy narzędzie startujące po FTL.

Zapora to druga brama

Poprawny tryb FTL nadal zawodzi, jeśli zapora hosta odrzuca port 53 na wg0. Przepuść zakres źródeł VPN dla obu protokołów i pozostaw stronę internetową zamkniętą. W nftables, z istniejącym łańcuchem input w tabeli inet filter, reguły wyglądają tak:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Dodaj pasujące reguły IPv6, jeśli tunel przenosi IPv6, i umieść je przed polityką odrzucania łańcucha. Jeśli host używa ufw lub firewalld, wyraź to samo dopasowanie w tym menedżerze, zamiast mieszać narzędzia. Nie przekazuj portu 53 z routera internetowego; klienci powinni docierać do adresu VPN resolvera przez tunel.

Dwie ścieżki pozostają oddzielne. Zapytania klientów kończą się na FTL. Własne zapytania FTL do nadrzędnych wychodzą zgodnie z tabelą routingu hosta, która może, ale nie musi, używać tunelu, więc resolver, który odpowiada, ale nie zwraca nic użytecznego, jest problemem nadrzędnym. Panel www i API nasłuchują na własnych portach i potrzebują własnego ograniczenia.

Sprawdź odpowiedź i odmowę

Z klienta VPN odpytaj adres resolvera oboma protokołami: dig @10.90.0.1 example.com i dig +tcp @10.90.0.1 example.com. Następnie sprawdź log zapytań w interfejsie administracyjnym, aby potwierdzić, że FTL zapisał zapytanie. Przekroczenie czasu u klienta bez wpisu w logu wskazuje na zaporę lub filtr interfejsu; wpis bez odpowiedzi wskazuje na rozwiązywanie nadrzędne.

Sprawdź ścieżkę negatywną z hosta poza VPN-em. dig @10.90.0.1 example.com powinno zakończyć się przekroczeniem czasu, a ss -lunp na resolverze nie powinno pokazywać portu 53 powiązanego z adresem publicznym. Zrestartuj usługę raz, potem zrestartuj hosta i potwierdź, że resolver nadal odpowiada, gdy wg0 pojawi się ponownie. Zapytanie, które działa tylko do następnego restartu, nie jest ukończoną zmianą.