A Pi-hole nem blokkolja a hirdetéseket a VPN csatlakozása után: öt ellenőrzés

A hirdetések továbbra is megjelennek egy ügyfélen, a Pi-hole egészségesnek jelenti magát, és az alagút él, ezért az ösztön az, hogy az ügyfél forgalmát a Pi-n keresztül irányítsuk. Ez a rossz kanyar. A szűréshez a kérdések kellenek, nem a csomagok, és az az ügyfél, amelynek lekérdezései a szolgáltató feloldójához mennek, szűretlen marad, bármerre folyik is a forgalma. Menjen végig ezen a listán sorban, és álljon meg az első lépésnél, amelyik elbukik, mert egy későbbi lépés semmit sem mondhat, amíg egy korábbi el van romolva.

1. Olvassa el a feloldót, amelyet az ügyfél ténylegesen használ

Az ügyfélt kérdezze, ne az útválasztót. Linuxon a resolvectl status kiírja a DNS-kiszolgálókat kapcsolatonként és azt, hogy melyik kapcsolat nyer; a /etc/resolv.conf önmagában általában egy stub, amely a 127.0.0.53-ra mutat. Windowson az ipconfig /all adapterenként listázza a DHCP által adott kiszolgálókat, macOS-en pedig a scutil --dns ugyanezt mutatja hatókörönként. Ha a válasz nem a Pi-hole címe, hozzárendelési problémája van, és a 2-es lépés az a hely, ahol ez lakik.

Két dolog legyőzi a rendszer feloldóját akkor is, ha helyesen van beállítva. A saját biztonságos DNS-sel rendelkező böngészők (a Chrome “Use secure DNS” opciója, a Firefox network.trr.mode-ja) HTTPS-en keresztül küldik a lekérdezéseket egy nyilvános feloldóhoz, és soha nem nyitják meg az 53-as portot. És az ügyfélen lévő VPN-kliens telepíthet egy DNS-kiszolgálót az alagút-interfészére ~. útválasztási tartománnyal, ami azt a kapcsolatot minden név számára mérvadóvá teszi.

Tesztelje azt az útvonalat, amelyet az alkalmazások járnak be, ne azt, amelyet egy hibakereső eszköz. A resolvectl query example.com megmutatja, melyik kapcsolat válaszolt, és a getent hosts example.com ugyanazon az NSS-útvonalon megy, mint egy alkalmazás; macOS-en a dscacheutil -q host -a name example.com azokat a hatókörös feloldókat olvassa, amelyeket a scutil --dns listáz. A csupasz dig ezt nem teszi: a /etc/resolv.conf-ot olvassa, és kihagyja a kapcsolatonkénti választást, így válaszolhat a Pi-hole-ból, miközben minden alkalmazás a tolt feloldót használja, és pontosan ez az a hiba, amelyre ez a lista létezik. Tartsa meg a dig @192.168.1.53-at egy adott kiszolgáló tesztelésére.

2. Erősítse meg, ki osztja ki a választ

A hozzárendelés attól jön, ami a DHCP-re válaszol. A dnsmasq-nál ez egyetlen sor, dhcp-option=6,192.168.1.53; egy útválasztó webes felületén ez a DNS-mező a LAN DHCP szakaszban. Az ügyfeleknek meg kell újítaniuk, mielőtt látják. Egy napok óta futó eszköz még a régi bérletet tartja, és egy kézzel beírt feloldóval rendelkező eszköz örökre tartja. Újítsa meg egy tesztügyfélen, ahelyett hogy feltételezné a terjedést.

Az IPv6 az a fele, amelyik kimarad. Az útválasztó-hirdetések saját DNS-kiszolgálót hordozhatnak (RDNSS), és OpenWrt-n ez az odhcpd ra_dns opciója; az IPv6-ot előnyben részesítő ügyfél azt a kiszolgálót használja, miközben az éppen beállított DHCPv4 opció használatlan marad. Ha nem kész szolgáltatni IPv6 DNS-t, csak a DNS-hirdetést törölje: ra_dns az odhcpd-ben, vagy az RDNSS opció abban, ami az útválasztó-hirdetésekre válaszol. A teljes hirdetés kikapcsolása az IPv6-címzést is eltávolítja a LAN-ról, ami sokkal nagyobb változás a szándékozottnál, míg csak a DNS-opció törlése érintetlenül hagyja a címzést, és láthatóvá teszi a hiányzó RDNSS-t egy csomagrögzítésben.

3. Bizonyítsa, hogy a lekérdezés eléri a Pi-hole-t

