Pi-hole не блокира рекламе након повезивања VPN-а: пет провера
Блокирање реклама захтева упите, а не руте. Прођите кроз доделу, порт 53, IPv6, гурнути DNS и префиксе тунела редом и зауставите се на првом неуспеху.
Рекламе се још приказују на клијенту, Pi-hole се пријављује као здрав, а тунел је активан, па је инстинкт да се саобраћај тог клијента усмери кроз Pi. То је погрешна кривина. Филтрирање захтева питања, а не пакете, и клијент чији упити иду ка резолверу провајдера остаје нефилтриран без обзира куда тече његов саобраћај. Прођите кроз овај списак редом и зауставите се на првом кораку који не успе, јер каснији корак не може ништа да каже док је ранији покварен.
1. Прочитајте резолвер који клијент заиста користи
Питајте клијента, не рутер. На Linux-у resolvectl status исписује DNS сервере по вези и која веза побеђује; /etc/resolv.conf сам по себи је обично стуб који показује на 127.0.0.53. На Windows-у ipconfig /all наводи сервере које је доделио DHCP по адаптеру, а на macOS-у scutil --dns показује исто по опсегу. Ако одговор није адреса Pi-hole-а, имате проблем са доделом и корак 2 је место где се налази.
Две ствари побеђују системски резолвер чак и када је правилно подешен. Прегледачи са сопственим безбедним DNS-ом (опција “Use secure DNS” у Chrome-у, network.trr.mode у Firefox-у) шаљу упите преко HTTPS јавном резолверу и никада не отварају порт 53. А VPN клијент на самом клијенту може да инсталира DNS сервер на свом тунелском интерфејсу са доменом рутирања ~., што ту везу чини меродавном за свако име.
Тестирајте пут којим иду апликације, а не пут којим иде алат за отклањање грешака. resolvectl query example.com показује која веза је одговорила, а getent hosts example.com иде истим NSS путем као апликација; на macOS-у dscacheutil -q host -a name example.com чита резолвере по опсегу које наводи scutil --dns. Голи dig то не ради: он чита /etc/resolv.conf и прескаче избор по вези, па може да одговори из Pi-hole-а док свака апликација користи гурнути резолвер, и то је управо дефект због којег овај списак постоји. Задржите dig @192.168.1.53 за тестирање једног конкретног сервера.
2. Потврдите ко дели одговор
Додела долази од онога што одговара на DHCP. На dnsmasq-у то је један ред, dhcp-option=6,192.168.1.53; у веб интерфејсу рутера то је поље DNS у одељку DHCP за LAN. Клијенти морају да обнове пре него што то виде. Уређај који ради данима још држи стари закуп, а уређај са ручно унетиим резолвером држи га заувек. Обновите на тест клијенту уместо да претпоставите ширење.
IPv6 је половина која се пропушта. Огласи рутера могу да носе сопствени DNS сервер (RDNSS), а на OpenWrt-у то је опција ra_dns у odhcpd-у; клијент који преферира IPv6 користи тај сервер док опција DHCPv4 коју сте управо подесили остаје неискоришћена. Ако нисте спремни да служите DNS преко IPv6-а, обришите само оглас за DNS: ra_dns у odhcpd-у, или опцију RDNSS у ономе што одговара на огласе рутера. Искључивање целог огласа уклања и адресирање IPv6 са LAN-а, што је много већа промена од оне коју сте намеравали, док брисање само опције DNS чува адресирање нетакнутим и чини недостајући RDNSS видљивим у снимању пакета.
3. Докажите да захтев стиже до Pi-hole-а
Захтев са Pi-а не доказује ништа о мрежном путу. Покрените га са клијента и прочитајте код одговора:
dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net
Истек времена указује на филтрирање или на руту; REFUSED указује на правило приступа; SERVFAIL указује на надређени резолвер иза Pi-hole-а; исправан одговор који се никада не појављује у дневнику захтева значи да је клијент питао нешто друго. Проверите UDP и TCP 53, јер велики одговори и неки резолвери падају назад на TCP, и објавите оба када Pi-hole ради у контејнеру. Мапирање које покрива само UDP ствара повремене дефекте који изгледају као губитак пакета.
Затим режим слушања Pi-hole-а одлучује да ли уопште одговара. У режиму само локално dnsmasq игнорише захтеве из извора који нису на директно повезаној подмрежи, а управо тако изгледа клијент иза другог рутера или онај који долази кроз тунел: клијент истекне и захтев никада не стигне до дневника. Захтев који се ипак појави као REFUSED одбијен је листом приступа или правилом заштитног зида. Дозвољавање свих извора је уобичајена поправка, заједно са правилом заштитног зида које ограничава порт 53 на ваше сопствене подмреже.
4. Проверите да ли је тунел заменио или прогутао одговор
Ово је случај у коме се крију оба симптома. Када је рутер сам VPN клијент, гурнута DNS опција може да надјача подешавање LAN-а у тренутку када се тунел подигне: OpenVPN сервери гурају dhcp-option DNS, а WireGuard профили носе сопствени DNS унос. Читајте ефективни резолвер рутера са подигнутим тунелом, не пре тога, и игноришите шта тврди LAN страница.
Други дефект је достижност, а не замена. Ако дозвољени префикси тунела укључују вашу LAN подмрежу, рутер има руту која шаље захтеве за 192.168.1.53 у тунел, а супротна страна нема руту назад: захтеви истекну иако је тунел здрав. Обрнуто се дешава када Pi-hole седи у подмрежи коју тунел не носи. Упоредите адресу са дозвољеним префиксима тунела и табелом рута рутера пре него што поново додирнете DNS.
Изаберите једну поправку, не обе. Или држите тунел далеко од DNS-а — са pull-filter ignore “dhcp-option DNS” на OpenVPN-у и без LAN префикса у AllowedIPs на WireGuard-у —, или прихватите гурнути резолвер и одрекните се локалног филтрирања за клијенте иза тог рутера. Шта год да изаберете, запишите то поред профила, јер ће следећа особа која га буде уређивала иначе случајно окренути одлуку.
5. Поновите тест после поновног повезивања
Упитајте са клијента, потврдите да се тај клијент појављује у дневнику Pi-hole-а, затим разрешите домен који би требало да буде блокиран и проверите да ли добијате одговор о блокирању уместо правог. Поново повежите тунел и извршите иста два захтева, јер подешавање резолвера које траје само до следећег повезивања је уобичајен резултат поправке примењене на погрешном слоју.
Оставите секундарну путању резолвера која не зависи од тунела, да би се прекид Pi-hole-а деградирао у нефилтрирано прегледање уместо у никакво прегледање. Задржите претходне вредности DHCP-а и резолвера док тест не прође два пута; промену која поквари кућни интернет за вечером много је теже отклонити од оне коју можете да вратите за минут.