Hvorfor Pi-hole v6 ignorerer DNS-forespørgsler fra WireGuard-klienter

Pi-hole v6 modtager en DNS-forespørgsel på port 53 og afgør derefter, om pakken, der ankom, må besvares. På en WireGuard-vært er den anden afgørelse normalt grunden til, at en klient får timeout, mens resolveren ser sund ud fra LAN’et. Porten er åben, FTL kører, og alligevel kommer der intet tilbage fra 10.90.0.1. Tre ting spiller sammen, før et svar forlader systemet: dns.interface, dns.listeningMode og firewallett foran begge.

Lytte-socket’en afgør ikke, hvem der får et svar

FTL åbner UDP- og TCP-lyttere på port 53. I standardkonfigurationen er socket’en ofte wildcard, så ss -lunp | grep :53 viser 0.0.0.0:53 og [::]:53, uanset om VPN-klienter betjenes. En wildcard-socket accepterer pakken, og derefter anvender FTL sine grænseflade- og kilderegler, før den svarer. Derfor beviser "porten lytter" meget lidt om en tunnelklient.

Læs den kørende konfiguration i stedet for den fil, du tror er aktiv. pihole-FTL --config dns.interface og pihole-FTL --config dns.listeningMode udskriver de effektive værdier, og de kan afvige fra værtens fil, når en container, en miljøvariabel eller en udrulningsmanager ejer indstillingen. Pi-hole FTL-konfigurationsreference viser tilstandene og hvilken af dem der afhænger af grænsefladen.

LOCAL spørger hvilket subnet, SINGLE spørger hvilken grænseflade

LOCAL, standardtilstanden, besvarer forespørgsler, hvis kildeadresse tilhører et subnet, der er konfigureret på en af værtens grænseflader. En simpel wg0 med 10.90.0.1/24 består den test, fordi klienten på 10.90.0.2 sidder inde i tunnel-subnettet. En rutet klient på den anden side af en peer, eller en der er skjult bag NAT i et andet præfiks, består den ikke, selvom pakken ankom på wg0, og der vises ingen forespørgsel i loggen.

SINGLE ændrer spørgsmålet. Den accepterer forespørgsler, der ankommer på grænsefladen, der er navngivet i dns.interface, med loopback inkluderet, og ignorerer kildesubnettet. Det er tilstanden, der overlever en kædet eller rutet VPN-topologi. Sæt begge nøgler sammen, for en tilstand uden en navngivet grænseflade er ikke en fuldstændig instruks:

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

BIND ændrer socket’en, og det har en pris

BIND filtrerer ikke en wildcard-socket; den binder port 53 kun til adresser, der findes på den navngivne grænseflade, så kernen afviser pakker, der ankommer andre steder. Den er strengere end SINGLE og ikke et synonym for den. Prisen viser sig ved opstart: hvis wg0 ikke er oppe, når FTL starter, er der måske ingen adresse at binde til, og resolveren kan køre uden en lytter, indtil grænsefladen dukker op, og FTL genstarter.

Vælg BIND, når du styrer opstartsrækkefølgen, for eksempel en systemd-unit ordnet efter WireGuard-grænsefladen, og når du vil have kernen til at droppe vildfarne pakker, før FTL ser dem. Vælg SINGLE, når tunnelen kommer og går, eller når grænsefladen oprettes af et værktøj, der starter efter FTL.

Firewallett er den anden port

En korrekt FTL-tilstand fejler stadig, hvis værtens firewall dropper port 53 på wg0. Tillad VPN-kildeområdet for begge protokoller, og hold internetsiden lukket. I nftables, med den eksisterende input-kæde i inet filter-tabellen, ser reglerne sådan ud:

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

Tilføj tilsvarende IPv6-regler, hvis tunnelen bærer IPv6, og sæt dem før kædens drop-politik. Hvis værten bruger ufw eller firewalld, udtryk den samme matchning i den manager i stedet for at blande værktøjer. Videresend ikke port 53 fra internetrouteren; klienter bør nå resolverens VPN-adresse gennem tunnelen.

To veje forbliver adskilte. Klientforespørgsler ender ved FTL. FTL’s egne upstream-opslag forlader systemet efter værtens routingtabel, som måske eller måske ikke bruger tunnelen, så en resolver, der svarer, men ikke returnerer noget brugbart, er et upstream-problem. Webadministratoren og API’et lytter på deres egne porte og har brug for deres egen begrænsning.

Bekræft svaret og afvisningen

Fra en VPN-klient: forespørg resolverens adresse over begge protokoller: dig @10.90.0.1 example.com og dig +tcp @10.90.0.1 example.com. Kontrollér derefter forespørgselsloggen i administrationsgrænsefladen for at bekræfte, at FTL registrerede forespørgslen. En klient-timeout uden logpost peger på firewallett eller grænsefladefilteret; en logpost uden svar peger på upstream-opslag.

Test den negative vej fra en vært uden for VPN’et. dig @10.90.0.1 example.com bør time out, og ss -lunp på resolveren bør ikke vise port 53 bundet til en offentlig adresse. Genstart tjenesten én gang, genstart derefter værten og bekræft, at resolveren stadig svarer, efter wg0 dukker op igen. En forespørgsel, der kun virker indtil næste genstart, er ikke en færdig ændring.