Pi-hole blokket gjin advertinsjes nei't de VPN ferbynt: fiif kontrôles

Advertinsjes ferskine noch op in klant, Pi-hole meldt himsels sûn, en de tunnel is omheech, dus it ynstinkt is om it ferkear fan dy klant troch de Pi te stjoeren. Dat is de ferkearde bocht. Filtering hat de fragen nedich, net de pakketten, en in klant waans fragen nei de resolver fan de provider geane, bliuwt unfiltere, hokker kant it ferkear ek op giet. Wurkje dizze list yn folchoarder troch en stopje by de earste stap dy't misrint, want in lettere stap kin dy neat sizze wylst in ierdere ferkeard is.

1. Lês de resolver dy't de klant eins brûkt

Freegje de klant, net de router. Op Linux prints resolvectl status de DNS-tsjinners per keppeling en hokker keppeling wint; /etc/resolv.conf op himsels is meastentiids in stub dy't nei 127.0.0.53 wiist. Op Windows listet ipconfig /all de troch DHCP levere tsjinners per adapter, en op macOS lit scutil --dns itselde per berik sjen. As it antwurd net it adres fan Pi-hole is, hast in tawizingsprobleem en stap 2 is wêr't dat sit.

Twa dingen ferslaan de systeemresolver sels as dy goed ynsteld is. Ferkenners mei har eigen feilige DNS (de opsje “Use secure DNS” fan Chrome, network.trr.mode fan Firefox) stjoere fragen oer HTTPS nei in iepenbiere resolver en iepenje nea poarte 53. En in VPN-klant op de klant sels kin in DNS-tsjinner op syn tunnelinterface ynstallearje mei in rûtesdomein fan ~., wat dy keppeling foar elke namme gesachhawwend makket.

Test it paad dat applikaasjes nimme, net it paad dat in debug-ark nimt. resolvectl query example.com lit sjen hokker keppeling antwurde, en getent hosts example.com giet troch itselde NSS-paad as in applikaasje; op macOS lêst dscacheutil -q host -a name example.com de berikresolvers dy't scutil --dns listet. In bleate dig docht dat net: dy lêst /etc/resolv.conf en slacht de kar per keppeling oer, dus kin er fan Pi-hole antwurdzje wylst elke applikaasje de tafierde resolver brûkt, en dat is krekt it falen dêr't dizze list foar bestiet. Hâld dig @192.168.1.53 foar it testen fan ien spesifike tsjinner.

2. Befêstigje wa't it antwurd útdielt

It tawizen komt fan wat op DHCP antwurdet. Op dnsmasq is dat ien rigel, dhcp-option=6,192.168.1.53; yn 'e webinterface fan in router is it it DNS-fjild yn 'e LAN-DHCP-seksje. Klanten moatte fernije foar't se it sjogge. In apparaat dat dagen oan stiet hâldt noch de âlde lease, en in apparaat mei in hânmjittich typt resolver hâldt dy foar altyd. Fernij op in testklant ynstee fan te ferûnderstellen dat it trochkringt.

IPv6 is de helte dy't fergetten wurdt. Routeradvertinsjes kinne har eigen DNS-tsjinner drage (RDNSS), en op OpenWrt is dat de opsje ra_dns fan odhcpd; in klant dy't IPv6 foarkomt brûkt dy tsjinner wylst de DHCPv4-opsje dy't jo krekt ynstelden ûnbrûkt bliuwt. As jo net klear binne om IPv6-DNS te tsjinjen, wiskje dan allinnich de DNS-advertinsje: ra_dns yn odhcpd, of de RDNSS-opsje yn wat op routeradvertinsjes antwurdet. It hiele advertinsje útskeakelje hellet ek IPv6-adressearring fan 'e LAN ôf, wat in folle gruttere feroaring is as de bedoeling, wylst it wiskjen fan allinnich de DNS-opsje de adressearring yntakt hâldt en de ûntbrekkende RDNSS sichtber makket yn in pakketopname.

