Prečo Pi-hole v6 ignoruje DNS dopyty od klientov WireGuardu

Pi-hole v6 prijme DNS dopyt na porte 53 a potom rozhodne, či na doručený paket smie odpovedať. Na hostiteľovi s WireGuardom je toto druhé rozhodnutie zvyčajne dôvodom, prečo klient dostane časový limit, hoci resolver vyzerá z LAN zdravo. Port je otvorený, FTL beží, a napriek tomu sa z 10.90.0.1 nič nevracia. Pred odchodom odpovede spolupôsobia tri veci: dns.interface, dns.listeningMode a firewall pred oboma.

Počúvajúci socket nerozhoduje o tom, kto dostane odpoveď

FTL otvára UDP a TCP poslucháče na porte 53. V predvolenej konfigurácii je socket často wildcard, takže ss -lunp | grep :53 ukazuje 0.0.0.0:53 a [::]:53 bez ohľadu na to, či sa VPN klienti obsluhujú. Wildcard socket paket prijme, a až potom FTL pred odpoveďou uplatní pravidlá rozhrania a zdroja. Preto fráza „port počúva“ o klientovi tunela dokazuje len veľmi málo.

Čítajte bežiacu konfiguráciu, nie súbor, ktorý považujete za aktívny. pihole-FTL --config dns.interface a pihole-FTL --config dns.listeningMode vypisujú skutočné hodnoty a môžu sa líšiť od súboru hostiteľa, keď nastavenie vlastní kontajner, premenná prostredia alebo nástroj na nasadenie. Referenčná príručka konfigurácie Pi-hole FTL uvádza režimy a ktorý z nich závisí od rozhrania.

LOCAL sa pýta na podsiet, SINGLE sa pýta na rozhranie

LOCAL, predvolený režim, odpovedá na dopyty, ktorých zdrojová adresa patrí do podsiete nastavenej na niektorom z rozhraní hostiteľa. Jednoduchý wg0 s 10.90.0.1/24 týmto testom prejde, pretože klient na 10.90.0.2 sedí vnútri podsiete tunela. Klient s routingom na druhej strane partnera, alebo klient skrytý za NAT v inom prefixe, ním neprejde, aj keď paket dorazil na wg0, a v logu sa neobjaví žiadny dopyt.

SINGLE mení otázku. Prijíma dopyty, ktoré dorazia na rozhranie uvedené v dns.interface, vrátane loopbacku, a ignoruje zdrojovú podsiet. To je režim, ktorý prežije zreťazenú alebo routovanú topológiu VPN. Nastavte oba kľúče spolu, pretože režim bez uvedeného rozhrania nie je úplná inštrukcia:

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

BIND mení socket, a to má svoju cenu

BIND nefiltruje wildcard socket; pripája port 53 len k adresám, ktoré existujú na uvedenom rozhraní, takže jadro odmieta pakety, ktoré dorazia inam. Je prísnejší ako SINGLE a nie je jeho synonymom. Cena sa prejaví pri štarte: ak wg0 nie je nahor, keď FTL štartuje, nemusí byť adresa na pripojenie a resolver môže bežať bez poslucháča, kým sa rozhranie neobjaví a FTL sa nerestartuje.

BIND zvoľte, keď riadite poradie štartu, napríklad jednotku systemd zoradenú za rozhraním WireGuard, a keď chcete, aby jadro zahodilo zatúlané pakety skôr, než ich FTL uvidí. SINGLE zvoľte, keď tunel prichádza a odchádza, alebo keď rozhranie vytvára nástroj, ktorý štartuje po FTL.

Firewall je druhá brána

Správny režim FTL stále zlyhá, ak firewall hostiteľa zahadzuje port 53 na wg0. Povoľte rozsah zdrojov VPN pre oba protokoly a internetovú stranu nechajte zavretú. V nftables, s existujúcim reťazcom input v tabuľke inet filter, pravidlá vyzerajú 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

Pridajte zodpovedajúce pravidlá IPv6, ak tunel prenáša IPv6, a umiestnite ich pred politiku zahadzovania reťazca. Ak hostiteľ používa ufw alebo firewalld, vyjadrite rovnakú zhodu v tomto správcovi, namiesto miešania nástrojov. Nepresmerúvajte port 53 z internetového routera; klienti majú dosiahnuť VPN adresu resolvera cez tunel.

Dve cesty zostávajú oddelené. Dopyty klientov končia na FTL. Vlastné upstream dopyty FTL odchádzajú podľa smerovacej tabuľky hostiteľa, ktorá tunel môže a nemusí používať, takže resolver, ktorý odpovedá, ale nevracia nič užitočné, je problém upstreamu. Webová administrácia a API počúvajú na vlastných portoch a potrebujú vlastné obmedzenie.

Overte odpoveď aj odmietnutie

Z VPN klienta sa opýtajte adresy resolvera cez oba protokoly: dig @10.90.0.1 example.com a dig +tcp @10.90.0.1 example.com. Potom skontrolujte log dopytov v administračnom rozhraní, aby ste potvrdili, že FTL dopyt zaznamenal. Časový limit klienta bez záznamu v logu ukazuje na firewall alebo filter rozhrania; záznam bez odpovede ukazuje na upstream rozlíšenie.

Otestujte negatívnu cestu z hostiteľa mimo VPN. dig @10.90.0.1 example.com by mal vypršať a ss -lunp na resolvere by nemal ukazovať port 53 viazaný na verejnú adresu. Raz restartujte službu, potom restartujte hostiteľa a potvrďte, že resolver stále odpovedá, keď sa wg0 znovu objaví. Dopyt, ktorý funguje len do ďalšieho restartu, nie je dokončená zmena.