Mikrotik настройка dns doh
Обновлено: 06.07.2024
Всем замечательно это решение, но у него есть один нюанс. Если вдруг у нас закончились деньги на счету у оператора связи или по каким-то другим причинам пропал канал связи до внешнего мира, мы даже не сможем пополнить счет, чтобы восстановить сервис, потому что не будет работать DNS. Или, например, если наш Pi-Hole по каким-то причинам перестал работать - вот вроде и вся сеть работает, и гугл пингуется, а пока не пропишешь другой DNS-сервер - не будет счастья. А если вы еще в этот момент заняты чем-то другим и не можете приступить к восстановлению незамедлительно - домашние негодуют, портят радостное существование своими жалобами и даже котики, чуя общую нервозность, стремятся нагадить вам в тапки.
Огорчать котиков - дело последнее, поэтому в этой статье я опишу, как вы можете внедрить автоматическое переключение с использования Pi-Hole на использование операторских (как, впрочем, и любых других) DNS при проблемах на Pi-Hole.
Настраиваем автоматическое переключение DNS-сервиса между Pi-Hole и Mikrotik, используя протокол VRRP в реализации демона keepalived.
Никаких волшебных know-how не открывается, простая пошаговая инструкция для тех, кому не хочется разбираться во всех хитросплетениях самому.
Что вам для этого потребуется
Внедренное решение Pi-Hole из предыдущей статьи. Понятно, что описываемое решение можно использовать для отказоустойчивости в принципе чего угодно, но в данном конкретном случае мы сосредоточимся на именно этой реализации. Базовый Linux у решения - Ubuntu.
Маршрутизатор Mikrotik в качестве бордера. Опять же, подойдет и OpenWRT, и EdgeRouter, и какой-нибудь софтовый на PC, но рассмотреть всё разнообразие в статье не получится никак. Если ваш роутер поддерживает VRRP - он сможет быть частью этого решения, а как конкретно его настраивать, если возникнут сложности, спросите в комментариях к посту. Впрочем, если ваш роутер VRRP не поддерживает - можно всё то же самое построить между двумя Pi-Hole или Pi-Hole и другим DNS-сервером.
Исходные данные
IPv4-адрес нашего сервера Pi-Hole в домашней сети: 192.168.1.10 и он назначен как статический.
IPv4-адрес нашего маршрутизатора в домашней сети: 192.168.1.1 и он назначен как статический на интерфейсе bridge маршрутизатора.
Новый IPv4-адрес DNS: 192.168.1.9
Настройки на Linux выполняем от root (т.е. перед началом настройки выполняем команду sudo -i).
Логика решения и немного теории
Чтобы не превращать статью в совсем уж деревянную инструкцию "нажмите третьим пальцем левой руки на кнопку W", расскажу самую базовую теорию того, что мы пытаемся сделать.
В случае VRRP все устройства, входящие в группу, анонсируют себя через рассылку мультикаст-пакетов на адрес 224.0.0.18, внутри которых передается множество технической информации. Из нее нам важен один параметр - приоритет. Логика простая - все устройства, входящие в группу, меряются приоритетом, у кого длиннее больше, тот и победил и приземлил на себя виртуальный IP группы. Остальные сидят в засаде и ждут, пока победитель зазевается и умрет (перестанет слать нужный мультикаст), в этом случае опять проходят выборы и опять побеждает устройство с наибольшим приоритетом. Если устройств с одинаковым приоритетом несколько - побеждает больший IP-адрес, но хорошим тоном считается таких ситуаций избегать и разруливать приоритеты явно.
Большим плюсом для нас является возможность изменять приоритет на ходу. У Cisco используемая для этого фича, например, называется Enhanced Object Tracking. Но она такая есть у любой известной мне имплементации протокола, в том числе и у линуксового демона.
На основе этой фичи вырисовывается логика всей нашей конструкции:
Настраиваем на нашем маршрутизаторе в качестве основных DNS сервера провайдера
Настраиваем между маршрутизатором и Pi-Hole VRRP с приоритетами 100 на маршрутизаторе и 90 на Pi-Hole
Создаем на Pi-Hole скрипт, проверяющий работоспособность DNS и при успешности повышающий приоритет на Pi-Hole до 110
Раздаем домашним клиентам по DHCP наш виртуальный IP-адрес как адрес DNS.
Настройка
1. Настройка DNS на Mikrotik
Если помните, в предыдущей статье мы много обсуждали, какой адрес DNS раздавать клиентам и куда форвардить запросы с маршрутизатора. Для целей же нашего нового решения важно на маршрутизаторе указать в качестве DNS-серверов именно сервера нашего провайдера - чтобы они оставались доступны при блокировке сервиса за неуплату, например. Поэтому или настраиваем получение DNS от оператора по DHCP, или идем в Winbox по пути IP - DNS и в поле Servers прописываем адреса DNS-серверов провайдера.
2. Настройка VRRP на Mikrotik
Создаем новый VRRP интерфейс с привязкой к интерфейсу Bridge и навязываем на него наш виртуальный адрес. Можно сделать в Winbox, но гораздо проще сделать это в терминале:
Здесь vrrp-dns - это имя интерфейса (можете выбрать любое на свой вкус, главное совпасть в обеих командах), vrid - ID группы, можно тоже выбрать любой в диапазоне 1-255, нужно совпасть на обоих устройствах. Имя интерфейса bridge и IPv4-адреса нужно скорректировать под вашу домашнюю сеть.
После выполнения этого действия можно попинговать 192.168.1.9 - он уже должен отвечать с маршрутизатора, если пинг не закрыт файрволом.
3. Настройка VRRP на Pi-Hole
Устанавливаем демон keepalived:
Создаем файл конфигурации демона /etc/keepalived/keepalived.conf:
Здесь обратите внимание на имя интерфейса, на котором сейчас работает Pi-Hole - в примере дефолтное ens160, у вас может быть другое (проверить можно, например, через команду ifconfig).
Создаем скрипт проверки живости DNS /etc/keepalived/check_dns.sh:
и не забываем сделать его исполняемым:
Теперь достаточно перезапустить сервис:
и всё заработает. В логе Mikrotik можно будет увидеть запись, подобную этой:
Вы можете проверить, что теперь на адресе 192.168.1.9 отвечает Pi-Hole, самый простой способ проверки - это резолвинг имени pi.hole:
Обратите внимание, что резолвиться будет в адрес сервера Pi-Hole, а не в наш виртуальный IP - это правильно и так и должно быть.
4. Настройка DHCP на Mikrotik
Ну и наконец нам надо научить DHCP-сервис Mikrotik раздавать клиентам правильный адрес DNS. Это удобнее сделать из WinBox - там вы увидите все свои пулы. Идем по пути IP - Networks, смотрим глазами на все сети, которые у вас связаны с Pi-Hole сейчас и изменяем поле DNS Servers с адреса Pi-Hole 192.168.1.10 на виртуальный адрес 192.168.1.9.
Обновляем аренду адреса на компьютерах, проверяем, что получили правильный адрес DNS, проверяем, что резолвинг работает (например, командой nslookup pi.hole - уже без прямого указания имени используемого сервера). Радуемся.
Особо ответственные могут каким-либо образом сломать своему DNS-серверу резолвинг и проконтролировать, что по истечении таймаута виртуальный адрес переползет на Mikrotik. Но это уже зависит от вашей фантазии.
Заключение
Как обычно, никаких особых тайн не открыл, но для тех, кто не сталкивался с отказоустойчивостью сервисов, надеюсь, подсказал новый путь улучшения вашей домашней сети. Конечно, решение можно менять под себя в широком диапазоне вариантов, от него скорее можно отталкиваться при появлении каких-то близких по логике задач.
Главное помните в production есть место только long-term релизам, не о каких stable и тем более testing не идёт и речи.
Сегодняшняя тема пойдёт о функционале DoH который перекочевал из ветки testing в stable.
Для чего DoH необходим или нужен?
Для чего провайдеры это делают?
Именно для того чтобы ваши запросы не мог перехватить и подменить кто-то третий, была придумана реализация DoH. Но здесь есть обратная сторона медали, если вы использовали ДНС сервера провайдера или позволяли перехватывать трафик провайдеру, то только провайдер знал куда вы реально ходите в интернет на какие адреса. А когда вы будете использовать публичные ДНС сервера DoH например Гугл, то это значит, что теперь Гугл будет знать куда вы ходите и будет вам подсовывать соответствующую рекламу. тут исключительно дело вкуса.
Есть ещё одна сторона, третья, допустим ваш клиент это известный человек в публичном пространстве или просто успешный человек с финансовым достатком и конечно человек семейный, и он любит ходить "на лево", отследить по ДНС запросам значительно проще провайдеру так как он знает, какой реально человек стоит за запросом, и согласитесь если запросы идут, сначала на сайты знакомств\досуг, а потом Цветы, гостиницы и тд.. можно провести некую параллель, а теперь представьте такая информация досталась Васе Пупкину сотруднику провайдера, который недоволен жизнью, зарплатой и личной жизнью, и решил "по легкому срубить бобла". Публичному серверу это будет сделать значительно сложнее в виду огромного количества запросов и сложностью сопоставления с реальным человеком, хотя и возможно. Отдельным особняком стоят люди которые имеют доступ к секретной\закрытой информации или могут принимать управленческие решения в гос-ве, в таком случае может быть всё наоборот.
Что-то далеко ушёл.
И так начнём.
DoH стандартизирован и работа с ним описана в документа RFC8484
Мы разберём на примере двух серверов.
Первым делом нам необходимо выяснить по какому url необходимо отправлять запросы, привожу список страниц на которых указаны url для запросов.
И сами урл-ы, чтобы вам лишний раз не лазить.
На данный момент MikroTik поддерживает только один сервер, но прелесть в том, что, так как к ДНС серверу мы обращаемся по доменному адресу, DoH провайдеры могут сделать DNS-RR для данных записей A записей и они будут зарезервированный ну или могут смениться без перенастройки оборудования с вашей стороны. Вы только представьте если завтра Гугл скажет, что они решили изменить 8.8.8.8 на 8.8.9.9 мир рухнет =).
Установим сервер и обязательно поставим галочку отвечающую за то, что будет проверяться SSL сертификат сервера, иначе прилетит ответ с не валидным сертификатом от провайдера "и пиши пропал", начинай всё сначала.
Либо вариант через CLI
А так же для резольвинга самой записи нам понадобиться любой ДНС сервер, можно от провайдера можно от гугла это без разницы.
Сразу проверим работу DNS
Как видите запрос не прошёл, посмотрим кэш
Видим, что в КЭШ только адрес нашего DoH сервера, после того как вы указали DoH сервер резольвиться адрес с помощью обычного ДНС сервера будет только адреса DoH серверов.
Почему не работает?
Дело в том, что мы установили параметр verify-doh-cert что означает проверять SSL сертификат, но сверять сертификат RouterOS не с чем и некому доверять так как в RouterOS нет корневых сертификатов центров сертификации, по народному CA.
Как узнать какой CA нужно установить?!
Очень просто, нам необходимы выяснить какой CA выдал сертификат.
Вы найдёте на просторах уже инструкции, что можно скачать сам сертификат основной который висит на сайте, на сомом деле это не обязательно, можно скачать CA сертификат который подписал непосредственно данный сертификат или подписал CA которых стал промежуточным CA и подписал конечный сертификат. Проще, скачать и доверять самому верхнему сертификату в цепочке. Единственный какой может быть тут подвох, в том, что у таких сертификатов отсутствует CRL пусть к проверке отозванных сертификатов, но мы не будет сейчас затрагивать данную тему.
Unix-like
Для тех у кого unix-like обратите внимание, что сервер указывается два раза. В параметре -servername и -connect с портом 443.
Нас интересует владелец и видим что его выдал DigiCert
Windows
Для тех у кого WIndows идём в
и открываем адрес Doh сервера допустим хромом и смотрим какой сертификат, а точнее кто выдал видим что это DigiCert
Идём в Гугл и находи сайт CA DigiCert и по ключевому слову download ищем страницу загрузки CA сертификатов, находим нужный сертификат, качаем.
Прежде чем копировать сертификат на Микротик, откройте (не устанавливайте) его в вашей операционной системой и убедить, что ему ОС доверяет, если не доверяет значит вы скачали не то или не оттуда.
Если всё хорошо, скопируйте сертификат на Микротик и выполните команду импорта сертификата
Всё должно работать, проверяем.
Настоятельно рекомендую не пользоваться скриптами из интернета, всё, что касается сертификатов, сделайте пару раз руками, дальше пойдёт как по маслу. Если вы ещё не готовы понимать того, что написано в скрипте, то откажитесь от автоматической генерации и скачивании сертификатов, особенно если там встречаются короткие ссылки который по факту непонятно куда могут привести и не понятно какой сертификат скачать.
Я специально не привожу готовые сертификаты а только ссылки на них, пожалуйста убедитесь что вы скачиваете сертификаты именно с нужного сайта (наш сайт тоже могут ломануть =)) )
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор - официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
Чтобы понять суть проблемы незащищенного DNS немного углубимся в историю: на заре формирования глобальной сети интернет в том виде, в каком мы ее знаем встал вопрос использования простых и запоминающихся имен вместо цифровых адресов. Для того чтобы решить эту задачу был создана система DNS, которая должна была хранить соответствия имен цифровым адресам и сообщать их, получив запрос по специальному протоколу. Со временем возможности DNS росли и расширялись, но основной функцией по-прежнему остается сопоставление доменных имен IP-адресам, это одна из ключевых служб современного интернета, обойтись без нее невозможно.
В далеком 1987 году, когда принимались первые спецификации DNS вопросы безопасности были далеко не на первом месте и поэтому протокол дожил до наших дней практически в первозданном виде, передавая данные без какой-либо защиты. Чем это чревато? Давайте посмотрим.
Мы развернули в нашей виртуальной лаборатории небольшую сеть, которая выходит в интернет через виртуальный роутер Mikrotik. Вышестоящим узлом для него (читай - провайдером) является наш домашний роутер, с которого мы сняли дамп проходящего трафика. Даже беглого взгляда хватает, чтобы понять - вся интернет жизнь абонента как на ладони.
При этом, обратите внимание, абонент не использовал DNS-сервера провайдера, а работал с публичными серверами Google, но все равно провайдер имеет полную картину запросов пользователя. Эта же самая информация доступна каждому промежуточному узлу, через который проходит абонентский трафик.
- Позвольте, - скажет иной пользователь, - но мне нечего скрывать!
К сожалению, это не так. Информацию на основе ваших DNS-запросов могут использовать в рекламных целях и далеко не факт, что это будет ненавязчивая реклама в браузере. Кроме того, она позволяет составить достаточно наглядную картину вашей интернет-деятельности и далеко не все ее эпизоды вы захотите сделать общественным достоянием. Причем речь тут даже не о каких-то порочащих моментах, но вряд ли широкой общественности надо знать, что вы храните деньги в банке А и регулярно делаете покупки на площадке Б.
Поэтому сокрытие данной информации - это вопрос личной цифровой безопасности, а не попытка скрыть какие-либо неприглядные факты, тем более что провайдер может легко сопоставить такие запросы с реальной личностью: IP-адрес - номер договора - ФИО - адрес - паспортные данные.
В RouterOS возможность использовать DoH появилась начиная с версии 6.47, но в ней имеется ряд уязвимостей, которые могут привести к утечке DNS, поэтому минимальной версией для DoH следует считать 6.47.1.
Следующий вопрос - какие сервера DoH использовать? Мы рекомендуем крупных публичных провайдеров, благо есть из чего выбирать, ниже приведены провайдеры и URL-адреса DoH серверов:
Здесь возникает один интересный парадокс: DoH-сервер указан в виде URL, и чтобы достичь его нам нужно будет выполнить разрешение имен на обычном DNS-сервере. Поэтому в настройках выше у вас должен быть указан хотя бы один DNS-сервер. Наиболее правильно будет не трогать текущие настройки DNS, так как при указании DoH все запросы будут автоматически направляться к нему. Таким образом ваш провайдер будет знать, что вы используете DoH, но ваша интернет активность будет от него полностью скрыта.
Вроде бы все настроено правильно, но после применения данных настроек доступ в интернет на клиентах пропадет. А в качестве причины будет указана невозможность разрешения DNS-запросов.
Но почему сертификат не проходит проверку? Да потому что RouterOS не имеет возможности ее выполнить. Для того чтобы проверить валидность сертификата нам потребуется корневой сертификат центра сертификации (CA), во "взрослых" ОС такие сертификаты хранятся в защищенном системном хранилище и обновляются средствами системы, в RouterOS нам нужно добавить такие сертификаты самостоятельно.
Для работы с Google Public DNS нам потребуется корневой сертификат GlobalSign Root CA - R2, а для остальных провайдеров - DigiCert Global Root CA, формат скачиваемых сертификатов - PEM.
Данные сертификаты следует скопировать на Mikrotik и находясь в System - Certificates выполнить их импорт.
Корневые сертификаты CA не являются секретными, но именно они отвечают за доверие ко всем выпущенным этим удостоверяющим центром сертификатам, поэтому скачивайте их только с официальных источников (на нашем сайте ссылки именно оттуда) и обязательно проверяйте контрольные суммы, которые отображаются в колонке Fingerprint на Mikrotik.
После того, как мы импортируем корневой сертификат доступ во всемирную сеть появится. А что теперь у нас видит провайдер? Снова снимем дамп трафика на промежуточном роутере и изучим его. На этот раз не густо, единственное что можно узнать - это то, что мы используем DoH от Cloudflare.
Как видим - настроить DoH не сложно, но это позволить поднять защиту приватной информации на качественно новый уровень. Надеемся, что данный материал окажется вам полезен, также всегда готовы к вашим вопросам в комментариях.
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор - официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
В использовании данной технологии есть клиент и сервер. Так вот, клиентская часть реализована в RouterOS с версии 6.47. Mikrotik не может быть DoH сервером.
Настройка DoH
Перед включением необходимо определиться, какой сервис вы будите использовать. На сегодняшний день их достаточно и выбрать есть из чего, так же вы может быть захотите свой сервер поднять. Из общедоступных есть следующие:
В примере я буду использовать проверенный временем Cloudflare. Они обещают не передавать аналитику третьим лица.
Открываем IP – DNS и вставляем строку резолвера в Use DoH Server
Обязательно ставим галочку Verify DoH Certificate.
Попробуем проверить работу по новой технологии через nslookup.
Так же видно, что в кэше тоже ничего нет. В чем может быть причина? Правильно в сертификате!
Импорт сертификатов
RouterOS ничего не знает о сертификате Cloudflare и о других, т.к. в него не импортированы корневые публичные ключи глобальных CA и по этому он не может выстроить доверие. Допустим в ОС Windows они уже идут в составе и добавляются / удаляются с обновлениями.
Прежде чем импортировать корневой CA вам нужно понять, кем был выпущен сертификат для одного из сервис-провайдеров. Допустим, для моего примера выпустил DigiCert.
Качаем его публичную часть по этой ссылке. Делаем его Upload на девайс, после в System – Certificates импортируем.
Проверим снова разрешение имён
Теперь все отлично. Как вы видите, ничего сложного нет, выбираем сервис, который вам больше нравится, прописываем его в настройках и импортируем CA того, кто выпустил вашему сервису сертификат, и все на этом настройка DoH на MikroTik завершена.
89 вопросов по настройке MikroTik
Вы хорошо разбираетесь в Микротиках? Или впервые недавно столкнулись с этим оборудованием и не знаете, с какой стороны к нему подступиться? В обоих случаях вы найдете для себя полезную информацию в курсе «Настройка оборудования MikroTik». 162 видеоурока, большая лабораторная работа и 89 вопросов, на каждый из которых вы будете знать ответ. Подробности и доступ к началу курса бесплатно тут.
Читайте также: