Домашній Pi-hole, Telegram-бот і трохи vibe coding: як Raspberry Pi стала DNS-фільтром для всієї квартири

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Вступ: з чого все почалося

У якийсь момент мені захотілося зробити вдома щось просте, корисне й достатньо технічне, щоб було цікаво копирсатися вечорами. Не черговий «hello world» на Raspberry Pi, а маленьку домашню інфраструктуру, яка реально працює щодня.

Ідея була проста: поставити вдома DNS-блокувальник реклами, щоб не налаштовувати ad blocker окремо на кожному пристрої. Бо якщо чесно, браузерні розширення — це добре, але вони не вирішують усе. Є телефон, MacBook, TV, застосунки, IoT-пристрої, якісь фонові сервіси. Усе це постійно ходить у мережу, робить DNS-запити, тягне аналітику, трекери, рекламні домени й інший цифровий шум.

Хотілося, щоб реклама, трекери й аналітика різалися не на рівні конкретного браузера, а на рівні всієї домашньої мережі. Тобто пристрій підключився до Wi-Fi — і вже використовує локальний DNS-фільтр. Без окремих налаштувань на кожному клієнті. Максимально в стилі «підключив і забув».

Для цього я взяв Raspberry Pi Zero 2 W, поставив Raspberry Pi OS Lite, підняв Pi-hole і налаштував роутер так, щоб він видавав Raspberry Pi як DNS-сервер для домашніх пристроїв.

Найбільшим відкриттям стало те, що в моїй домашній мережі близько 20% DNS-запитів за день — це рекламні домени, трекінгові системи, аналітика або суміжний цифровий шум.

І коли ти бачиш це не як абстрактну розмову про privacy, а як реальну статистику зі своєї квартири, ставлення трохи змінюється. Бо це вже не «десь там інтернет збирає дані». Це твій телефон, ноутбук, телевізор і застосунки прямо зараз постійно щось запитують.

Raspberry Pi Zero 2 W, яка тепер тихо працює домашнім DNS-фільтром.

Важливий дисклеймер: я не мережевий спеціаліст

Одразу чесно: я не мережевий інженер і не людина, яка зранку за кавою читає RFC по DNS. Моя основна спеціалізація — iOS-розробка, а вся ця історія з Pi-hole, DHCP, локальним DNS, systemd, watchdog-ами й домашньою інфраструктурою для мене була радше пригодою, ніж «я зараз за вечір професійно спроєктую мережеве рішення».

Багато речей я заводив методом проб і помилок. Десь щось ламалося, десь Raspberry Pi не одразу виходила в мережу після reboot, десь роутер поводився не так, як я очікував, десь клієнти все одно намагалися ходити повз Pi-hole. І паралельно з цим я розбирався: що це дідько таке, чому DNS такий важливий, як DHCP видає налаштування клієнтам, чому secondary DNS може зламати всю ідею фільтрації, чому pihole-FTL — це серце Pi-hole, і чому «інтернет не працює» іноді означає просто «DNS не відповідає».

Мені здається, це важливий контекст. Цей проєкт не народився як ідеальна архітектура на білому аркуші. Він ріс ітеративно: поставив, перевірив, зламав, полагодив, додав healthcheck, знову зламав, додав watchdog, зробив backup, перезапустив, подивився логи, трохи посварився з роутером, знову полагодив.

І в цьому, чесно кажучи, був окремий кайф. Бо коли ти не просто копіюєш готовий гайд, а поступово розбираєшся, як воно працює, домашній pet-проєкт стає набагато ціннішим. Навіть якщо фінальний результат виглядає як маленька Raspberry Pi біля роутера, всередині там уже є купа маленьких інженерних рішень, які з’явилися саме через практичні помилки.

Тому цю статтю не варто сприймати як «еталонний network design». Це радше історія про те, як розробник не з мережевого світу взяв Raspberry Pi, Pi-hole, Telegram-бота, Codex, трохи впертості — і поступово зібрав домашню систему, яка виявилася реально корисною.

