Как блокировать рекламу на уровне роутера с помощью pixelserv и DD‑WRT

Быстрая навигация

• Обзор
• Принцип работы
• Что нужно и допущения
• Благодарности
• Подготовка и установка
• Конфигурация роутера
• Персональные списки и белый список
• Запуск и проверка
• Поиск неисправностей
• Методики, чек-листы и тесты
• Безопасность и приватность
• Критерии приёмки
• Краткое резюме

Обзор

В этой инструкции описано, как блокировать рекламу централизованно для всей локальной сети, используя прошивку DD‑WRT и подход «намеренного отравления DNS» (DNS poisoning) в сочетании с лёгким HTTP‑сервером pixelserv. После настройки рекламные домены будут разрешаться в локальный IP пиксель‑сервера, а клиенты будут получать прозрачный 1×1 пиксель вместо рекламного контента.

Обновление: руководство обновлено с учётом отзывов и нового исполняемого файла pixel‑server, а также журнала изменений.

Почему не просто расширение ad‑block в браузере?

• Централизованное решение избавляет от необходимости устанавливать расширения на каждое устройство в сети (подойдёт для гостей, IoT, общих ПК и серверов).
• Снижается административная нагрузка: не нужно обучать каждого пользователя включать адблок.
• Рекомендуется комбинировать подходы: маршрутизаторный блок + клиентский ad‑block дают лучший результат.

Важно: если у вас нет DD‑WRT, то адблок в браузере уже покрывает большинство случаев. Это руководство для тех, кто хочет общий сетевой блокировщик.

Принцип работы

Коротко:

1. DNS‑сервер роутера (dnsmasq) «отравляет» ответы, возвращая конкретный локальный IP для известных рекламных доменов.
2. На этом IP запускается лёгкий HTTP‑сервис pixelserv, который отвечает прозрачным 1×1 пикселем или пустым ответом на любые HTTP‑запросы.
3. Клиенты получают корректный HTTP‑ответ, загрузка страницы продолжается без внешних рекламных ресурсов.

Компоненты:

• DD‑WRT с поддержкой JFFS (для хранения файлов после перезагрузки)
• pixelserv (компактный HTTP‑сервер, возвращающий один пиксель)
• Скрипт автоматизации, который собирает персональный список + динамические списки (MVPS Hosts, Yoyo list)
• Белый список доменов, которые нельзя блокировать

Короткое объяснение термина «DNS‑отрава»: это намеренное возвращение неверного IP‑адреса для домена с целью перенаправить запрос на локальный сервис.

Что нужно и допущения

• Терпение: инструкция детальная и займёт время.
• DD‑WRT версии приблизительно v24pre‑sp2 10/12/10 mini r15437 или более новая (минимальная поддержка — мини‑версия с JFFS). Точная версия зависит от модели роутера.
• Роутер должен быть восстановлен к заводским настройкам или не иметь изменённых DNS/сетевых настроек.
• Клиенты по умолчанию используют роутер как DNS‑сервер (DHCP раздаёт IP роутера в качестве DNS).
• Доступно место для JFFS (рекомендуется мини‑сборка DD‑WRT с JFFS‑разделом).
• Сеть — класс C (маска 255.255.255.0), так как скрипт рассчитывает последний адрес x.y.z.254 для pixelserv. При другой маске потребуется поправить конфигурацию.
• У вас есть возможность подключиться по SCP/SSH к роутеру (winSCP или scp/ssh).
• Рекомендуется также установить browser ad‑block как «ответная мера». Скрипт не может динамически скачать новые пакеты между циклами обновления (скрипт обновляет списки раз в 3 дня).

ВНИМАНИЕ: некоторые шаги меняют конфигурацию роутера и требуют доступа root. Выполняйте осторожно и сохраняйте резервные копии.

Благодарности

Обновление: особая благодарность mstombs за реализацию C‑кода pixelserv, Oki за сборку для Atheros‑платформ и Nate за помощь в тестировании. Части идеи взяты с форумов DD‑WRT и Wiki (ad‑blocking with DD‑WRT revisited, pixelserv без Perl и Flexion.Org Wiki on DNSmasq).

Подготовка: включаем SSH и JFFS

1. В веб‑интерфейсе DD‑WRT перейдите на вкладку “Services” и в секции “Secure shell” включите SSHd.

Сохраните настройки, но пока не применяйте.

2. В вкладке “Administration” найдите секцию JFFS и включите JFFS2 и опцию очистки (Clean JFFS2) при первом запуске. Затем сохраните и перезагрузите роутер для форматирования JFFS‑раздела.

Описание JFFS (перевод цитаты DD‑WRT):

