Pi-hole stöðvar ekki auglýsingar eftir að VPN tengist: fimm athuganir

Auglýsingar birtast enn á biðlara, Pi-hole segist vera heilbrigt og göngin eru uppi, svo eðlishvötin er að beina umferð þess biðlara í gegnum Pi. Það er rangt beygja. Sía þarf spurningarnar, ekki pakkana, og biðlari sem fyrirspurnir hans fara til leysir þjónustuveitunnar helst ósíaður hvert sem umferð hans streymir. Farðu í gegnum þennan lista í röð og staldraðu við fyrsta skrefið sem bregst, því seinna skref getur ekki sagt þér neitt á meðan fyrra er bilað.

1. Lestu leysinn sem biðlarinn notar í raun

Spurðu biðlarann, ekki beininn. Á Linux prentar resolvectl status DNS-þjónana á hverja tengingu og hvaða tenging vinnur; /etc/resolv.conf eitt og sér er yfirleitt stub sem bendir á 127.0.0.53. Á Windows listar ipconfig /all þjónana sem DHCP gefur á hvern millistykki, og á macOS sýnir scutil --dns það sama eftir sviði. Ef svarið er ekki heimilisfang Pi-hole hefurðu úthlutunarvandamál og skref 2 er staðurinn þar sem það býr.

Tveir hlutir sigra leysi kerfisins jafnvel þegar hann er rétt stilltur. Vafrar með eigið öruggt DNS (valkosturinn “Use secure DNS” í Chrome, network.trr.mode í Firefox) senda fyrirspurnir yfir HTTPS til opinbers leysis og opna aldrei port 53. Og VPN-biðlari á biðlaranum sjálfum getur sett upp DNS-þjón á gönguviðmót sitt með leiðardómeni ~., sem gerir þá tengingu ræðandi fyrir hvert nafn.

Prófaðu leiðina sem forrit fara, ekki leiðina sem kembiforrit fer. resolvectl query example.com sýnir hvaða tenging svaraði, og getent hosts example.com fer sama NSS-leið og forrit; á macOS les dscacheutil -q host -a name example.com sviðsleysana sem scutil --dns listar. Bert dig gerir þetta ekki: það les /etc/resolv.conf og sleppir vali eftir tengingu, svo það getur svarað frá Pi-hole á meðan hvert forrit notar ýtta leysinn, og það er einmitt bilunin sem þessi listi er til fyrir. Haltu dig @192.168.1.53 til að prófa einn tiltekinn þjón.

2. Staðfestu hver skiptir svarinu út

Úthlutunin kemur frá því sem svarar DHCP. Á dnsmasq er það ein lína, dhcp-option=6,192.168.1.53; í vefviðmóti beinis er það DNS-reiturinn í LAN DHCP-hlutanum. Biðlarar verða að endurnýja áður en þeir sjá það. Tæki sem hefur verið í gangi í daga heldur enn gömlu leigunni, og tæki með handskrifuðum leysi heldur henni að eilífu. Endurnýjaðu á prófbiðlara í stað þess að gera ráð fyrir dreifingu.

IPv6 er sá helmingur sem gleymist. Beinaboð geta borið eigin DNS-þjón (RDNSS), og á OpenWrt er það valkosturinn ra_dns í odhcpd; biðlari sem kýs IPv6 notar þann þjón á meðan DHCPv4-valkosturinn sem þú stilltir rétt áðan situr ónotaður. Ef þú ert ekki tilbúinn að þjónusta IPv6 DNS skaltu hreinsa aðeins DNS-tilkynninguna: ra_dns í odhcpd, eða RDNSS-valkostinn í því sem svarar beinaboðum. Að slökkva á allri tilkynningunni fjarlægir líka IPv6-vistföng úr LAN-inu, sem er miklu stærri breyting en sú sem þú ætlaðir, á meðan að hreinsa aðeins DNS-valkostinn heldur vistföngunum óbreyttum og gerir vantað RDNSS sýnilegt í pakkaskrá.

3. Sannaðu að fyrirspurnin nái Pi-hole