Що таке Pi-hole і чому це зручно вдома

Pi-hole — це локальний DNS-сервер із фільтрацією доменів. Якщо пояснювати максимально просто, DNS — це така телефонна книга інтернету. Пристрій питає: «де знаходиться example.com?», а DNS відповідає IP-адресою.

Pi-hole стає посередником у цьому процесі. Коли пристрій у домашній мережі хоче відкрити якийсь домен, запит іде до Pi-hole. Далі Pi-hole дивиться: якщо домен нормальний — він резолвиться. Якщо домен є у blocklist — запит блокується.

У цьому й головна зручність: блокування відбувається на рівні мережі.

Не треба ставити розширення в кожен браузер. Не треба пояснювати телевізору, що реклама — це погано. Не треба на кожному телефоні вручну щось конфігурувати. Якщо пристрій використовує домашній DNS, Pi-hole вже може фільтрувати частину небажаного трафіку.

Особливо це корисно для:

• Smart TV;
• мобільних застосунків;
• IoT-пристроїв;
• планшетів;
• гостьових пристроїв;
• пристроїв, де звичайний browser ad blocker не працює.

Але тут важливо не продавати Pi-hole як магічну кнопку «прибрати всю рекламу з інтернету». Це не так.

DNS-блокування не замінює повністю browser extension. Воно не ідеально блокує YouTube-рекламу. Воно не завжди допомагає з first-party tracking, коли аналітика живе на тому самому домені, що й основний сервіс. Частина in-app механік теж може спокійно обходити такі фільтри або працювати через домени, які не можна просто заблокувати без побічних ефектів.

Іноді, навпаки, доводиться щось розблоковувати. Наприклад, можуть ламатися окремі сервіси Apple, Apple Private Relay, Threads, YouTube API або якісь застосунки, які дуже творчо використовують аналітичні домени. Це нормальна частина життя з DNS-фільтром: іноді треба зайти в Query Log, подивитися, що саме блокується, і додати виняток.

Залізо: чому Raspberry Pi Zero 2 W

Для домашнього DNS не потрібен сервер у стійці, Kubernetes і окрема кімната з кондиціонером. Raspberry Pi Zero 2 W виявилася цілком достатньою.

Вона маленька, тиха, споживає мало енергії й може просто лежати біля роутера. У моєму випадку вона підключена по Wi-Fi 2.4 GHz. Це не роутер, не Wi-Fi access point і не пристрій, через який проходить увесь трафік. Вона просто живе в локальній мережі й відповідає на DNS-запити.

Схема приблизно така:

• Raspberry Pi Zero 2 W працює на Raspberry Pi OS Lite;
• на ній локально запущений Pi-hole;
• роутер через DHCP видає IP Raspberry Pi як DNS для клієнтів;
• телефон, MacBook, TV та інші пристрої питають DNS у Raspberry Pi;
• Pi-hole або резолвить домен, або блокує його.

Окремий важливий момент: якщо ви хочете, щоб клієнти не обходили Pi-hole, не варто ставити Google або Cloudflare як secondary DNS у роутері. Бо частина пристроїв може піти туди напряму, і тоді фільтрація буде неповною.

Тобто якщо DNS 1 — це Raspberry Pi, а DNS 2 — 8.8.8.8, то не треба дивуватися, що частина запитів оминає Pi-hole. Для клієнтів домашньої мережі краще, щоб основним DNS був саме Pi-hole.

А от для самої Raspberry Pi можна залишити зовнішній DNS. Це допомагає уникнути ситуацій, коли Pi-hole залежить сам від себе й у разі проблеми виходить DNS-loop. Домашня інфраструктура має бути простою, але не самозакоханою.

«Підключив і забув»: що довелося доробити навколо Pi-hole

Просто встановити Pi-hole — це тільки половина історії. Навіть, можливо, менша половина.

Бо домашній DNS має не просто запуститися. Він має переживати нормальне домашнє життя:

• reboot;
• вимкнення світла;
• ситуацію, коли Raspberry Pi стартує швидше за роутер;
• тимчасове зникнення Wi-Fi;
• падіння pihole-FTL;
• тимчасову відсутність інтернету;
• заповнення логів;
• проблеми з пам’яттю;
• потенційні проблеми SD-карти.

Коли DNS падає, для звичайного користувача це виглядає як «інтернет не працює». Хоча роутер живий, Wi-Fi є, провайдер працює, але сайти не відкриваються. Тому для мене головним було не просто «підняти Pi-hole», а зробити так, щоб система сама себе перевіряла й у більшості випадків могла відновитися без мого втручання.

Навколо Pi-hole я поступово доробив operational-шар.

Наприклад, додав очікування локальної мережі перед стартом важливих сервісів. Це потрібно, бо після reboot Raspberry Pi може піднятися швидше, ніж роутер повністю відновить Wi-Fi або маршрут до інтернету.

Для pihole-FTL додав systemd override з autorestart. Якщо сервіс упав — systemd має спробувати підняти його знову.

Окремо працює healthcheck timer. Він перевіряє, чи DNS реально відповідає, і якщо бачить проблему — може перезапустити FTL. Але без паніки. Один короткий збій — це ще не катастрофа. Домашній Wi-Fi іноді чхає, роутер іноді задумується, пакет може загубитися. Тому network watchdog поводиться лагідно: перевіряє Wi-Fi, маршрут, доступність інтернету й не влаштовує істерику через один packet loss.

Є bot watchdog, який стежить, що Telegram-бот живий. Є daily Gravity update, щоб списки блокування автоматично оновлювалися. Є daily cleanup о 05:00, weekly/monthly self-maintenance, hardware watchdog, RAM/OOM guard, log flood guard, SD card health guard.

Ще є safe mode. Це режим, у якому система може зупинити важкі фонові задачі, але не вимикати DNS. Бо DNS — головний сервіс. Якщо щось допоміжне створює проблеми, краще тимчасово вимкнути допоміжне, ніж покласти всю домашню мережу.

І саме тут pet-проєкт почав відчуватися не як «я поставив утиліту», а як маленька домашня інфраструктура.

Найважливіша частина pet-проєкту — не «щоб запустилося», а «щоб саме відновлювалося».

Telegram-бот: навіщо він тут

Після базового налаштування Pi-hole швидко стало зрозуміло, що постійно заходити по SSH або в web dashboard не хочеться. Хотілося мати простий інтерфейс, який завжди під рукою.

Так з’явився Telegram-бот.

Спочатку ідея була скромна: надсилати статистику. Але поступово бот перетворився на центр керування домашнім DNS.

Зараз він може надсилати щоденний звіт о 10:00 за минулу календарну добу. У звіті є статистика Pi-hole: кількість DNS-запитів, скільки заблоковано, відсоток блокування, дата й час останнього оновлення Gravity/blocklist.

Також бот показує системні метрики Raspberry Pi:

• RAM у форматі на кшталт 307/416 MB зайнято (73.8%);
• CPU;
• температуру CPU;
• навантаження по ядрах;
• диск;
• uptime;
• стан сервісів.

Окрім звітів, є кнопка статусу, повна перевірка системи, повна перевірка мережі, ручне оновлення списків Pi-hole, speedtest, локальний зашифрований backup, перегляд стану сервісів і командний режим.

Командний режим доступний тільки для owner chat ID. Сам бот приватний: якщо йому пише хтось чужий, він не показує меню, не віддає статуси й не дозволяє керувати системою. Просто відповідає, що доступ заборонено.

Для мене це важливий момент. Telegram-бот для домашньої інфраструктури — це не просто «красиве меню». Це operational layer. Маленька адмін-панель, яка дає змогу швидко зрозуміти, чи все живе, не відкриваючи ноутбук.

Telegram став простим інтерфейсом до домашнього DNS, без необхідності постійно заходити по SSH.

Щоденний звіт: що я бачу щодня