Файловая система Journaling Flash File System (JFFS) позволяет иметь записываемую Linux‑файловую систему на роутере с DD‑WRT. Она используется для хранения пользовательских программ и данных в недоступной иначе флеш‑памяти. Это позволяет сохранять индивидуальные конфигурационные файлы, собственные веб‑страницы и многое другое, что невозможно без JFFS.

После перезагрузки обновите страницу Administration → JFFS и убедитесь, что есть свободное место.

Установка pixelserv и файлов в JFFS

1. Скачайте архив anti‑ads pack для DD‑WRT (в архиве: pixelserv, скрипт disable_adds.sh и personal‑domain‑list).
2. Установите winSCP (или используйте scp в терминале) и подключитесь к роутеру по SCP: хост — IP роутера (по умолчанию 192.168.1.1), порт 22, пользователь root.

Отключите опцию “Lookup user groups” в расширенных настройках winSCP, иначе появятся предупреждения при подключении.

3. В winSCP перейдите в корневой каталог “/“ → “/jffs” и создайте папку dns. Скопируйте туда файлы pixelserv и disable_adds.sh, а также personal‑domain‑list.conf.

Если у вас Atheros‑маршрутизатор, используйте pixelserv_AR71xx и переименуйте его в pixelserv.

4. Сделайте файлы исполняемыми: свойства → поставить отметку X для владельца.

Запуск сценария при старте роутера

1. В веб‑интерфейсе DD‑WRT перейдите на “Administration” → “Commands”.
2. В поле команд введите путь к сценарию: /jffs/dns/disable_adds.sh
3. Нажмите “Save Startup” — сценарий будет добавлен в автозагрузку.

Настройка персонального списка блокируемых доменов

Есть два варианта добавления доменов:

1. Веб‑GUI — поле “Services” → секция DNSMasq → “Additional DNSMasq Options”. Вставляйте строки вида:

address=/domain-to-block/192.168.1.254

Где 192.168.1.254 — IP pixelserv для вашей подсети. Если ваша подсеть отличается, замените соответствующим адресом.

2. Редактирование файла /jffs/dns/personal-ads-list.conf и добавление строк с тем же синтаксисом. Скопируйте файл из архива, отредактируйте IP при необходимости и добавьте домены.

Важно: синтаксис критичен — ошибка может нарушить работу dnsmasq и привести к тому, что ваша сеть не сможет разрешать домены.

Настройка белого списка

Белый список исключает домены из динамических и персональных списков блокировки. Без него некоторые сайты будут работать некорректно (примеры: google‑analytics.com), потому что блокировка скриптов приводит к зависанию ожидания ответа.

Скрипт при первом запуске создаёт файл whitelist в /jffs/dns с уже включёнными google‑analytics и googleadservices. Если хотите изменить белый список, редактируйте файл в начале списка и добавляйте домены сверху — из‑за бага с обработкой новых строк новые записи должны быть в начале файла. Оставляйте файл без пустых строк — пустая строка может привести к удалению данных из всех списков.

Запуск и проверка

1. В веб‑GUI: Administration → Management → Reboot Router (Перезагрузить роутер).
2. Подождите 1–3 минуты — скрипт выполнит сборку списков и запустит pixelserv.
3. Проверка быстрого результата: откройте несколько сайтов с рекламой — вы должны увидеть меньше внешних рекламных блоков или пустые места, где раньше были баннеры.

Для точной проверки выполните на клиенте проверку DNS:

• Windows:

nslookup ad.example.com

Ожидаемый ответ: IP, совпадающий с pixelserv (например, 192.168.1.254).

• Если не совпадает — проверьте, какой DNS использует клиент (nslookup покажет сервер).

Дополнительная проверка: очистите кеш DNS (Windows: ipconfig /flushdns) и закройте браузер для удаления локального кеша.

Отладка и устранение неисправностей

1. nslookup: убедитесь, что рекламный домен резолвится в IP pixelserv.

Пример (Windows):

C:\> nslookup ad-emea.doubleclick.com
Server:  192.168.1.1
Address: 192.168.1.1#53

Name:    ad-emea.doubleclick.com
Address: 192.168.1.254

Если в поле “Server” указан не ваш роутер — клиент не использует роутер как DNS.

2. Вернуть заводские настройки и пройти установку заново — помогает избавиться от конфликтующих правил.

3. Убедитесь, что клиент действительно использует роутер как DNS (VPN, статические DNS или прокси могут перебить DHCP‑настройку).

4. Очистите DNS‑кеш клиента: Windows — ipconfig /flushdns; Linux — sudo systemd-resolve –flush-caches или перезапустить службу сети.

5. Закройте браузер — браузеры кэшируют ответы и содержимое страниц.

6. Перезагрузите роутер и/или клиент, если кеши не уходят.

7. Включите syslog на роутере (Services → Enable Syslogd) и просмотрите /var/log/messages.

Команды для просмотра логов (SSH):

more /var/log/messages
# или, чтобы смотреть в реальном времени
tail -f /var/log/messages

Скрипт добавляет алиасы для упрощённой отладки: clog (фильтрация сообщений скрипта) и tlog (tail логов).

8. Ознакомьтесь со скриптом disable_adds.sh, чтобы понять, как создаются списки и какие шаги выполняются.

Полезные команды и короткий справочник

• nslookup <домен> — проверить разрешение домена на клиенте.
• ipconfig /flushdns — очистить DNS‑кеш Windows.
• tail -f /var/log/messages — смотреть системные логи в реальном времени.
• chmod +x /jffs/dns/pixelserv — сделать бинарник исполняемым (если используете ssh).
• ps | grep pixelserv — проверить, запущен ли pixelserv.
• netstat -lnp | grep :80 — проверить, слушает ли локальный порт HTTP (если доступно).

Методология и лучшие практики (мини‑метод)

Шаги — контрольный список (микро‑SOP):

1. Сделать резервную копию текущей конфигурации роутера.
2. Включить SSH и JFFS, перезагрузить и проверить JFFS.
3. Скопировать pixelserv и скрипты в /jffs/dns, дать права на исполнение.
4. Настроить автозапуск скрипта.
5. Отредактировать personal‑ads‑list и whitelist.
6. Перезагрузить роутер и проверить резолв рекламных доменов.
7. Включить syslog и мониторить логи первые 24 часа.

Совет: оставьте клиентский ad‑block включённым в качестве резервного слоя.

Ролевые чек‑листы

Для домашнего пользователя:

• Включить SSH и JFFS
• Скопировать pixelserv и скрипт
• Включить автозапуск
• Перезагрузить и проверить 3–5 сайтов

Для администратора малого офиса:

• Проверить совместимость прошивки с JFFS и pixelserv
• Настроить резервную копию конфигурации
• Настроить централизованный мониторинг логов (удалённый syslog)
• Согласовать белый список с пользователями (маркетинг/аналитика)

Для системного инженера/DevOps:

• Написать playbook (Ansible) для развёртывания конфигурации на нескольких роутерах (если поддерживается)
• Настроить автоматическое тестирование резолвинга и HTTP‑ответов
• Интегрировать оповещения при падении pixelserv

Тест‑кейсы и критерии приёмки

Критерии приёмки:

• Рекламный домен A резолвится в IP pixelserv (например, .254).
• pixelserv отвечает HTTP 200 и возвращает изображение 1×1 или пустое тело для рекламных URL.
• После очистки кеша реклама на тестовых страницах исчезает.
• Белый список предотвращает падение функционала сайтов (например, аналитика не вызывает блокировку взаимодействия).

Тест‑кейсы:

1. NSLOOKUP: для наборa рекламных доменов — ответ = pixelserv IP.
2. CURL: curl -I http://blocked-ad.example/ — ответ 200 и тип содержимого image/gif (или image/png).
3. Поведенческий тест: открыть страницу с динамическими рекламными скриптами — проверить отсутствие долгих таймаутов.
4. Регрессивный тест: удалить персональный список и убедиться, что блокировка возвращается после восстановления.

Сравнение подходов (краткая матрица)

• Клиентский ad‑block (браузер): точный, действенен против сложных скриптов, требует установки на каждом устройстве.
• Роутерный DNS‑блок (pixelserv): централизованный, удобен для гостей/IoT, проще в управлении, но менее гибок против сложных (обфусцированных) рекламных CDN.
• Комбинация: лучшее покрытие — сетевой фильтр + клиентский фильтр.

Модель зрелости применения (уровни)

• Уровень 0 — нет блокировки
• Уровень 1 — клиентские ad‑block на отдельных устройствах
• Уровень 2 — централизованная DNS‑блокировка на роутере (pixelserv)
• Уровень 3 — уровень 2 + централизованный мониторинг и белые/чёрные списки с CI для обновлений

Цель — перейти к уровню 3, если сеть содержит много общих устройств.

Советы по безопасности и приватности

• pixelserv отвечает локально и не передаёт рекламные запросы во внешние сети — это повышает приватность.
• Однако: при неправильной конфигурации вы можете ненароком блокировать аналитические и функциональные домены. Тестируйте и поддерживайте белый список.
• Права доступа: храните исполняемые файлы в /jffs и защитите доступ к SSH (используйте ключи для постоянного администрирования, ограничьте доступ по IP).
• Логи: если вы пересылаете syslog на внешний сервер, убедитесь в защите канала и сохранении приватности.

Совместимость и переносимость

