Hindi hinaharang ng Pi-hole ang mga ad pagkatapos kumonekta ang VPN: limang pagsusuri

Lumalabas pa rin ang mga ad sa isang kliyente, nag-uulat ang Pi-hole na malusog ito, at aktibo ang tunnel, kaya ang likas na ugali ay i-ruta ang trapik ng kliyenteng iyon sa pamamagitan ng Pi. Iyon ang maling liko. Kailangan ng pagsasala ang mga tanong, hindi ang mga pakete, at ang kliyenteng ang mga query ay pumupunta sa resolver ng provider ay nananatiling hindi nasasala kahit saan dumaloy ang trapik nito. Dumaan sa listahang ito nang sunod-sunod at huminto sa unang hakbang na nabibigo, dahil walang maibibigay na impormasyon ang susunod na hakbang habang sira ang nauna.

1. Basahin ang resolver na aktwal na ginagamit ng kliyente

Tanungin ang kliyente, hindi ang router. Sa Linux, ipinapakita ng resolvectl status ang mga DNS server bawat link at kung aling link ang nananalo; ang /etc/resolv.conf lamang ay karaniwang stub na tumuturo sa 127.0.0.53. Sa Windows, inililista ng ipconfig /all ang mga server na ibinigay ng DHCP bawat adapter, at sa macOS ipinapakita ng scutil --dns ang parehong bagay bawat saklaw. Kung ang sagot ay hindi address ng Pi-hole, mayroon kang problema sa pagtatalaga at ang hakbang 2 ang lugar kung nasaan ito.

Dalawang bagay ang tumatalo sa system resolver kahit maayos itong nakatakda. Ang mga browser na may sariling secure DNS (ang “Use secure DNS” ng Chrome, ang network.trr.mode ng Firefox) ay nagpapadala ng query sa HTTPS sa isang pampublikong resolver at hindi kailanman binubuksan ang port 53. At ang isang VPN client sa mismong kliyente ay maaaring mag-install ng DNS server sa interface ng tunnel nito na may routing domain na ~., na ginagawang awtoritatibo ang link na iyon para sa bawat pangalan.

Subukan ang landas na dinadaanan ng mga aplikasyon, hindi ang landas na dinadaanan ng tool sa pag-debug. Ipinapakita ng resolvectl query example.com kung aling link ang sumagot, at ang getent hosts example.com ay dumadaan sa parehong NSS na landas ng isang aplikasyon; sa macOS, binabasa ng dscacheutil -q host -a name example.com ang mga resolver bawat saklaw na inililista ng scutil --dns. Ang hubad na dig ay hindi ito ginagawa: binabasa nito ang /etc/resolv.conf at nilalaktawan ang pagpili bawat link, kaya makakasagot ito mula sa Pi-hole habang ginagamit ng bawat aplikasyon ang itinulak na resolver, at iyon mismo ang pagkabigong umiiral ang listahang ito para mahuli. Itabi ang dig @192.168.1.53 para sa pagsubok ng isang partikular na server.

2. Kumpirmahin kung sino ang namamahagi ng sagot

Ang pagtatalaga ay nagmumula sa kahit anong sumasagot sa DHCP. Sa dnsmasq ito ay isang linya, dhcp-option=6,192.168.1.53; sa web UI ng router ito ang field ng DNS sa seksyong DHCP ng LAN. Kailangang mag-renew ng mga kliyente bago nila ito makita. Ang device na bukas nang ilang araw ay hawak pa rin ang lumang lease, at ang device na may manu-manong tinipa na resolver ay hinahawakan ito nang permanente. Mag-renew sa isang test client sa halip na ipagpalagay ang pagkalat.

Ang IPv6 ang kalahating madalas makaligtaan. Ang mga anunsyo ng router ay maaaring magdala ng sarili nilang DNS server (RDNSS), at sa OpenWrt ito ang opsyong ra_dns ng odhcpd; ang kliyenteng mas gusto ang IPv6 ay gumagamit ng server na iyon habang ang opsyong DHCPv4 na kakaset mo lang ay nananatiling hindi ginagamit. Kung hindi ka pa handang maglingkod ng DNS sa IPv6, burahin lamang ang anunsyo ng DNS: ra_dns sa odhcpd, o ang opsyong RDNSS sa kahit anong sumasagot sa mga anunsyo ng router. Ang pagpatay sa buong anunsyo ay nag-aalis din ng IPv6 addressing sa LAN, na mas malaking pagbabago kaysa sa intensyon mo, samantalang ang pagbura lamang ng opsyong DNS ay nagpapanatili ng addressing at ginagawang nakikita ang kulang na RDNSS sa isang packet capture.

