Kvifor Pi-hole v6 ignorerer DNS-spurnader frå WireGuard-klientar

Pi-hole v6 tek imot ei DNS-spurnad på port 53 og avgjer deretter om pakken som kom inn, kan svarast på. På ein WireGuard-vert er den andre avgjerda vanlegvis grunnen til at ein klient får tidsavbrot medan resolvaren ser sunn ut frå LAN-et. Porten er open, FTL køyrer, og likevel kjem ingenting tilbake frå 10.90.0.1. Tre ting verkar saman før eit svar forlet systemet: dns.interface, dns.listeningMode og brannmuren framfor båe.

Lyttesokkelen avgjer ikkje kven som får eit svar

FTL opnar UDP- og TCP-lyttarar på port 53. I standardoppsettet er sokkelen ofte wildcard, så ss -lunp | grep :53 viser 0.0.0.0:53 og [::]:53 uansett om VPN-klientar vert betente eller ikkje. Ein wildcard-sokkel tek imot pakken, og deretter nyttar FTL grensesnitt- og kjeldereglane sine før han svarar. Difor beviser «porten lyttar» svært lite om ein tunnelklient.

Les den køyrande konfigurasjonen i staden for fila du trur er aktiv. pihole-FTL --config dns.interface og pihole-FTL --config dns.listeningMode skriv ut dei faktiske verdiane, og dei kan avvike frå vertsfila når ein container, miljøvariabel eller distribusjonshandsamar eig innstillinga. Pi-hole FTL-konfigurasjonsreferansen viser modusane og kva av dei som er avhengig av grensesnittet.

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

LOCAL, standardmodusen, svarar på spurnader der kjeldeadressa høyrer til eit subnett som er konfigurert på eit av grensesnitta til verten. Ein enkel wg0 med 10.90.0.1/24 står på den testen, fordi klienten på 10.90.0.2 sit inne i subnettet til tunnelen. Ein ruta klient på den andre sida av ein peer, eller ein som er skjult bak NAT i eit anna prefiks, står ikkje på han, sjølv om pakken kom inn på wg0, og det viser seg inga spurnad i loggen.

SINGLE endrar spørsmålet. Han godtek spurnader som kjem inn på grensesnittet som er namngjeve i dns.interface, med loopback inkludert, og ignorerer kjeldessubnettet. Det er modusen som overlever ein kjed-a eller ruta VPN-topologi. Set båe nøklane saman, for ein modus utan eit namngjeve grensesnitt er ikkje ei fullstendig instruks:

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

BIND endrar sokkelen, og det har ein pris

BIND filtrerer ikkje ein wildcard-sokkel; han bind port 53 berre til adresser som finst på det namngjevne grensesnittet, slik at kjernen avviser pakkar som kjem inn andre stader. Han er strengare enn SINGLE og ikkje eit synonym for han. Prisen viser seg ved oppstart: om wg0 ikkje er oppe når FTL startar, er det kanskje inga adresse å binde til, og resolvaren kan køyre utan lyttar til grensesnittet dukkar opp og FTL startar på nytt.

Vel BIND når du styrer oppstartsrekkjefølgja, til dømes ein systemd-eining ordna etter WireGuard-grensesnittet, og når du vil at kjernen skal forkaste villfarne pakkar før FTL ser dei. Vel SINGLE når tunnelen kjem og går, eller når grensesnittet vert laga av eit verktøy som startar etter FTL.

Brannmuren er den andre porten

Ein korrekt FTL-modus feilar likevel om brannmuren til verten forkastar port 53 på wg0. Tillat VPN-kjeldeområdet for båe protokollane og hald internett-sida stengd. I nftables, med den eksisterande input-kjeda i tabellen inet filter, ser reglane 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 tilsvarande IPv6-reglar om tunnelen ber IPv6, og set dei før drop-policyen til kjeda. Om verten nyttar ufw eller firewalld, uttrykk same treffet i den handsamaren i staden for å blande verktøy. Ikkje videresend port 53 frå internett-rutaren; klientane bør nå VPN-adressa til resolvaren gjennom tunnelen.

To vegar vert haldne fråskilde. Spurnadene til klientane endar i FTL. FTL sine eigne oppstraums oppslag går ut etter rutetabellen til verten, som kanskje eller kanskje ikkje nyttar tunnelen, så ein resolvar som svarar men ikkje returnerer noko nyttig, er eit oppstraumsproblem. Netadmin og API lyttar på eigne portar og treng si eiga avgrensing.

Stadfest svaret og avvisinga

Frå ein VPN-klient, spør adressa til resolvaren over båe protokollane: dig @10.90.0.1 example.com og dig +tcp @10.90.0.1 example.com. Sjå deretter på spurnadsloggen i administrasjonsgrensesnittet for å stadfeste at FTL registrerte spurnaden. Tidsavbrot hos klienten utan loggoppføring peikar på brannmuren eller grensesnittfiltret; ei loggoppføring utan svar peikar på oppstraums oppslag.

Test den negative vegen frå ein vert utanfor VPN-et. dig @10.90.0.1 example.com bør gå ut på tid, og ss -lunp på resolvaren bør ikkje vise port 53 bunde til ei offentleg adresse. Start tenesta på nytt éin gong, start deretter verten på nytt og stadfest at resolvaren framleis svarar når wg0 dukkar opp att. Ei spurnad som berre verkar til neste omstart, er ikkje ei fullført endring.