Pi-hole

Материал из ALT Linux Wiki

Сервер DNS, предназначенный для домашнего и мелкоофисного использования. Блокирует нежелательную рекламу, кэширует запросы вовне, позволяет задействовать DoT для исключения зависимости от провайдерских ДНСов и подмены адресов прочими пакостниками.

Впрочем, его мнимая мелкотравчатость состоит в том, что зиждется он на ДНСмаске, априори заточенном на небольшие сети. В реале же вполне себе обслуживает сотни хостов — хватало бы памяти под кэш да места под базу (с ней отдельная история), а ядро он напрягает весьма незначительно.

Установка

Вполне уютно гнездится в непривилегированном контейнере. Но у Альта собирается лишь для Сизифа (увы!), посему поставить его можно либо в этой среде, либо пересобрав из сизифовых сырцов (например, для 11 платформы).

Потребуется три пакета: apt-get install pi-hole{,-ftl,-web}

Настройка

Практически вся производится через вебку http://ип.ад.ре.с/admin/, а примеров употребления оной внутрь не счесть на просторах интернетов. Разве что для реализации DoT (см. ниже) потребуется капелька командной строки.

DoT

Перенаправление запросов ДНС через ТЛС в обход всякого разного решается:

  1. установкой apt-get install unbound,
  2. добавлением в начало /etc/pihole/unbound/unbound.conf строки include: "/var/lib/unbound/pihole.conf",
  3. созданием означенного файла:
/var/lib/unbound/pihole.conf   
server:
access-control: 127.0.0.0/8 allow
cache-max-ttl: 14400
cache-min-ttl: 600
do-tcp: yes
hide-identity: yes
hide-version: yes
interface: 127.0.0.1
minimal-responses: yes
prefetch: yes
qname-minimisation: yes
rrset-roundrobin: yes
ssl-upstream: yes
use-caps-for-id: yes
verbosity: 1
port: 5533

forward-zone:
name: "."

## DoT providers (port 853)
# cloudflare-dns.com
# dns.google
# dns.quad9.net
# dns.adguard.com
# dns.comss.one
# dns.nextdns.io
# common.dot.dns.yandex.net

forward-addr: 77.88.1.8@853         # Yandex primary
forward-addr: 77.88.8.8@853         # Yandex secondary
forward-addr: 1.1.1.1@853           # CloudFlare primary
forward-addr: 1.0.0.1@853           # CloudFlare secondary
forward-addr: 8.8.8.8@853           # Google primary
forward-addr: 8.4.4.8@853           # Google secondary
forward-addr: 9.9.9.9@853           # Quad9.net primary
forward-addr: 149.112.112.112@853   # Quad9.net secondary
forward-addr: 208.67.222.222@853    # OpenDNS primary

Теперь нужно навсегда запустить (systemctl enable --now unbound) либо рестартануть запущенную службу.

Обязательно следует проверить доступность внешних ресурсов со свежеподнятого анбаунда: 

dig @127.0.0.1 <какой.либо.сайт> -p 5533

И если всё отрезолвилось, остаётся последний штрих к портрету — указать pi-hole использовать наш анбаунд, вставив на самый верх раскрывающегося текстового списа Custom DNS servers в разделе Главное меню ⇾ Settings ⇾ DNS строчку 127.0.0.1#5533 и перезапустив службу (systemctl restart pihole-FTL).

Нюанс с базой

Кэш-база /etc/pihole/pihole-FTL.db при немалом числе локальных инет-клиентов пухнет довольно быстро, норовя выжрать всё свободное пространство. И проблема не столько в том, что места мало (можно ж и поддать парку́), сколько в абсолютной незаточенности sqlite3 под серьёзные объёмы: формат чертовски быстр на мелких базах, но с некоего предела попросту тормозит всю систему до невозможности оперативно работать даже из командной строки ввиду того, что вся база крутится в ОЗУ.

Решается без особых хлопот.

  1. Если служба крутится в контейнере, бэкапящемся хотя бы еженедельно, то с учётом того, что контейнеры рекомендуется резервировать остановленными, а не снимком, достаточно добавить /etc/pihole/pihole-FTL.db...
    • либо в конец команды юнита /lib/systemd/system/pihole-FTL.service перед замыкающей кавычкой: 
      ExecStartPre = -/bin/sh -c '/bin/rm -f /dev/shm/FTL-* /etc/pihole/pihole-FTL.db'
    • либо отдельным /etc/systemd/system/pihole-FTL.service.d/database.conf: 
      [Service]
ExecStartPre = -/bin/sh -c '/bin/rm -f /etc/pihole/pihole-FTL.db'
    В результате чего после каждого бэкапа служба будет запускаться заново, очищая базу.
  2. Не использовать под кэширование:
    • наше новое «пихло» — для адресов в локалке,
    • внутренний ДНСмаск — для запросов наружу, указав ему это самое «пихло» в качестве форвардера (что в случае с ДНСмаском означает главный сервер, а не отдельный для зоны/сети).
  3. ДНСом для всей локальной «клиентуры» назначить внутренний ДНСмаск, ни в коем случае не указывая новое «пихло».

Не возбраняется комбинирование подходов: и нежданчика не случится, и были б кости — а кэш на них нарастёт.

Обратная связь