Kial Pi-hole v6 ignoras DNS-demandojn de WireGuard-klientoj

Pi-hole v6 ricevas DNS-demandon sur pordo 53 kaj poste decidas, ĉu la alveninta paketo rajtas esti respondita. Sur WireGuard-gastiganto tiu dua decido kutime estas la kialo, kial kliento ricevas tempolimon dum la solvilo aspektas sana el la LAN. La pordo estas malfermita, FTL funkcias, tamen nenio revenas de 10.90.0.1. Tri aferoj interagas antaŭ ol respondo foriras: dns.interface, dns.listeningMode kaj la fajroŝirmilo antaŭ ambaŭ.

La aŭskulta ingo ne decidas, kiu ricevas respondon

FTL malfermas UDP- kaj TCP-aŭskultantojn sur pordo 53. En la defaŭlta agordo la ingo ofte estas wildcard, do ss -lunp | grep :53 montras 0.0.0.0:53 kaj [::]:53 sendepende de tio, ĉu VPN-klientoj estas servataj. Wildcard-ingo akceptas la paketon, poste FTL aplikas siajn regulojn pri interfaco kaj fonto antaŭ ol respondi. Tial "la pordo aŭskultas" pruvas tre malmulte pri tunela kliento.

Legu la funkciantan agordon anstataŭ la dosieron, kiun vi kredas aktiva. pihole-FTL --config dns.interface kaj pihole-FTL --config dns.listeningMode presas la efektivajn valorojn, kaj ili povas diferenci de la dosiero de la gastiganto kiam ujo, medivariablo aŭ deploja administrilo posedas la agordon. La Referenco pri agordo de Pi-hole FTL listigas la reĝimojn kaj kiun el ili dependas de la interfaco.

LOCAL demandas kiun subreton, SINGLE demandas kiun interfacon

LOCAL, la defaŭlto, respondas demandojn kies fonta adreso apartenas al subreto agordita sur unu el la interfacoj de la gastiganto. Simpla wg0 kun 10.90.0.1/24 trapasas tiun teston, ĉar la kliento ĉe 10.90.0.2 sidas ene de la tunela subreto. Kliento kun itinero sur la malproksima flanko de samtavolano, aŭ unu kaŝita malantaŭ NAT en malsama prefikso, ne trapasas ĝin kvankam la paketo alvenis sur wg0, kaj neniu demando aperas en la protokolo.

SINGLE ŝanĝas la demandon. Ĝi akceptas demandojn, kiuj alvenas sur la interfaco nomita en dns.interface, kun loopback inkluzivita, kaj ignoras la fontan subreton. Tiu estas la reĝimo, kiu postvivas ĉenan aŭ itinaran VPN-topologion. Agordu ambaŭ ŝlosilojn kune, ĉar reĝimo sen nomita interfaco ne estas kompleta instrukcio:

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

BIND ŝanĝas la ingon, kaj tio havas koston

BIND ne filtradas wildcard-ingon; ĝi ligas pordon 53 nur al adresoj, kiuj ekzistas sur la nomita interfaco, do la kerno rifuzas paketojn, kiuj alvenas aliloke. Ĝi estas pli strikta ol SINGLE kaj ne estas ĝia sinonimo. La kosto aperas ĉe ŝarĝo: se wg0 ne estas aktiva kiam FTL komenciĝas, eble ne estas adreso por ligi, kaj la solvilo povas funkcii sen aŭskultanto ĝis la interfaco aperos kaj FTL restartos.

Elektu BIND kiam vi regas la startordon, ekzemple systemd-unuo ordigita post la WireGuard-interfaco, kaj kiam vi volas, ke la kerno forĵetu erarvagajn paketojn antaŭ ol FTL vidas ilin. Elektu SINGLE kiam la tunelo venas kaj foriras, aŭ kiam la interfacon kreas ilo, kiu startas post FTL.

La fajroŝirmilo estas la dua pordego

Ĝusta FTL-reĝimo ankoraŭ malsukcesas se la fajroŝirmilo de la gastiganto forĵetas pordon 53 sur wg0. Permesu la fontan intervalon de VPN por ambaŭ protokoloj kaj tenu la interretan flankon fermita. En nftables, kun la ekzistanta input-ĉeno en la tabelo inet filter, la reguloj aspektas tiel:

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

Aldonu kongruajn IPv6-regulojn se la tunelo portas IPv6, kaj metu ilin antaŭ la forĵeta politiko de la ĉeno. Se la gastiganto uzas ufw aŭ firewalld, esprimu la saman kongruon en tiu administrilo anstataŭ miksi ilojn. Ne plusendu pordon 53 de la interreta enkursigilo; klientoj devus atingi la VPN-adreson de la solvilo tra la tunelo.

Du vojoj restas apartaj. Klientaj demandoj finiĝas ĉe FTL. La propraj suprenfluaj serĉoj de FTL eliras laŭ la itinera tabelo de la gastiganto, kiu povas aŭ ne uzi la tunelon, do solvilo, kiu respondas sed redonas nenion utilan, estas suprenflua problemo. La reta administrado kaj API aŭskultas sur propraj pordoj kaj bezonas propran limigon.

Kontrolu la respondon kaj la rifuzon

De VPN-kliento, demandu la adreson de la solvilo per ambaŭ protokoloj: dig @10.90.0.1 example.com kaj dig +tcp @10.90.0.1 example.com. Poste kontrolu la demandoprotokolon en la administra interfaco por konfirmi, ke FTL registris la demandon. Tempolimo de kliento sen protokola ero montras al la fajroŝirmilo aŭ la interfaca filtrilo; ero sen respondo montras al suprenflua solvado.

Testu la negativan vojon de gastiganto ekster la VPN. dig @10.90.0.1 example.com devus finiĝi per tempolimo, kaj ss -lunp sur la solvilo devus ne montri pordon 53 ligitan al publika adreso. Restartigu la servon unufoje, poste restartigu la gastiganton kaj konfirmu, ke la solvilo ankoraŭ respondas post kiam wg0 reaperas. Demando, kiu funkcias nur ĝis la sekva restarto, ne estas finita ŝanĝo.