Найприємніша частина всієї системи — щоденний звіт. Він приходить о 10:00 і коротко показує, що відбувалося в мережі за минулу календарну добу.

У звіті видно:

• скільки було DNS-запитів;
• скільки з них заблоковано;
• який відсоток блокування;
• скільки доменів у blocklist;
• коли востаннє оновлювалися списки;
• який стан Raspberry Pi;
• який відсоток блокування за поточний календарний місяць.

Я спеціально хотів, щоб звіт був людяний. Не просто «raw metrics dump», а щось, що можна швидко прочитати з телефона. Бо якщо домашня система щодня шле тобі полотно логів, дуже швидко ти починаєш її ігнорувати.

А тут працює інший ефект: кожного ранку можна буквально за кілька секунд побачити, що DNS живий, блокування працює, Raspberry Pi не перегрівається, RAM не забита, списки оновлені.

Коли виявляється, що приблизно кожен п’ятий DNS-запит у домашній мережі — це реклама, аналітика або трекінг, починаєш інакше дивитися на «нормальну» роботу інтернету.

Бо це не виглядає як щось екзотичне. Це просто фон. Ти відкрив застосунок, телевізор щось перевірив, телефон прокинувся, ноутбук оновив вкладки — і ось уже десятки або сотні DNS-запитів. Частина з них корисна. Частина — не дуже.

Self-healing і безпека: щоб не прокидатися від мертвого DNS

DNS у домашній мережі — критична штука. Не в сенсі «як у банку», але в побутовому сенсі точно критична. Якщо DNS не працює, людина зазвичай не думає: «О, здається, мій локальний резолвер не відповідає». Людина думає: «Інтернет здох».

Тому я хотів, щоб система не просто слала алерти, а спочатку пробувала лагодити себе.

Базовий рівень — autorestart для pihole-FTL. Якщо FTL впав, systemd пробує його підняти.

Далі — autorepair healthcheck. Він перевіряє, чи DNS відповідає, чи можна резолвити домени, чи Pi-hole у нормальному стані. Якщо щось не так, пробує перезапустити потрібні сервіси.

Network watchdog стежить за Wi-Fi та інтернетом. Але з затримками й grace period, щоб не перезапускати все через короткий збій. Це важливо, бо домашні мережі не ідеальні. Роутер може на кілька секунд задуматися, Wi-Fi може мигнути, провайдер може коротко просісти. Якщо на кожен такий випадок реагувати як на пожежу, система сама стане джерелом проблем.

Є auto-alerts із grace period після boot. Після перезавантаження Raspberry Pi не треба одразу кричати, що все погано. Сервіси мають піднятися, Wi-Fi має підключитися, Pi-hole має стартувати, бот має ожити.

Ще одна приємна деталь — тимчасові повідомлення в Telegram. Наприклад, бот може написати, що перевірка стартувала. Якщо все добре — видалити це повідомлення. Якщо є проблема — залишити його й надіслати alert. У результаті чат не перетворюється на смітник із «усе добре, усе добре, усе добре», але проблеми не губляться.

Звучить трохи як перебір для Raspberry Pi біля роутера. Але це не enterprise і не спроба побудувати датацентр. Це просто практичний домашній resilience. Маленький набір запобіжників, щоб система не ламалася від першої ж побутової дрібниці.

Backup і rollback

Окрема тема — backup.

Домашні pet-проєкти часто живуть за принципом «та я потім розберуся». А потім ти щось міняєш, сервіс не стартує, SD-карта дивиться на тебе як на людину, яка зробила вибір, і починається археологія по shell history.

Я хотів цього уникнути.

Перед змінами створюється локальний backup. Він зашифрований і містить важливі частини системи: код бота, Pi-hole конфіги, systemd unit-и й зріз системи. При цьому зберігається тільки останній успішний архів, щоб не забивати SD-карту.

Це не криптографічний deep dive і не backup-стратегія для бізнесу. Мета проста: якщо я щось зламаю, у мене є точка відкату.