3. Patunayan na nakakarating ang query sa Pi-hole

Ang query mula sa Pi ay walang pinapatunayan tungkol sa landas ng network. Patakbuhin ito mula sa kliyente at basahin ang response code:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Ang timeout ay tumuturo sa pagsasala o sa isang ruta; ang REFUSED ay tumuturo sa isang access rule; ang SERVFAIL ay tumuturo sa upstream resolver sa likod ng Pi-hole; ang tamang sagot na hindi kailanman lumalabas sa query log ay nangangahulugang iba ang tinanong ng kliyente. Suriin ang UDP at TCP 53, dahil ang malalaking sagot at ilang resolver ay bumabalik sa TCP, at i-publish ang pareho kapag tumatakbo ang Pi-hole sa isang container. Ang mapping na sumasaklaw lamang sa UDP ay gumagawa ng paminsan-minsang pagkabigo na mukhang pagkawala ng packet.

Pagkatapos ay nagpapasya ang listening mode ng Pi-hole kung sasagot ba ito talaga. Sa local-only mode, binabalewala ng dnsmasq ang mga query mula sa mga source na wala sa direktang konektadong subnet, at ganyan talaga ang hitsura ng kliyenteng nasa likod ng ibang router o dumarating sa pamamagitan ng tunnel: nauubos ang oras ng kliyente at hindi kailanman nakakarating ang query sa log. Ang query na lumalabas pa rin bilang REFUSED ay tinanggihan ng access list o ng firewall rule. Ang pagpayag sa lahat ng pinagmulan ang karaniwang lunas, kasama ng firewall rule na nililimitahan ang port 53 sa sarili mong mga subnet.

4. Suriin kung pinalitan o nilamon ng tunnel ang sagot

Ito ang kaso kung saan nagtatago ang dalawang sintomas. Kapag ang router mismo ay isang VPN client, ang itinulak na opsyong DNS ay maaaring mangibabaw sa setting ng LAN sa sandaling umangat ang tunnel: itinutulak ng mga OpenVPN server ang dhcp-option DNS, at may sariling DNS entry ang mga WireGuard profile. Basahin ang epektibong resolver ng router habang nakataas ang tunnel, hindi bago, at balewalain ang sinasabi ng pahina ng LAN.

Ang isa pang depekto ay abot, hindi pagpapalit. Kung kasama sa pinapayagang prefix ng tunnel ang iyong subnet ng LAN, may ruta ang router na nagpapadala ng mga query para sa 192.168.1.53 papasok sa tunnel, at walang ruta pabalik ang kabilang side: nauubos ang oras ng mga query kahit malusog ang tunnel. Ang kabaligtaran ang nangyayari kapag ang Pi-hole ay nasa subnet na hindi dinadala ng tunnel. Ihambing ang address sa mga pinapayagang prefix ng tunnel at sa routing table ng router bago muling hawakan ang DNS.

Pumili ng isang lunas, hindi dalawa. Alinman sa ilayo ang tunnel sa DNS — gamit ang pull-filter ignore “dhcp-option DNS” sa OpenVPN at walang prefix ng LAN sa AllowedIPs sa WireGuard —, o tanggapin ang itinulak na resolver at isuko ang lokal na pagsasala para sa mga kliyenteng nasa likod ng router na iyon. Anuman ang piliin mo, isulat ito sa tabi ng profile, dahil bubaligtarin ito nang aksidente ng susunod na taong mag-e-edit nito.

5. Ulitin ang pagsubok pagkatapos ng muling pagkonekta

Mag-query mula sa isang kliyente, kumpirmahin na lumalabas ang kliyenteng iyon sa log ng Pi-hole, pagkatapos ay i-resolve ang isang domain na dapat harangin at tingnan kung ang sagot na pagharang ang nakukuha mo sa halip na ang tunay. Muling ikonekta ang tunnel at patakbuhin ang parehong dalawang query, dahil ang setting ng resolver na tumatagal lamang hanggang sa susunod na koneksyon ay ang karaniwang resulta ng lunas na inilapat sa maling layer.

Mag-iwan ng pangalawang landas ng resolver na hindi nakadepende sa tunnel, para ang pagpalya ng Pi-hole ay bumaba sa pagba-browse na walang pagsasala sa halip na walang pagba-browse. Panatilihin ang dating mga halaga ng DHCP at resolver hanggang makapasa ang pagsubok nang dalawang beses; ang pagbabagong sumisira sa internet ng sambahayan sa oras ng hapunan ay mas mahirap i-debug kaysa sa isang maaari mong ibalik sa loob ng isang minuto.