Hvorfor Pi-hole v6 ignorerer DNS-spørringer fra WireGuard-klienter

Pi-hole v6 mottar en DNS-spørring på port 53 og avgjør deretter om pakken som kom inn, kan besvares. På en WireGuard-vert er den andre avgjørelsen vanligvis grunnen til at en klient får tidsavbrudd mens resolveren ser sunn ut fra LAN-et. Porten er åpen, FTL kjører, og likevel kommer ingenting tilbake fra 10.90.0.1. Tre ting samvirker før et svar forlater systemet: dns.interface, dns.listeningMode og brannmuren foran begge.

Lyttesocketen avgjør ikke hvem som får et svar

FTL åpner UDP- og TCP-lyttere på port 53. I standardoppsettet er socketen ofte wildcard, så ss -lunp | grep :53 viser 0.0.0.0:53 og [::]:53 uansett om VPN-klienter betjenes eller ikke. En wildcard-socket godtar pakken, og deretter bruker FTL grensesnitt- og kildereglene sine før den svarer. Derfor beviser «porten lytter» svært lite om en tunnelklient.

Les den kjørende konfigurasjonen i stedet for filen du tror er aktiv. pihole-FTL --config dns.interface og pihole-FTL --config dns.listeningMode skriver ut de faktiske verdiene, og de kan avvike fra vertens fil når en container, miljøvariabel eller distribusjonsbehandler eier innstillingen. Pi-hole FTL-konfigurasjonsreferansen viser modusene og hvilken av dem som avhenger av grensesnittet.

LOCAL spør hvilket subnett, SINGLE spør hvilket grensesnitt

LOCAL, standardmodusen, svarer på spørringer der kildeadressen tilhører et subnett som er konfigurert på et av vertens grensesnitt. En enkel wg0 med 10.90.0.1/24 består den testen, fordi klienten på 10.90.0.2 sitter inne i tunnelens subnett. En rutet klient på den andre siden av en peer, eller en som er skjult bak NAT i et annet prefiks, består den ikke, selv om pakken kom inn på wg0, og det vises ingen spørring i loggen.

SINGLE endrer spørsmålet. Den godtar spørringer som kommer inn på grensesnittet som er navngitt i dns.interface, med loopback inkludert, og ignorerer kildesubnettet. Det er modusen som overlever en kjedet eller rutet VPN-topologi. Sett begge nøklene sammen, for en modus uten et navngitt grensesnitt er ikke en fullstendig instruks:

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

BIND endrer socketen, og det har en pris

BIND filtrerer ikke en wildcard-socket; den binder port 53 bare til adresser som finnes på det navngitte grensesnittet, slik at kjernen avviser pakker som kommer inn andre steder. Den er strengere enn SINGLE og ikke et synonym for den. Prisen viser seg ved oppstart: hvis wg0 ikke er oppe når FTL starter, er det kanskje ingen adresse å binde til, og resolveren kan kjøre uten lytter til grensesnittet dukker opp og FTL starter på nytt.

Velg BIND når du kontrollerer oppstartsrekkefølgen, for eksempel en systemd-enhet ordnet etter WireGuard-grensesnittet, og når du vil at kjernen skal forkaste villfarne pakker før FTL ser dem. Velg SINGLE når tunnelen kommer og går, eller når grensesnittet opprettes av et verktøy som starter etter FTL.

Brannmuren er den andre porten

En korrekt FTL-modus feiler likevel hvis vertens brannmur forkaster port 53 på wg0. Tillat VPN-kildeområdet for begge protokollene og hold internett-siden lukket. I nftables, med den eksisterende input-kjeden i tabellen inet filter, ser reglene slik ut:

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

Legg til tilsvarende IPv6-regler hvis tunnelen bærer IPv6, og sett dem før kjedens drop-policy. Hvis verten bruker ufw eller firewalld, uttrykk samme treff i den behandleren i stedet for å blande verktøy. Ikke videresend port 53 fra internett-ruteren; klientene bør nå resolverens VPN-adresse gjennom tunnelen.

To veier holdes atskilt. Klientenes spørringer avsluttes i FTL. FTLs egne oppstrøms oppslag går ut etter vertens rutetabell, som kanskje eller kanskje ikke bruker tunnelen, så en resolver som svarer men ikke returnerer noe nyttig, er et oppstrømsproblem. Netadmin og API lytter på egne porter og trenger sin egen begrensning.

Bekreft svaret og avvisningen

Fra en VPN-klient, spør resolverens adresse over begge protokollene: dig @10.90.0.1 example.com og dig +tcp @10.90.0.1 example.com. Se deretter på spørringsloggen i administrasjonsgrensesnittet for å bekrefte at FTL registrerte spørringen. Tidsavbrudd hos klienten uten loggoppføring peker på brannmuren eller grensesnittfilteret; en loggoppføring uten svar peker på oppstrøms oppslag.

Test den negative veien fra en vert utenfor VPN-et. dig @10.90.0.1 example.com bør time ut, og ss -lunp på resolveren bør ikke vise port 53 bundet til en offentlig adresse. Start tjenesten på nytt én gang, start deretter verten på nytt og bekreft at resolveren fortsatt svarer når wg0 dukker opp igjen. En spørring som bare virker til neste omstart, er ikke en fullført endring.