Kodėl Pi-hole v6 nepaiso WireGuard klientų DNS užklausų

Pi-hole v6 gauna DNS užklausą 53 prievade ir tada nusprendžia, ar atvykusiam paketui leidžiama atsakyti. WireGuard hoste šis antrasis sprendimas paprastai yra priežastis, kodėl klientas gauna skirtąjį laiką, nors resolveris iš LAN atrodo sveikas. Prievadas atidarytas, FTL veikia, vis tik niekas negrįžta iš 10.90.0.1. Trys dalykai sąveikauja prieš išsiunčiant atsakymą: dns.interface, dns.listeningMode ir ugniasienė prieš abu.

Klausymosi lizdas nenusprendžia, kas gaus atsakymą

FTL atidaro UDP ir TCP klausytojus 53 prievade. Numatytojoje konfigūracijoje lizdas dažnai būna wildcard, todėl ss -lunp | grep :53 rodo 0.0.0.0:53 ir [::]:53 nepriklausomai nuo to, ar VPN klientai aptarnaujami. Wildcard lizdas priima paketą, tada FTL prieš atsakydamas taiko savo sąsajos ir šaltinio taisykles. Todėl frazė „prievadas klausosi“ labai mažai įrodo apie tunelio klientą.

Skaitykite veikiančią konfigūraciją, o ne failą, kurį laikote aktyviu. pihole-FTL --config dns.interface ir pihole-FTL --config dns.listeningMode išspausdina faktines vertes, ir jos gali skirtis nuo hosto failo, kai konteineris, aplinkos kintamasis ar diegimo tvarkyklė valdo šį nustatymą. Pi-hole FTL konfigūracijos žinynas išvardija režimus ir kuris iš jų priklauso nuo sąsajos.

LOCAL klausia, kuris potinklis, SINGLE klausia, kuri sąsaja

LOCAL, numatytasis, atsako į užklausas, kurių šaltinio adresas priklauso potinkliui, sukonfigūruotam vienoje iš hosto sąsajų. Paprastas wg0 su 10.90.0.1/24 praeina šį testą, nes klientas 10.90.0.2 yra tunelio potinklyje. Maršrutizuotas klientas kitoje partnerio pusėje, arba kitame prefikse už NAT paslėptas klientas, jo nepraeina, nors paketas atvyko į wg0, ir žurnale nepasirodo nė viena užklausa.

SINGLE pakeičia klausimą. Jis priima užklausas, atvykstančias į sąsają, nurodytą dns.interface, įskaitant loopback, ir nepaiso šaltinio potinklio. Tai režimas, kuris išlaiko grandininę ar maršrutizuotą VPN topologiją. Nustatykite abu raktus kartu, nes režimas be nurodytos sąsajos nėra ištisa instrukcija:

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

BIND pakeičia lizdą, ir tai turi kainą

BIND nefiltruoja wildcard lizdo; jis susieja 53 prievadą tik su adresais, kurie egzistuoja nurodytoje sąsajoje, todėl branduolys atmeta paketus, atvykstančius kitur. Jis griežtesnis už SINGLE ir nėra jo sinonimas. Kaina pasimato paleidžiant: jei wg0 nepakelta, kai FTL startuoja, gali nebūti adreso susiejimui, ir resolveris gali veikti be klausytojo, kol sąsaja atsiras ir FTL persikraus.

Rinkitės BIND, kai kontroliuojate paleidimo tvarką, pavyzdžiui, systemd įrenginį, išdėstytą po WireGuard sąsajos, ir kai norite, kad branduolys išmestų paklydusius paketus prieš FTL juos pamatant. Rinkitės SINGLE, kai tunelis ateina ir išeina, arba kai sąsają sukuria įrankis, startuojantis po FTL.

Ugniasienė yra antrieji vartai

Teisingas FTL režimas vis tiek nepavyksta, jei hosto ugniasienė išmeta 53 prievadą wg0 sąsajoje. Leiskite VPN šaltinio diapazoną abiem protokolams ir laikykite interneto pusę uždarytą. nftables, su esama input grandine lentelėje inet filter, taisyklės atrodo taip:

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

Pridėkite atitinkamas IPv6 taisykles, jei tunelis perneša IPv6, ir įdėkite jas prieš grandinės drop politiką. Jei hostas naudoja ufw ar firewalld, išreikškite tą patį atitikimą tame tvarkyklėje, o ne maišykite įrankius. Neperadresuokite 53 prievado iš interneto maršrutizatoriaus; klientai turi pasiekti resolverio VPN adresą per tunelį.

Du keliai lieka atskiri. Klientų užklausos baigiasi FTL. Pačios FTL užklausos į aukštupį išeina pagal hosto maršrutizavimo lentelę, kuri gali naudoti tunelį arba ne, todėl resolveris, kuris atsako, bet negrąžina nieko naudingo, yra aukštupio problema. Žiniatinklio administravimas ir API klausosi savo prievaduose ir jiems reikia savo apribojimo.

Patikrinkite atsakymą ir atmetimą

Iš VPN kliento užklauskite resolverio adresą abiem protokolais: dig @10.90.0.1 example.com ir dig +tcp @10.90.0.1 example.com. Tada patikrinkite užklausų žurnalą administravimo sąsajoje, kad patvirtintumėte, jog FTL užklausą įrašė. Kliento skirtasis laikas be įrašo žurnale rodo ugniasienę arba sąsajos filtrą; įrašas be atsakymo rodo aukštupio sprendimą.

Išbandykite neigiamą kelią iš hosto už VPN ribų. dig @10.90.0.1 example.com turėtų baigtis skirtuoju laiku, o ss -lunp resolveryje neturėtų rodyti 53 prievado, susieto su viešu adresu. Kartą paleiskite paslaugą iš naujo, tada perkraukite hostą ir patvirtinkite, kad resolveris vis dar atsako, kai wg0 vėl pasirodo. Užklausa, kuri veikia tik iki kito perkrovimo, nėra užbaigtas pakeitimas.