Bakit binabalewala ng Pi-hole v6 ang mga DNS query mula sa mga WireGuard client

Tumanggap ang Pi-hole v6 ng DNS query sa port 53 at pagkatapos ay nagpapasya kung ang packet na dumating ay pinapayagang sagutin. Sa isang WireGuard host, ang ikalawang desisyong iyon ang karaniwang dahilan kung bakit nag-timeout ang client habang ang resolver ay mukhang maayos mula sa LAN. Bukas ang port, tumatakbo ang FTL, gayunpaman walang bumabalik mula sa 10.90.0.1. Tatlong bagay ang nag-uugnay bago lumabas ang isang sagot: dns.interface, dns.listeningMode at ang firewall sa harap ng dalawa.

Hindi nagpapasya ang nakikinig na socket kung sino ang makakakuha ng sagot

Binubuksan ng FTL ang UDP at TCP listeners sa port 53. Sa default na configuration ang socket ay madalas wildcard, kaya ss -lunp | grep :53 ay nagpapakita ng 0.0.0.0:53 at [::]:53 may serbisyo man sa mga VPN client o wala. Tumatanggap ang wildcard socket ng packet, pagkatapos ay inilalapat ng FTL ang mga tuntunin nito sa interface at source bago sumagot. Kaya't ang "nakikinig ang port" ay halos walang pinapatunayan tungkol sa isang tunnel client.

Basahin ang tumatakbong configuration sa halip na ang file na inaakala mong aktibo. pihole-FTL --config dns.interface at pihole-FTL --config dns.listeningMode ay nagpi-print ng mga epektibong halaga, at maaaring iba ang mga ito sa file ng host kapag isang container, environment variable o deployment manager ang nagmamay-ari ng setting. Ang Sanggunian sa configuration ng Pi-hole FTL ay naglilista ng mga mode at kung alin sa mga ito ang nakabatay sa interface.

Nagtatanong ang LOCAL kung aling subnet, nagtatanong ang SINGLE kung aling interface

Ang LOCAL, ang default, ay sumasagot sa mga query na ang source address ay kabilang sa isang subnet na naka-configure sa isa sa mga interface ng host. Ang simpleng wg0 na may 10.90.0.1/24 ay pumapasa sa pagsubok na iyon, dahil ang client sa 10.90.0.2 ay nasa loob ng subnet ng tunnel. Isang routed na client sa kabilang panig ng isang peer, o isang nakatago sa likod ng NAT sa ibang prefix, ay hindi pumapasa, kahit dumating ang packet sa wg0, at walang query na lumalabas sa log.

Binabago ng SINGLE ang tanong. Tumatanggap ito ng mga query na dumarating sa interface na pinangalanan sa dns.interface, kasama ang loopback, at binabalewala ang source subnet. Ito ang mode na nakakaligtas sa isang chained o routed na VPN topology. Itakda ang dalawang key nang magkasama, dahil ang mode na walang pinangalanang interface ay hindi kumpletong instruksiyon:

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

Binabago ng BIND ang socket, at may halaga iyon

Hindi sinasala ng BIND ang isang wildcard socket; ikinakabit nito ang port 53 lamang sa mga address na umiiral sa pinangalanang interface, kaya tinatanggihan ng kernel ang mga packet na dumarating sa ibang lugar. Mas mahigpit ito kaysa SINGLE at hindi ito kasingkahulugan nito. Lumalabas ang halaga sa boot: kung wala sa itaas ang wg0 kapag nagsisimula ang FTL, maaaring walang address na maikabit, at ang resolver ay maaaring tumakbo nang walang listener hanggang lumabas ang interface at mag-restart ang FTL.

Piliin ang BIND kapag kontrolado mo ang pagkakasunod-sunod ng pagsisimula, halimbawa isang systemd unit na inayos pagkatapos ng WireGuard interface, at kapag gusto mong itapon ng kernel ang mga ligaw na packet bago pa makita ng FTL ang mga ito. Piliin ang SINGLE kapag papasok at lalabas ang tunnel, o kapag ang interface ay ginawa ng isang tool na nagsisimula pagkatapos ng FTL.

Ang firewall ay ang ikalawang pintuan

Nabibigo pa rin ang tamang FTL mode kung itinatapon ng firewall ng host ang port 53 sa wg0. Payagan ang saklaw ng source ng VPN para sa dalawang protocol at panatilihing sarado ang panig ng internet. Sa nftables, kasama ang umiiral na input chain sa table na inet filter, ganito ang hitsura ng mga tuntunin:

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

Magdagdag ng tumutugmang mga tuntunin sa IPv6 kung nagdadala ng IPv6 ang tunnel, at ilagay ang mga ito bago ang drop policy ng chain. Kung gumagamit ang host ng ufw o firewalld, ipahayag ang parehong tugma sa manager na iyon sa halip na paghaluin ang mga tool. Huwag i-forward ang port 53 mula sa internet router; dapat maabot ng mga client ang VPN address ng resolver sa pamamagitan ng tunnel.

Dalawang landas ang nananatiling magkahiwalay. Nagtatapos ang mga query ng client sa FTL. Ang mga sariling upstream lookup ng FTL ay lumalabas ayon sa routing table ng host, na maaaring gumamit o hindi ng tunnel, kaya ang resolver na sumasagot pero walang ibinabalik na kapaki-pakinabang ay problema sa upstream. Ang web admin at API ay nakikinig sa sariling port at kailangan ng sariling paghihigpit.

I-verify ang sagot at ang pagtanggi

Mula sa isang VPN client, tanungin ang address ng resolver sa dalawang protocol: dig @10.90.0.1 example.com at dig +tcp @10.90.0.1 example.com. Pagkatapos ay tingnan ang query log sa admin interface upang kumpirmahin na naitala ng FTL ang query. Ang timeout ng client na walang entry sa log ay tumuturo sa firewall o sa interface filter; ang entry na walang sagot ay tumuturo sa upstream resolution.

Subukan ang negatibong landas mula sa isang host sa labas ng VPN. dig @10.90.0.1 example.com ay dapat mag-timeout, at ss -lunp sa resolver ay hindi dapat magpakita ng port 53 na nakakabit sa isang pampublikong address. I-restart ang serbisyo nang isang beses, pagkatapos i-reboot ang host at kumpirmahin na sumasagot pa rin ang resolver kapag muling lumitaw ang wg0. Ang query na gumagana lamang hanggang sa susunod na reboot ay hindi tapos na pagbabago.