Fyrirspurn frá Pi sannar ekkert um netleiðina. Keyrðu hana frá biðlaranum og lestu svarkóðann:

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

Tímamörk benda til síu eða leiðar; REFUSED bendir til aðgangsreglu; SERVFAIL bendir til leysisins ofan við Pi-hole; rétt svar sem birtist aldrei í fyrirspurnaskránni þýðir að biðlarinn spurði um eitthvað annað. Athugaðu UDP og TCP 53, því stór svör og sumir leysarar falla aftur á TCP, og birtu bæði þegar Pi-hole keyrir í gámi. Vörpun sem nær aðeins yfir UDP framleiðir slitróttar bilanir sem líta út eins og pakkatap.

Þá ræður hlustunarmáti Pi-hole hvort hann svarar yfirleitt. Í aðeins staðbundnum ham hunsar dnsmasq fyrirspurnir frá upptökum sem eru ekki á beintengdu undirneti, og einmitt þannig lítur biðlari bak við annan beini eða sá sem kemur í gegnum göng út: biðlarinn rennur út á tíma og fyrirspurnin nær aldrei í skrána. Fyrirspurn sem birtist samt sem REFUSED var hafnað af aðgangslista eða eldveggjarreglu. Að leyfa allar upptök er venjulega lagfæringin, ásamt eldveggjarreglu sem takmarkar port 53 við þín eigin undirnet.

4. Athugaðu hvort göngin komu í stað svarsins eða gleyptu það

Þetta er tilfellið sem bæði einkennin fela sig í. Þegar beinirinn er sjálfur VPN-biðlari, getur ýttur DNS-valkostur hnekkt LAN-stillingunni á þeirri stundu sem göngin rísa: OpenVPN-þjónar ýta dhcp-option DNS, og WireGuard-snið bera eigin DNS-færslu. Lestu raunverulega leysi beinisins með göngin uppi, ekki fyrir það, og hunsaðu það sem LAN-síðan fullyrðir.

Hinn gallinn er aðgengi, ekki staðgengil. Ef leyfð forskeyti göngunnar ná yfir LAN-undirnetið þitt hefur beinirinn leið sem sendir fyrirspurnir fyrir 192.168.1.53 inn í göngin, og hinum megin er engin leið til baka: fyrirspurnir renna út á tíma þótt göngin séu heilbrigð. Hið gagnstæða gerist þegar Pi-hole situr á undirneti sem göngin bera ekki. Berðu heimilisfangið saman við leyfð forskeyti göngunnar og leiðatöflu beinisins áður en þú snertir DNS aftur.

Veldu eina lagfæringu, ekki báðar. Annaðhvort haltu göngunum frá DNS — með pull-filter ignore “dhcp-option DNS” á OpenVPN og án LAN-forskeytis í AllowedIPs á WireGuard —, eða samþykktu ýtta leysinn og láttu af staðbundinni síun fyrir biðlara bak við þann beini. Hvað sem þú velur skaltu skrifa það við hlið sniðsins, því næsta manneskja sem breytir því mun annars snúa ákvörðuninni fyrir slysni.

5. Endurtaktu prófið eftir endurtengingu

Gerðu fyrirspurn frá biðlara, staðfestu að sá biðlari birtist í skrá Pi-hole, leystu síðan lén sem ætti að vera lokað og athugaðu að þú fáir lokandi svarið í stað hins raunverulega. Taktu göngin aftur og keyrðu sömu tvær fyrirspurnirnar, því leysistilling sem endist aðeins til næstu tengingar er venjuleg niðurstaða lagfæringar sem beitt var á röngu lagi.

Skildu eftir aukaleið leysis sem er ekki háð göngunum, svo bilun Pi-hole hrörni í ósíaða vafrun í stað engrar vafrunar. Haltu fyrri DHCP- og leysigildum þar til prófið gengur tvisvar; breyting sem brýtur net heimilisins við kvöldmat er miklu erfiðari að kemba en sú sem þú getur afturkallað á einni mínútu.