Pi-hole не блокира реклами откако ќе се поврзе VPN: пет проверки

Рекламите сѐ уште се прикажуваат на клиент, 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 и резолверот додека тестот не помине двапати; промена што го крши домашниот интернет за време на вечерата е многу потешко да се отстрани од грешка отколку онаа што може да ја вратите за една минута.