3. Bewiisje dat de fraach Pi-hole berikt

In fraach fan 'e Pi bewiist neat oer it netwurkpaad. Rin it fan 'e klant en lês de antwurdkoade:

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

In tiidferrin wiist op filtering of op in rûte; REFUSED wiist op in tagongsregel; SERVFAIL wiist op de upstream resolver efter Pi-hole; in korrekt antwurd dat nea yn it fraachloch ferskynt, betsjut dat de klant wat oars frege hat. Kontrolearje UDP en TCP 53, want grutte antwurden en guon resolvers falle werom op TCP, en publisearje beide as Pi-hole yn in kontener rint. In mapping dy't allinnich UDP dekt, produsearret ûnregelmjittige flaters dy't op pakketferlies lykje.

Dêrnei beslút de harkmodus fan Pi-hole oft er hielendal antwurdet. Yn 'e modus allinnich lokaal negearret dnsmasq fragen fan boarnen dy't net op in direkt oansletten subnet binne, en krekt sa sjocht in klant efter in oare router of ien dy't troch in tunnel komt derút: de klant rint ôf en de fraach berikt nea it loch. In fraach dy't dochs as REFUSED ferskynt, waard troch in tagongslist of in firewallregel wegere. Alle oarsprongen tastean is de gewoane oplossing, tegearre mei in firewallregel dy't poarte 53 ta dyn eigen subnets beheint.

4. Kontrolearje oft de tunnel it antwurd ferfongen of opslokt hat

Dat is it gefal dêr't beide symptomen har yn ferskûlje. As de router sels in VPN-klant is, kin in tafierde DNS-opsje de LAN-ynstelling oerskriuwe op it stuit dat de tunnel omheech komt: OpenVPN-tsjinners fiere dhcp-option DNS ta, en WireGuard-profylen drage har eigen DNS-ynfier. Lês de effektive resolver fan 'e router mei de tunnel omheech, net dêrfoar, en negearje wat de LAN-side bewissiget.

It oare mankemint is berikberens ynstee fan ferfanging. As de tastiene prefixen fan 'e tunnel dyn LAN-subnet omfetsje, hat de router in rûte dy't fragen foar 192.168.1.53 de tunnel yn stjoert, en de oare kant hat gjin rûte werom: fragen rinne ôf hoewol de tunnel sûn is. It omkearde bart as Pi-hole op in subnet sit dat de tunnel net draacht. Ferlykje it adres mei de tastiene prefixen fan 'e tunnel en de rûtetabel fan 'e router foar't jo DNS wer oanreitsje.

Kies ien oplossing ynstee fan beide. Hâld de tunnel of fan DNS ôf — mei pull-filter ignore “dhcp-option DNS” op OpenVPN en gjin LAN-prefix yn AllowedIPs op WireGuard —, of akseptearje de tafierde resolver en jou lokale filtering oan klanten efter dy router op. Hokker jo ek kieze, skriuw it njonken it profyl, want de folgjende persoan dy't it bewurkje sil it beslút oars by ûngelok omkeare.

5. Werhelje de test nei in werferbining

Freegje fan in klant, befêstigje dat dy klant yn it loch fan Pi-hole ferskynt, en los dan in domein op dat blokkearre wurde moat en kontrolearje dat jo it blokkearjende antwurd krije ynstee fan it echte. Ferbyn de tunnel wer en rin deselde twa fragen, want in resolverynstelling dy't allinnich oant de folgjende werferbining hâldt, is it gewoane resultaat fan in oplossing dy't op 'e ferkearde laach tapast is.

Lit in sekundêr resolverpaad efter dat net fan 'e tunnel ôfhinklik is, sadat in Pi-hole-ûnderbrekking degradearret nei unfiltere browse ynstee fan hielendal gjin browse. Hâld de eardere DHCP- en resolverwearden oant de test twa kear slagget; in feroaring dy't it ynternet fan 'e húshâlding by it jûnsmiel brekt, is folle dreger te debuggen as ien dy't jo yn in minút weromdraaie kinne.