Varför Pi-hole v6 ignorerar DNS-förfrågningar från WireGuard-klienter

Pi-hole v6 tar emot en DNS-förfrågan på port 53 och avgör sedan om paketet som kom in får besvaras. På en WireGuard-värd är det andra beslutet oftast anledningen till att en klient får timeout medan resolvern ser frisk ut från LAN. Porten är öppen, FTL körs, och ändå kommer inget tillbaka från 10.90.0.1. Tre saker samverkar innan ett svar lämnar systemet: dns.interface, dns.listeningMode och brandväggen framför båda.

Lyssningssocketen avgör inte vem som får ett svar

FTL öppnar UDP- och TCP-lyssnare på port 53. I standardkonfigurationen är socketen ofta wildcard, så ss -lunp | grep :53 visar 0.0.0.0:53 och [::]:53 oavsett om VPN-klienter betjänas. En wildcard-socket tar emot paketet, sedan tillämpar FTL sina gränssnitts- och källregler innan den svarar. Därför bevisar "porten lyssnar" mycket lite om en tunnelklient.

Läs den körande konfigurationen i stället för filen du tror är aktiv. pihole-FTL --config dns.interface och pihole-FTL --config dns.listeningMode skriver ut de faktiska värdena, och de kan skilja sig från värdens fil när en container, miljövariabel eller driftsättningshanterare äger inställningen. Pi-hole FTL-konfigurationsreferensen listar lägena och vilket av dem som bygger på gränssnittet.

LOCAL frågar vilket subnät, SINGLE frågar vilket gränssnitt

LOCAL, standardläget, svarar på förfrågningar vars källadress tillhör ett subnät som är konfigurerat på ett av värdens gränssnitt. En enkel wg0 med 10.90.0.1/24 klarar det testet, eftersom klienten på 10.90.0.2 sitter inne i tunnelns subnät. En routad klient på andra sidan av en peer, eller en som är dold bakom NAT i ett annat prefix, klarar det inte, trots att paketet kom in på wg0, och ingen förfrågan syns i loggen.

SINGLE ändrar frågan. Den accepterar förfrågningar som kommer in på gränssnittet som namnges i dns.interface, med loopback inkluderat, och ignorerar källsubnätet. Det är läget som överlever en kedjad eller routad VPN-topologi. Sätt båda nycklarna tillsammans, för ett läge utan ett namngivet gränssnitt är inte en fullständig instruktion:

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

BIND ändrar socketen, och det har ett pris

BIND filtrerar inte en wildcard-socket; den binder port 53 endast till adresser som finns på det namngivna gränssnittet, så kärnan avvisar paket som kommer in någon annanstans. Den är strängare än SINGLE och inte en synonym till den. Priset visar sig vid start: om wg0 inte är uppe när FTL startar finns det kanske ingen adress att binda till, och resolvern kan köra utan lyssnare tills gränssnittet dyker upp och FTL startar om.

Välj BIND när du kontrollerar startordningen, till exempel en systemd-enhet ordnad efter WireGuard-gränssnittet, och när du vill att kärnan ska släppa vilsegna paket innan FTL ser dem. Välj SINGLE när tunneln kommer och går, eller när gränssnittet skapas av ett verktyg som startar efter FTL.

Brandväggen är den andra porten

Ett korrekt FTL-läge misslyckas ändå om värdens brandvägg släpper port 53 på wg0. Tillåt VPN-källintervallet för båda protokollen och håll internetsidan stängd. I nftables, med den befintliga input-kedjan i tabellen inet filter, ser reglerna ut så här:

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

Lägg till motsvarande IPv6-regler om tunneln bär IPv6, och sätt dem före kedjans drop-policy. Om värden använder ufw eller firewalld, uttryck samma matchning i den hanteraren i stället för att blanda verktyg. Vidarebefordra inte port 53 från internetroutern; klienterna bör nå resolverns VPN-adress genom tunneln.

Två vägar hålls åtskilda. Klienternas förfrågningar avslutas i FTL. FTL:s egna uppströmsuppslag går ut enligt värdens routingtabell, som kanske eller kanske inte använder tunneln, så en resolver som svarar men inte returnerar något användbart är ett uppströmsproblem. Webbadmin och API lyssnar på egna portar och behöver sin egen begränsning.

Verifiera svaret och avvisningen

Från en VPN-klient, fråga resolverns adress över båda protokollen: dig @10.90.0.1 example.com och dig +tcp @10.90.0.1 example.com. Kontrollera sedan frågeloggen i administrationsgränssnittet för att bekräfta att FTL registrerade förfrågan. En klient-timeout utan loggpost pekar på brandväggen eller gränssnittsfiltret; en loggpost utan svar pekar på uppströmsuppslag.

Testa den negativa vägen från en värd utanför VPN:et. dig @10.90.0.1 example.com bör times ut, och ss -lunp på resolvern bör inte visa port 53 bunden till en offentlig adress. Starta om tjänsten en gång, starta sedan om värden och bekräfta att resolvern fortfarande svarar när wg0 dyker upp igen. En förfrågan som bara fungerar till nästa omstart är inte en avslutad ändring.