Окремо є restore drill. Це перевірка, що backup не просто «нібито створився», а реально читається й містить критичні файли. Бо backup, який жодного разу не перевіряли, — це не backup, а психологічна підтримка.

Vibe coding з Codex: як це реально відчувалося

Найцікавіша частина цього проєкту для мене — навіть не сам Pi-hole. А те, як він робився.

Майже вся робота відбувалася через vibe coding з Codex. Я не сидів і не писав усе вручну рядок за рядком. Я описував бажану поведінку системи природною мовою: що має статися після reboot, як має виглядати Telegram-звіт, які перевірки потрібні, що робити, якщо впав FTL, як обмежити доступ до бота, як запускати тести, як робити backup перед змінами.

Codex підключався по SSH до Raspberry Pi, читав існуючі файли, правив конфіги, запускав тести, перезапускав сервіси й перевіряв результат. Ми ітеративно додавали функціональність: спочатку Pi-hole setup, потім Telegram-бот, щоденні звіти, меню, speedtest, оновлення списків, backup, watchdog-и, safe mode, доступ тільки для мого chat ID, командний режим, startup checks.

Це відчувалося не як «згенеруй мені файл», а як діалог із дуже терплячим Linux/Python інженером, який не втомлюється від фрази «а тепер давай ще перевіримо, що воно переживе reboot».

Звісно, тут важливо не впадати в магічне мислення. AI може помилятися. Він може запропонувати неідеальний systemd unit, забути про edge case, занадто сміливо змінити конфіг або не врахувати конкретну поведінку Raspberry Pi OS.

Тому я намагався тримати процес у межах здорового інженерного контролю:

• перед змінами робити backup;
• після змін запускати тести;
• перевіряти systemctl status;
• дивитися логи;
• перезапускати сервіси;
• перевіряти, що DNS реально відповідає;
• не дозволяти небезпечні дії без розуміння наслідків.

Майже всі зміни проходили через цикл: зробити → протестувати → перезапустити сервіс → перевірити → тільки потім рухатися далі.

І ось це, як на мене, дуже цікава зміна в підході до pet-проєктів. AI-асистент тут був не просто autocomplete для коду. Він став pair engineer для маленької домашньої інфраструктури.

Що вийшло в результаті

У результаті Raspberry Pi Zero 2 W працює як домашній DNS-фільтр.

Pi-hole блокує рекламу, трекінг і частину аналітики на рівні мережі. Telegram-бот щодня присилає статистику. Є адмін-панель у Telegram, self-healing, watchdog-и, backup/restore drill, startup checks і тести, які запускаються при старті Raspberry Pi.

Система не відкрита в інтернет. Вона працює тільки в локальній домашній мережі. Доступ до Telegram-бота є тільки для мого chat ID. У відповідях бота є redaction секретів, щоб випадково не показати токени або чутливі значення.

Також є weekly checks і weekly reboot. Gravity/blocklist оновлюється автоматично. Додатковий health check о 22:00 мовчить, якщо все добре, і пише тільки якщо є проблема.

І це, мабуть, головне: система не вимагає постійної уваги. Вона просто працює. А коли їй щось не подобається — вона повідомляє.

Що б я порадив тим, хто хоче повторити

Я б радив починати простіше.

Спочатку просто поставте Pi-hole і добийтеся, щоб він стабільно працював як DNS для одного пристрою. Потім налаштуйте DHCP reservation у роутері, щоб Raspberry Pi завжди мала одну й ту саму IP-адресу. Потім уже вказуйте її як DNS для всієї мережі.

Не ставте Google або Cloudflare як secondary DNS у роутері, якщо хочете, щоб клієнти не обходили Pi-hole. Інакше частина запитів піде повз фільтр.

Для самої Raspberry Pi краще залишити зовнішній DNS, щоб уникнути залежності Pi-hole від самого себе.

Не відкривайте Pi-hole в інтернет. Це домашній локальний сервіс, і йому там добре. Якщо дуже хочеться мати доступ зовні — краще дивитися в бік VPN, а не виставляти адмінки назовні.

