Pi-hole ei estä mainoksia VPN:n yhdistämisen jälkeen: viisi tarkistusta

Mainoksia näkyy edelleen asiakkaassa, Pi-hole ilmoittaa olevansa kunnossa ja tunneli on pystyssä, joten vaisto sanoo reitittää kyseisen asiakkaan liikenne Pi:n kautta. Se on väärä käännös. Suodatus tarvitsee kysymykset, ei paketteja, ja asiakas, jonka kyselyt menevät operaattorin resolverille, pysyy suodattamattomana riippumatta siitä, mihin sen liikenne virtaa. Käy tämä luettelo järjestyksessä läpi ja pysähdy ensimmäiseen vaiheeseen, joka epäonnistuu, koska myöhempi vaihe ei voi kertoa sinulle mitään, kun aikaisempi on rikki.

1. Lue resolver, jota asiakas todella käyttää

Kysy asiakkaalta, älä reitittimeltä. Linuxissa resolvectl status tulostaa DNS-palvelimet linkeittäin ja sen, mikä linkki voittaa; /etc/resolv.conf yksinään on yleensä stub, joka osoittaa osoitteeseen 127.0.0.53. Windowsissa ipconfig /all luettelee DHCP:n tarjoamat palvelimet sovitinkahtaisesti, ja macOS:ssa scutil --dns näyttää saman laajuuksittain. Jos vastaus ei ole Pi-holen osoite, sinulla on määritysongelma ja vaihe 2 on sen sijainti.

Kaksi asiaa voittaa järjestelmän resolverin, vaikka se olisi asetettu oikein. Selaimet, joilla on oma suojattu DNS (Chromen “Use secure DNS”, Firefoxin network.trr.mode), lähettävät kyselyt HTTPS:n yli julkiselle resolverille eivätkä koskaan avaa porttia 53. Ja asiakkaassa itsessään oleva VPN-asiakas voi asentaa DNS-palvelimen tunneliliittymäänsä reititysverkkotunnuksella ~., mikä tekee siitä linkistä valtuutetun kaikille nimille.

Testaa reitti, jota sovellukset kulkevat, älä reittiä, jota virheenkorjaustyökalu kulkee. resolvectl query example.com näyttää, mikä linkki vastasi, ja getent hosts example.com kulkee samaa NSS-reittiä kuin sovellus; macOS:ssa dscacheutil -q host -a name example.com lukee laajuuskohtaiset resolverit, jotka scutil --dns luettelee. Paljas dig ei tee tätä: se lukee /etc/resolv.conf ja ohittaa linkkikohtaisen valinnan, joten se voi vastata Pi-holesta, vaikka jokainen sovellus käyttää työnnettyä resolveria, ja juuri se on se vika, jota varten tämä luettelo on olemassa. Pidä dig @192.168.1.53 yhden tietyn palvelimen testaamiseen.

2. Vahvista, kuka jakaa vastauksen

Määritys tulee siltä, mikä vastaa DHCP:hen. dnsmasqissa se on yksi rivi, dhcp-option=6,192.168.1.53; reitittimen verkkokäyttöliittymässä se on DNS-kenttä LAN DHCP -osiossa. Asiakkaiden on uusittava ennen kuin ne näkevät sen. Laite, joka on ollut päällä päiviä, pitää yhä vanhan vuokran, ja laite, johon resolver on kirjoitettu käsin, pitää sen ikuisesti. Uusi testiasiakkaalla sen sijaan, että olettaisit leviämisen.

IPv6 on se puoli, joka unohtuu. Reitittimen ilmoitukset voivat kuljettaa oman DNS-palvelimensa (RDNSS), ja OpenWrt:ssä se on odhcpd:n ra_dns-vaihtoehto; asiakas, joka suosii IPv6:tta, käyttää tuota palvelinta, kun taas juuri asettamasi DHCPv4-vaihtoehto jää käyttämättömäksi. Jos et ole valmis tarjoamaan IPv6-DNS:ää, tyhjennä vain DNS-ilmoitus: ra_dns odhcpd:ssä tai RDNSS-vaihtoehto siinä, mikä vastaa reitittimen ilmoituksiin. Koko ilmoituksen sammuttaminen poistaa myös IPv6-osoitteet LAN:sta, mikä on paljon suurempi muutos kuin se, jonka aioit tehdä, kun taas vain DNS-vaihtoehdon tyhjentäminen pitää osoitteet ehjinä ja tekee puuttuvan RDNSS:n näkyväksi pakettikaappauksessa.