A Pi-ről indított lekérdezés semmit sem bizonyít a hálózati útvonalról. Futtassa az ügyfélről, és olvassa le a válaszkódot:

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

Az időtúllépés szűrésre vagy útvonalra mutat; a REFUSED hozzáférési szabályra; a SERVFAIL a Pi-hole mögötti felső feloldóra; a lekérdezési naplóban soha meg nem jelenő helyes válasz azt jelenti, hogy az ügyfél valami mást kérdezett. Ellenőrizze az UDP és TCP 53-at, mert a nagy válaszok és egyes feloldók visszaesnek TCP-re, és tegye közzé mindkettőt, amikor a Pi-hole konténerben fut. A csak UDP-t lefedő leképezés időszakos hibákat okoz, amelyek csomagvesztésnek tűnnek.

Ezután a Pi-hole figyelési módja dönti el, hogy egyáltalán válaszol-e. Csak helyi módban a dnsmasq figyelmen kívül hagyja azoknak a forrásoknak a lekérdezéseit, amelyek nincsenek közvetlenül csatlakozó alhálózaton, és pontosan így néz ki egy másik útválasztó mögötti vagy alagúton érkező ügyfél: az ügyfél időtúllépésbe fut, és a lekérdezés soha nem ér el a naplóba. Az a lekérdezés, amely mégis REFUSED-ként jelenik meg, hozzáférési listán vagy tűzfalszabályon bukott el. Az összes forrás engedélyezése a szokásos javítás, párosítva egy tűzfalszabállyal, amely az 53-as portot a saját alhálózataira korlátozza.

4. Ellenőrizze, hogy az alagút lecserélte-e vagy elnyelte-e a választ

Ez az az eset, amelyben mindkét tünet elrejtőzik. Amikor az útválasztó maga VPN-kliens, a tolt DNS-opció felülírhatja a LAN-beállítást abban a pillanatban, amikor az alagút feljön: az OpenVPN-kiszolgálók dhcp-option DNS-t tolnak, a WireGuard-profilok pedig saját DNS-bejegyzést hordoznak. Az útválasztó tényleges feloldóját az alagút élő állapotában olvassa, ne előtte, és hagyja figyelmen kívül, amit a LAN-oldal állít.

A másik hiba az elérhetőség, nem a helyettesítés. Ha az alagút engedélyezett előtagjai tartalmazzák a LAN-alhálózatát, az útválasztónak van egy útvonala, amely a 192.168.1.53-ra vonatkozó lekérdezéseket az alagútba küldi, és a túloldalon nincs visszaút: a lekérdezések időtúllépésbe futnak, pedig az alagút egészséges. Ennek a fordítottja történik, amikor a Pi-hole olyan alhálózaton ül, amelyet az alagút nem visz át. Hasonlítsa össze a címet az alagút engedélyezett előtagjaival és az útválasztó útvonaltáblázatával, mielőtt újra a DNS-hez nyúlna.

Válasszon egy javítást, ne mindkettőt. Vagy tartsa távol az alagutat a DNS-től — az OpenVPN-en pull-filter ignore “dhcp-option DNS” és a WireGuardon LAN-előtag nélkül az AllowedIPs-ben —, vagy fogadja el a tolt feloldót, és mondjon le a helyi szűrésről az adott útválasztó mögötti ügyfelek számára. Bármit is választ, írja le a profil mellé, mert a következő ember, aki szerkeszti, különben véletlenül megfordítja a döntést.

5. Ismételje meg a tesztet újracsatlakozás után

Kérdezzen egy ügyféltől, erősítse meg, hogy az az ügyfél megjelenik a Pi-hole naplójában, majd oldjon fel egy domaint, amelyet blokkolni kellene, és ellenőrizze, hogy a blokkoló választ kapja-e a valódi helyett. Csatlakoztassa újra az alagutat, és futtassa ugyanazt a két lekérdezést, mert az a feloldóbeállítás, amely csak a következő csatlakozásig tart, a rossz rétegen alkalmazott javítás szokásos eredménye.

Hagyjon egy másodlagos feloldóútvonalat, amely nem függ az alagúttól, hogy a Pi-hole kiesése szűretlen böngészésbe essen vissza, ne pedig a böngészés teljes hiányába. Tartsa meg az előző DHCP- és feloldóértékeket, amíg a teszt kétszer át nem megy; azt a változtatást, amely vacsoránál megszakítja a háztartás internetét, sokkal nehezebb hibakeresni, mint azt, amelyet egy perc alatt vissza tud fordítani.