Proč Pi-hole v6 ignoruje DNS dotazy od klientů WireGuardu

Pi-hole v6 přijme DNS dotaz na portu 53 a potom rozhodne, zda na paket, který dorazil, smí odpovědět. Na hostiteli s WireGuardem je toto druhé rozhodnutí obvykle důvodem, proč klient dostane časový limit, zatímco resolver vypadá z LAN zdravě. Port je otevřený, FTL běží, a přesto se z 10.90.0.1 nic nevrací. Než odpověď odejde, spolupůsobí tři věci: dns.interface, dns.listeningMode a firewall před oběma.

Naslouchající socket nerozhoduje o tom, kdo dostane odpověď

FTL otevírá UDP a TCP posluchače na portu 53. Ve výchozí konfiguraci je socket často wildcard, takže ss -lunp | grep :53 ukazuje 0.0.0.0:53 a [::]:53 bez ohledu na to, zda jsou VPN klienti obsluhováni. Wildcard socket paket přijme, a teprve potom FTL před odpovědí uplatní pravidla rozhraní a zdroje. Proto fráze „port naslouchá“ o klientovi tunelu dokazuje jen velmi málo.

Čtěte běžící konfiguraci, ne soubor, který považujete za aktivní. pihole-FTL --config dns.interface a pihole-FTL --config dns.listeningMode vypisují skutečné hodnoty a mohou se lišit od souboru hostitele, když nastavení vlastní kontejner, proměnná prostředí nebo nástroj pro nasazení. Referenční příručka konfigurace Pi-hole FTL uvádí režimy a který z nich závisí na rozhraní.

LOCAL se ptá na podsíť, SINGLE se ptá na rozhraní

LOCAL, výchozí režim, odpovídá na dotazy, jejichž zdrojová adresa patří do podsítě nastavené na některém z rozhraní hostitele. Jednoduchý wg0 s 10.90.0.1/24 tento test projde, protože klient na 10.90.0.2 sedí uvnitř podsítě tunelu. Klient s routingem na druhé straně peeru, nebo klient skrytý za NATem v jiném prefixu, jím neprojde, i když paket dorazil na wg0, a v logu se neobjeví žádný dotaz.

SINGLE mění otázku. Přijímá dotazy, které dorazí na rozhraní uvedené v dns.interface, včetně loopbacku, a ignoruje zdrojovou podsíť. To je režim, který přežije zřetězenou nebo routovanou topologii VPN. Nastavte oba klíče společně, protože režim bez pojmenovaného rozhraní není úplná instrukce:

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

BIND mění socket, a to má svou cenu

BIND nefiltruje wildcard socket; připojuje port 53 jen k adresám, které existují na pojmenovaném rozhraní, takže jádro odmítá pakety, které dorazí jinam. Je přísnější než SINGLE a není jeho synonymem. Cena se objeví při startu: pokud wg0 není nahoře, když FTL startuje, nemusí být adresa k připojení a resolver může běžet bez posluchače, dokud se rozhraní neobjeví a FTL se nerestartuje.

BIND zvolte, když řídíte pořadí startu, například jednotku systemd seřazenou za rozhraním WireGuard, a když chcete, aby jádro zahodilo zatoulané pakety dřív, než je FTL uvidí. SINGLE zvolte, když tunel přichází a odchází, nebo když rozhraní vytváří nástroj, který startuje po FTL.

Firewall je druhá brána

Správný režim FTL stále selže, pokud firewall hostitele zahazuje port 53 na wg0. Povolte rozsah zdrojů VPN pro oba protokoly a internetovou stranu nechte zavřenou. V nftables, s existujícím řetězcem input v tabulce inet filter, vypadají pravidla takto:

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

Přidejte odpovídající pravidla IPv6, pokud tunel přenáší IPv6, a umístěte je před politiku zahazování řetězce. Pokud hostitel používá ufw nebo firewalld, vyjádřete stejnou shodu v tomto správci, místo abyste míchali nástroje. Nepřesměrovávejte port 53 z internetového routeru; klienti mají dosáhnout VPN adresy resolveru přes tunel.

Dvě cesty zůstávají oddělené. Dotazy klientů končí na FTL. Vlastní upstream dotazy FTL odcházejí podle směrovací tabulky hostitele, která tunel může a nemusí používat, takže resolver, který odpovídá, ale nevrací nic užitečného, je problém upstreamu. Webová administrace a API poslouchají na vlastních portech a potřebují vlastní omezení.

Ověřte odpověď i odmítnutí

Z VPN klienta se dotazujte adresy resolveru přes oba protokoly: dig @10.90.0.1 example.com a dig +tcp @10.90.0.1 example.com. Potom zkontrolujte log dotazů v administračním rozhraní, abyste potvrdili, že FTL dotaz zaznamenal. Časový limit klienta bez záznamu v logu ukazuje na firewall nebo filtr rozhraní; záznam v logu bez odpovědi ukazuje na upstream rozlišení.

Otestujte negativní cestu z hostitele mimo VPN. dig @10.90.0.1 example.com by měl vypršet a ss -lunp na resolveru by neměl ukazovat port 53 vázaný na veřejnou adresu. Jednou restartujte službu, potom restartujte hostitele a potvrďte, že resolver stále odpovídá, když se wg0 znovu objeví. Dotaz, který funguje jen do dalšího restartu, není dokončená změna.