3. Todista, että kysely saavuttaa Pi-holen

Kysely Pi:stä ei todista mitään verkkoreitistä. Suorita se asiakkaalta ja lue vastauskoodi:

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

Aikakatkaisu viittaa suodatukseen tai reittiin; REFUSED viittaa käyttösääntöön; SERVFAIL viittaa Pi-holen takana olevaan ylempään resolveriin; oikea vastaus, joka ei koskaan ilmesty kyselylokiin, tarkoittaa, että asiakas kysyi jotain muuta. Tarkista UDP ja TCP 53, koska suuret vastaukset ja jotkin resolverit putoavat takaisin TCP:hen, ja julkaise molemmat, kun Pi-hole toimii kontissa. Vain UDP:n kattava kartoitus tuottaa ajoittaisia vikoja, jotka näyttävät pakettihäviöltä.

Sitten Pi-holen kuuntelutila ratkaisee, vastaako se ollenkaan. Vain paikallinen -tilassa dnsmasq jättää huomiotta kyselyt lähteistä, jotka eivät ole suoraan liitetyssä aliverkossa, ja juuri sellaiselta toisen reitittimen takana oleva tai tunnelin kautta saapuva asiakas näyttää: asiakas aikakatkaisee eikä kysely koskaan saavu lokiin. Kysely, joka kuitenkin ilmestyy REFUSED:na, hylättiin käyttöluettelolla tai palomuurisäännöllä. Kaikkien lähteiden salliminen on tavallinen korjaus, yhdessä palomuurisäännön kanssa, joka rajaa portin 53 omiin aliverkkoihisi.

4. Tarkista, korvasiko vai nielaisiko tunneli vastauksen

Tämä on tapaus, johon molemmat oireet kätkeytyvät. Kun reititin on itse VPN-asiakas, työnnetty DNS-vaihtoehto voi ohittaa LAN-asetuksen heti, kun tunneli nousee: OpenVPN-palvelimet työntävät dhcp-option DNS:n, ja WireGuard-profiilit tuovat oman DNS-merkintänsä. Lue reitittimen tehollinen resolver tunneli pystyssä, ei ennen sitä, ja jätä huomiotta se, mitä LAN-sivu väittää.

Toinen vika on tavoitettavuus eikä korvaaminen. Jos tunnelin sallitut etuliitteet sisältävät LAN-aliverkkosi, reitittimellä on reitti, joka lähettää 192.168.1.53:n kyselyt tunneliin, eikä vastapuolella ole paluureittiä: kyselyt aikakatkaisevat, vaikka tunneli on kunnossa. Päinvastainen tapahtuu, kun Pi-hole on aliverkossa, jota tunneli ei kuljeta. Vertaa osoitetta tunnelin sallittuihin etuliitteisiin ja reitittimen reititystauluun ennen kuin kosket DNS:ään uudelleen.

Valitse yksi korjaus, älä molempia. Joko pidä tunneli erossa DNS:stä — OpenVPN:ssä pull-filter ignore “dhcp-option DNS” ja WireGuardissa ilman LAN-etuliitettä AllowedIPs:ssä — tai hyväksy työnnetty resolver ja luovu paikallisesta suodatuksesta kyseisen reitittimen takana oleville asiakkaille. Mitä ikinä valitsetkin, kirjoita se profiilin viereen, koska seuraava sitä muokkaava henkilö kääntää päätöksen muuten vahingossa.

5. Toista testi uudelleenyhdistämisen jälkeen

Kysy asiakkaalta, vahvista, että kyseinen asiakas ilmestyy Pi-holen lokiin, ratkaise sitten verkkotunnus, joka pitäisi estää, ja tarkista, että saat estovastauksen todellisen sijaan. Yhdistä tunneli uudelleen ja suorita samat kaksi kyselyä, koska resolveriasetus, joka kestää vain seuraavaan yhdistämiseen, on tavallinen tulos väärälle kerrokselle tehdystä korjauksesta.

Jätä toissijainen resolver-reitti, joka ei riipu tunnelista, jotta Pi-holen katkos heikkenee suodattamattomaan selailuun eikä selailun puuttumiseen. Pidä aiemmat DHCP- ja resolver-arvot, kunnes testi menee läpi kahdesti; muutos, joka katkaisee kotitalouden internetin päivällisellä, on paljon vaikeampi selvittää kuin sellainen, jonka voi perua minuutissa.