Furriest 5 мая 2021 в 22:36

Настраиваем отказоустойчивость Pi-Hole в связке с Mikrotik

6 мин

39K

Сетевые технологии*

Туториал

Технотекст 2021

+16

Комментарии 19

Meklon 6 мая 2021 в 01:15

Спасибо огромное, очень интересно. Я для себя решил проблему high availability с помощью дополнительных инстансов pi-hole у родителей. Они доступны через VPN, соответственно, от DNS не зависят никак.

Furriest 6 мая 2021 в 07:25

Вполне себе вариант, конечно.
Не решает только кейс блокировки сервиса оператором — в этом случае VPN тоже разорвется и DNSов не будет.

nebularia 6 мая 2021 в 05:17

Я может чего-то не понимаю, но в чём проблема отдать в DHCP два адреса - Pi-Hole и провайдерский? Пока жив Pi-Hole будет использоваться он, иначе - провайдерский. Если не работает DoH (отключили интернет), то в настройках ресолвера на пишке прописываем вторым провайдерский DNS, запросы идут на него.

Furriest 6 мая 2021 в 07:32

Вы немного оптимистично ожидаете от клиентов, что они будут использовать «всегда первый, а если он недоступен — то второй». Логика использования нескольких DNS не стандартизована никак. Некоторые клиенты любят раунд-робин между DNSами и тогда каждый второй запрос будет улетать в провайдера мимо блокировок рекламы на Pi-Hole. А некоторые (например, XP — хотя понимаю, что некро, но это пример в котором я точно уверен) вообще не умели соскакивать с первого сервера, даже если он недоступен.

Чтобы поведение было предсказуемым — лучше управлять им самостоятельно.

Busla 6 мая 2021 в 12:03

Mikrotik из коробки умеет DoH и Conditional Forwarding DNS-запросов. VRRP, соответственно, не нужен. Ради только DNS over HTTPS и Pi-Hole не нужен.

Furriest 6 мая 2021 в 12:09

Умеет. Но плохо. На практике проблемы с DoH на микротике в 6.47 ветке были такие, что из продакшна это решение мне пришлось вывести.

Но если у вас всё хорошо работает — да кто ж заставляет-то уходить на другое. Мир гораздо разнообразнее, чем вам кажется, и кому-то нужен и VRRP. Например, мне.

mmaks17 6 мая 2021 в 12:14

аналогично переключать на другой днс можно встроенными средствами. например таким скриптом в шедулере

mmaks17 6 мая 2021 в 12:16

:local mydns [/ip dns get servers]



:do {

 /resolve ya.ru server=10.10.5.110

 :if ( $mydns ~ "8.8.8.8" ) do={ 

 /ip dns set servers=10.10.5.110 

 :log info dns_come_back_check

 }

 

 } on-error={

:log info error_dns_check

/ip dns set servers=8.8.8.8

/ip dns cache flush

 }

Furriest 6 мая 2021 в 12:20

Можно, конечно. Практически любую задачу можно решить несколькими способами, каждый из которых будет иметь свои преимущества и недостатки.

eps 6 мая 2021 в 14:45

Опять же, подойдет и OpenWRT

Если у вас OpenWRT, то для блокировки рекламы можно пользоваться adblock из opkg, и точек отказа сразу станет меньше

Terranz 7 мая 2021 в 11:47

Добрый день, реализовал это как вы пишете, на микротик и малинке
Но ночью получил в логе микротика

vrrp-dns now MASTER, master down timer

и днс перестал резолвиться
Хотя всё было онлайн и живое.
Есть предположения, что могло пойти не так?

Terranz 7 мая 2021 в 13:24

Ок, я разобрался почему сам микротик не резолвил когда отъехал мастер с малинки, но почему он отъехал, пока не разобрался.
На микротике в фаерволе надо было разрешить траффик с vrrp-dns интерфейса

Furriest 7 мая 2021 в 13:31

Ну если всё было реализовано по статье - то, возможно, что-то случилось с резолвером. Можно поиграть с rise - fall, чтобы таймаут стал побольше.

Rosti 4 июн 2021 в 08:21

да, была та-же проблема. DNS на новом адресе на майкротике не работал.
DNS на основном IP майкротика работал.
добавил udp/53 для входящих/выходящих для нового dns адреса.

Furriest 4 июн 2021 в 08:23

Да, понятно, что на сильно пережатом файрволе нужно не забыть разрешить сервис. Добавлю в статью.

vaultkeeper 4 окт 2021 в 11:50

Тоже столкнулся с тем, что произошло:

vrrp-dns now MASTER, master down timer

после расследования до 4 утра выяснил, что глюк в keepalived, который предоставляется в репо (в моем случае raspbian buster). Глюк заключается в том, что спустя рандомное время keepalived перестает выполнять скрипт проверки доступности домена (check_dns.sh) ну и на микрот улетает инфа что я не резолвлю, давай ты мастером будь.

Был пофикшен в рамках https://github.com/acassen/keepalived/issues/1364

Лечение:

удаляем тот keepalived что мы установили и делаем:

sudo apt update

sudo apt install snapd

sudo snap install core

sudo snap install keepalived --classic

Ребутаемся и радуемся жизни :)

Furriest 3 мая 2022 в 21:33

В свежие версии keepalived еще имеет смысл дописать в global_defs опцию max_auto_priority с каким-нибудь положительным значением - она помогает в случае загруженности сервера избежать скачков сервиса из-за таймаутов.