• Модели: pixelserv доступен в сборках для разных архитектур (mips, ar71xx и др.). Для Atheros используйте pixelserv_AR71xx и переименуйте в pixelserv.
• Прошивка: DD‑WRT мини/стандарт с поддержкой JFFS обязательна для удобного хранения файлов.
• Альтернативы: OpenWrt/LEDE предлагают iptables/Adblock пакеты и более гибкое управление; если ваша модель поддерживает OpenWrt, рассмотрите его как альтернативу.

Частые ошибки и способы их устранения

• Ошибка: реклама видна, nslookup показывает внешний IP — причина: клиент использует другой DNS (VPN/статический DNS). Решение: настройте DHCP, запретите внешние DNS через firewall, или настройте клиент.
• Ошибка: сайты с аналитикой зависают — причина: блокировка аналитики. Решение: добавить google‑analytics в белый список.
• Ошибка: dnsmasq падает — причина: синтаксическая ошибка в дополнительных опциях. Решение: проверить файл на пустые строки/неправильные записи.

Примеры реальных команд и вывода

Проверка наличия процесса pixelserv на роутере (SSH):

ps | grep pixelserv
root@DDWRT:~# /jffs/dns/pixelserv
1234 ?        S    0:00 /jffs/dns/pixelserv

Проверка прослушиваемых портов:

netstat -lnp | grep :80
tcp        0      0 0.0.0.0:80          0.0.0.0:*           LISTEN      1234/pixelserv

Проверка HTTP‑ответа (с клиента):

curl -I http://ad.example.com/some/path
HTTP/1.1 200 OK
Content-Type: image/gif
Content-Length: 43

Решение: когда это не работает (ограничения)

• Защищённый контент по HTTPS: pixelserv не сможет подменить TLS‑соединение — контент, загружаемый по HTTPS с внешних доменов, останется заблокированным только на уровне DNS (запросы на HTTPS будут отвергнуты или не установят соединение). Многие современные рекламные сети используют HTTPS, поэтому сетевой DNS‑подход не совершенен для всех случаев.
• CDN и динамические домены: если реклама идёт с общего CDN‑домена, его блокировка может повлиять на функциональность сайта.

Альтернативы: развертывание прозрачного прокси с HTTPS‑интерцептом (требует доверенных сертификатов и сложной настройки) или использование клиентских расширений, которые фильтруют элементы внутри браузера.

Диаграмма принятия решения (Mermaid)

flowchart TD
  A[Есть DD-WRT с JFFS?] -->|Да| B[Нужно блокировать рекламу централизованно?]
  A -->|Нет| Z[Рассмотреть OpenWrt или клиентские ad-block]
  B -->|Да| C[Установить pixelserv и скрипты]
  C --> D[Добавить динамические списки и personal list]
  D --> E[Добавить whitelist]
  E --> F[Перезагрузить и тестировать]
  F -->|Проблемы| G[Проверить DNS у клиента и логи]
  F -->|OK| H[Мониторинг и поддержка]

Краткое резюме

• Централизованная блокировка рекламы на уровне роутера с помощью pixelserv и DNS‑«отравления» удобна для домашних сетей и маленьких офисов.
• Не забывайте о белом списке и о комбинированном использовании клиентского ad‑block для полного покрытия.
• Тестируйте после каждого изменения, храните резервные копии и мониторьте логи.

Краткие рекомендации перед началом

• Сделайте backup конфигурации роутера.
• Проверьте поддержку JFFS и архитектуру CPU (Atheros vs другие).
• Помните про HTTPS‑ограничения и поведение CDN.

Полезные ссылки и ресурсы

• DD‑WRT Wiki — JFFS и dnsmasq
• MVPS hosts и Yoyo list — динамические списки рекламных доменов

Краткое резюме для публикации в соцсетях (анонс, 100–200 слов)

Нужна простая централизованная блокировка рекламы для всех устройств в сети? Используйте DD‑WRT и pixelserv: настраиваем JFFS, копируем pixelserv и скрипт, подключаем динамические списки рекламных доменов и добавляем белый список. Результат — рекламные домены разрешаются в локальный IP и получают прозрачный 1×1 пиксель вместо рекламы. Подходит для гостевых ПК, IoT и серверов, где не хочется ставить расширения. Для максимальной эффективности комбинируйте сетевую блокировку с клиентским ad‑block и внимательно тестируйте сайты с аналитикой. Полное руководство, чек‑листы и команды приведены в статье.

Заключение

Если вы готовы к централизованному подходу — pixelserv на DD‑WRT даёт простой, контролируемый и лёгкий механизм для снижения количества рекламного трафика в домашней или небольшой офисной сети. Поддерживайте списки, следите за логами и не забывайте обновлять белый список, чтобы не нарушать работу сайтов.