Zakaj Pi-hole v6 ignorira poizvedbe DNS od odjemalcev WireGuarda

Pi-hole v6 prejme poizvedbo DNS na vratih 53 in nato odloči, ali je na prispeli paket dovoljeno odgovoriti. Na gostitelju WireGuard je ta druga odločitev običajno razlog, da odjemalec dobi časovno omejitev, medtem ko je razreševalnik videti zdrav z LAN. Vrata so odprta, FTL deluje, pa vendar se z 10.90.0.1 ne vrne nič. Preden odgovor odide, medsebojno delujejo tri stvari: dns.interface, dns.listeningMode in požarni zid pred obema.

Poslušajoča vtičnica ne odloča, kdo dobi odgovor

FTL odpre poslušalce UDP in TCP na vratih 53. V privzeti nastavitvi je vtičnica pogosto wildcard, zato ss -lunp | grep :53 prikazuje 0.0.0.0:53 in [::]:53 ne glede na to, ali se streže odjemalcem VPN. Vtičnica wildcard paket sprejme, nato FTL pred odgovorom uporabi svoja pravila vmesnika in vira. Zato fraza „vrata poslušajo“ o odjemalcu tunela dokaže zelo malo.

Berite delujočo nastavitev, ne datoteke, za katero menite, da je dejavna. pihole-FTL --config dns.interface in pihole-FTL --config dns.listeningMode izpišeta dejanske vrednosti, ki se lahko razlikujejo od datoteke gostitelja, kadar nastavitev upravlja vsebnik, okoljska spremenljivka ali upravitelj uvajanja. Referenca za nastavitev Pi-hole FTL našteje načine in katerega od njih temelji na vmesniku.

LOCAL sprašuje, katera podomrežja, SINGLE sprašuje, kateri vmesnik

LOCAL, privzeti način, odgovarja na poizvedbe, katerih naslov vira pripada podomrežju, nastavljenemu na enem od vmesnikov gostitelja. Preprost wg0 z 10.90.0.1/24 prestane ta preizkus, ker odjemalec na 10.90.0.2 sedi znotraj podomrežja tunela. Usmerjeni odjemalec na drugi strani partnerja, ali odjemalec, skrit za NAT v drugi predponi, ga ne prestane, čeprav je paket prispel na wg0, in v dnevniku se ne pojavi nobena poizvedba.

SINGLE spremeni vprašanje. Sprejme poizvedbe, ki prispejo na vmesnik, naveden v dns.interface, vključno z loopback, in ne upošteva izvornega podomrežja. To je način, ki preživi verižno ali usmerjeno topologijo VPN. Nastavite oba ključa skupaj, ker način brez navedenega vmesnika ni popolno navodilo:

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

BIND spremeni vtičnico, in to ima ceno

BIND ne filtrira vtičnice wildcard; vrata 53 veže le na naslove, ki obstajajo na navedenem vmesniku, zato jedro zavrne pakete, ki prispejo drugam. Je strožji od SINGLE in ni njegov sinonim. Cena se pokaže ob zagonu: če wg0 ni dvignjen, ko FTL starta, morda ni naslova za vezavo in razreševalnik lahko deluje brez poslušalca, dokler se vmesnik ne pojavi in FTL se znova ne zažene.

Izberite BIND, ko nadzorujete vrstni red zagona, na primer enoto systemd, razvrščeno za vmesnikom WireGuard, in ko želite, da jedro zavrže zablodele pakete, preden jih FTL vidi. Izberite SINGLE, ko tunel prihaja in odhaja, ali ko vmesnik ustvari orodje, ki starta po FTL.

Požarni zid so druga vrata

Pravilen način FTL vseeno ne uspe, če požarni zid gostitelja zavrže vrata 53 na wg0. Dovolite obseg virov VPN za oba protokola in pustite internetno stran zaprto. V nftables, z obstoječo verigo input v tabeli inet filter, so pravila videti tako:

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

Dodajte ustrezna pravila IPv6, če tunel prenaša IPv6, in jih postavite pred politiko zavračanja verige. Če gostitelj uporablja ufw ali firewalld, izrazite isto ujemanje v tem upravitelju, namesto da mešate orodja. Ne posredujte vrat 53 z internetnega usmerjevalnika; odjemalci morajo naslov VPN razreševalnika doseči skozi tunel.

Dve poti ostaneta ločeni. Poizvedbe odjemalcev se končajo na FTL. Lastne poizvedbe FTL navzgor gredo po usmerjevalni tabeli gostitelja, ki lahko tunel uporablja ali ne, zato je razreševalnik, ki odgovori, a ne vrne nič koristnega, problem navzgor. Spletna administracija in API poslušata na svojih vratih in potrebujeta svojo omejitev.

Preverite odgovor in zavrnitev

Z odjemalca VPN vprašajte naslov razreševalnika po obeh protokolih: dig @10.90.0.1 example.com in dig +tcp @10.90.0.1 example.com. Nato preverite dnevnik poizvedb v upravljalnem vmesniku, da potrdite, da je FTL poizvedbo zabeležil. Časovna omejitev odjemalca brez vnosa v dnevniku kaže na požarni zid ali filter vmesnika; vnos brez odgovora kaže na razreševanje navzgor.

Preizkusite negativno pot z gostitelja zunaj VPN. dig @10.90.0.1 example.com bi moralo poteči, in ss -lunp na razreševalniku ne bi smel prikazati vrat 53 vezanih na javni naslov. Enkrat znova zaženite storitev, nato znova zaženite gostitelja in potrdite, da razreševalnik še vedno odgovarja, ko se wg0 znova pojavi. Poizvedba, ki deluje le do naslednjega zagona, ni dokončana sprememba.