Не поспішайте з агресивними blocklist. Більше списків не завжди означає краще. Іноді це означає «чому в мене зламався застосунок банку, Threads, YouTube або щось від Apple». Почніть з базових списків, подивіться Query Log, потім поступово додавайте.

Будьте готові іноді розблоковувати домени. Це нормально. DNS-фільтрація — це баланс між чистотою й тим, щоб інтернет не перетворився на квест.

Додайте хоча б простий healthcheck. Якщо DNS став центральною точкою для всієї домашньої мережі, треба розуміти, коли він упав.

Якщо робите Telegram-бота — обмежте доступ конкретним chat ID. Не показуйте меню чужим користувачам. Не повертайте секрети в повідомленнях. Не давайте боту виконувати все підряд без обмежень.

І не забувайте про SD-карту, RAM і логи. Raspberry Pi — класна штука, але це не чарівний сервер. Логи можуть рости, SD-карта може втомлюватися, пам’яті на Zero 2 W не так багато. Краще мати прості guard-и, ніж потім дивитися на мертвий DNS.

Висновок

Це невеликий домашній pet-проєкт, але він реально вплинув на повсякденний інтернет.

Найцікавіше для мене — не саме блокування реклами. А прозорість. Ти раптом бачиш, скільки цифрового шуму генерує домашня мережа. Бачиш, як часто пристрої звертаються до рекламних, трекінгових і аналітичних доменів. І це перестає бути абстрактною темою з дискусій про privacy.

Raspberry Pi Zero 2 W виявилася достатньою для такої задачі. Pi-hole — дуже практична штука для домашньої мережі. Telegram-бот зробив керування зручним. А Codex і vibe coding перетворили весь процес на швидкий інженерний експеримент, де ідеї можна одразу перевіряти на живому залізі.

Це не enterprise-рішення. Не ідеальна система. Але як домашній DNS-фільтр із моніторингом, self-healing і бекапами — воно працює і добре.

І, мабуть, найприємніше в цьому проєкті — я починав не як мережевий спеціаліст, а як людина, якій просто стало цікаво: «а що буде, якщо домашній DNS зробити трохи розумнішим?». Виявилося, що через проби, помилки й нормальні перевірки можна зібрати штуку, яка реально працює щодня. Навіть без спец знань можна це зробити, благо сучасний світ це дозволяє.

Тепер ця маленька Raspberry Pi просто лежить біля роутера, блимає індикатором і щодня нагадує мені, що частину інтернет-шуму можна прибрати ще до того, як він потрапить на пристрої.

Дякую, що дочитали 🙌

Якщо чесно, я навіть не думав, що маленький pet-проєкт із Raspberry Pi біля роутера перетвориться на настільки цікаву домашню інфраструктуру. Але саме такі штуки, як на мене, і найкраще повертають відчуття «технічної цікавості», коли щось збираєш не тому, що треба по роботі, а тому що просто цікаво зрозуміти: «а як воно працює всередині?».

І окрема чесна примітка наприкінці: з оформленням, структурою та написанням цієї статті мені допомагав ШІ. Не в сенсі «натиснув кнопку й отримав готовий текст», а саме як інструмент, який допоміг нормально зібрати думки, структурувати досвід і не загубити важливі технічні деталі по дорозі.

Бо я добре знаю свою проблему: коли пишу великі тексти повністю «з голови», то часто перескакую між думками, втрачаю деякі аспекти або залишаю в голові речі, які мені здаються очевидними, але неочевидні для читача. Тому цього разу AI став радше редактором і співрозмовником, який допоміг перетворити купу нотаток, логів, спостережень і вечірнього «а давай ще перевіримо оце» у цілісну історію.

І, чесно, мені здається, це теж доволі цікавий аспект сучасних pet-проєктів 🙂

Можу комусь цікаво, це лого мого бота: Просто намагався якось повʼязати телеграм бота + Pi-hole + кіберпанк