Как завернуть DNS трафик через VPN на mikrotik?
Настроен DNS сервер на микротике, поднят L2TP/IPSec клиент на микротике. На сервере микротика и на сервере L2TP/IPSec указан 8.8.8.8. На клиентских машинах указан DNS микротика.
Как проверить, идут ли запросы через туннель или через провайдера? И как можно завернуть DNS запросы в туннель.
делаешь на клиенте nslookup google.com и смотришь какой ip тебе отвечает.
Запросы идут по маршруту так же , как и все остальные пакеты. Те после того, как ты сделал nslookup google.com, ты можешь от traceroute ip днс сервера и увидеть, как идут пакеты.
Нихрена не понятно, что ты тут написал по сетке. Кто куда подключен и как. Но скорее всего у тебя будет так: клиент запрашивает микротик , микротик сам запрашивает 8.8.8.8 и отдает ответ клиенту. Если клиенту чтобы запросить микротик надо направлять запрос по vpn , значит по vpn. VPN это не что-то особенное, это просто еще один канал. Как прописана маршрутизация, так пакеты и идут.
Извините, что сумбурно выразился. Все будет работать так, как вы написали. Так и работает давно, но сейчас еще и туннель добавился. Сделать nslookup пока не могу, доступа пока нет.
Просто замечал, что многие при такой схеме (клиент запрашивает микротик , микротик сам запрашивает 8.8.8.8 и отдает ответ клиенту) маркируют пакеты на 53 порт.
Все равно не особенно понятно. Распишите подробнее схему сети и задачу.
Нужно абсолютно всё с рабочих мест заворачивать в туннель. На рабочих местах в DNS указан адрес роутера. Вечером проверю nslookup и traceroute
Ну дык и добавьте для destination 8.8.8.8 маршрут через ваш туннель. На самом микротике ясен пень.
Условная переадресация DNS-запросов на MikroTik
Когда используется MikroTik с настроенным vpn между офисами, столкнулся с проблемой переадресации DNS-запросов на внутренний сервер имён. Существует DNS-сервер, который автоматически разрешает имена сайтов на другом конце туннеля. Однако, если вы запрашиваете DNS-запись для внутреннего домена, например – microfin.local, на другом конце, маршрутизатор MikroTik попытается преобразовать запрос через собственный DNS-сервер, который, не имеет необходимой информации.
Итак, VPN между маршрутизаторами поднят, маршруты добавлены, по ip-адресам все пингуется в обе стороны нормально. Попытки пинговать по именам заканчиваются неудачей.
Используемые данные для решения задачи:
Внутренний IP адрес маршрутизатора MikroTik (192.168.24.1), он же указан в качестве DNS-сервера на той стороне
IP адрес внутреннего DNS сервера (192.168.23.5)
Имя локального домена (domain.local)
После этого требуется перезагрузка RouterOS. После перезагрузки получаем нужный результат
Условная переадресация DNS-запросов на MikroTik
MikroTik
Научиться настройке MikroTik можно на онлайн курсе по оборудованию этого производителя. Автор курса является сертифицированным тренером MikroTik. Подробней Вы можете прочитать в конце статьи.
Вводная информация DNS forwarding
Если используете маршрутизатор MikroTik с настроенным VPN между офисами, вероятно приходилось сталкиваться с проблемой переадресации DNS-запросов на внутренний сервер имён. Существует DNS-сервер, который автоматически разрешает имена сайтов на другом конце туннеля. Однако, если вы запрашиваете DNS-запись для внутреннего домена, например, company.ru, на другом конце, маршрутизатор MikroTik попытается преобразовать запрос через собственный DNS-сервер, который, очевидно, не имеет необходимой информации. Разберемся с проблемой DNS forwarding более детально.
У вас всегда есть возможность создавать записи вручную в файле хостов или добавлять ручные записи на ваш DNS-сервер, однако, если количество сайтов является значительным, это может превратиться в настоящую проблему, не говоря уже о том, что ваши записи не будут обновляться в случае изменения записей DNS на корпоративном сервере.
Как ни странно, у Микротика нет простого решения для условной пересылки DNS или пересылки DNS-запросов для определенного домена на конкретный сервер, однако мы сможем решить данную задачу с помощью командной строки.
Буду считать, что читатель знаком с командной строкой Mikrotik и нет необходимости расписывать используемый функционал, – это выходит за рамки этой публикации. В решении мы будем работать на 7 уровне сетевой модели OSI или прикладном уровне.
Прежде чем начать, вам понадобится следующая информация:
- Внутренний IP адрес вашего маршрутизатора MikroTik (172.16.100.1 в моем случае)
- IP адрес внутреннего DNS сервера (10.100.100.2 в моем случае)
- Имя внутреннего домена (mycompany.ru в моем случае)
- Доступ к маршрутизатору Микротик по протоколу ssh
Приступим к решению
1. Откройте текстовый редактор, например, notepad и вставьте следующие команды:
2. В списке команд выше необходимо изменить внутренний IP-адрес вашего маршрутизатора (зеленый цвет), имя внутреннего домена (оранжевый цвет) и адрес внутреннего DNS сервера (синий цвет) в соответствии с вашими настройками в текстовом редакторе.
3. Откройте ssh-сеанс на маршрутизаторе MikroTik и вставьте отредактированное содержимое текстового редактора в командную строку.
4. Перезагрузите маршрутизатор, чтобы изменения вступили в силу
Поиск неисправностей
Нам необходимо проверить, сможем ли попасть на сайты интрасети с другой стороны VPN. Если вы не можете, убедитесь, что туннель vpn запущен и работает, и что сайты действительно доступны через их внутренние IP-адреса, например, проверка по ping-протоколу нашего DNS-сервера 10.100.100.2. Следующим шагом является устранение проблемы с разрешением DNS при помощи таких команд, как nslookup. Сначала убедитесь, что DNS-сервер с другой стороны туннеля отвечает на запросы NS, выдавая команду:
где 10.100.100.2 DNS-сервер Интранета.
После приглашения > введите имя одного из ваших сайтов интрасети, и сервер имен должен сообщить его IP-адрес:
Если проверка проходит, то это означает, что туннель и DNS-сервер работают как нужно. Проверим перенаправление запросов через наш маршрутизатор, для этого выполним команду на клиентском устройстве:
где 172.16.100.1 — внутренний IP-адрес нашего маршрутизатора MikroTik.
Если результат не совпадает с вышеописанным, необходимо вернутся к списку команд в текстовом редакторе и убедитесь, что всё введено правильно. Исправьте ошибки и попробуйте еще раз.
MikroTik: куда нажать, чтобы заработало?
При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс « Настройка оборудования MikroTik ». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.
Записки IT специалиста
Настраиваем использование DNS over HTTPS (DoH) на роутерах Mikrotik
- Автор: Уваров А.С.
- 08.01.2021
Наша жизнь с каждым днем все сильнее уходит в интернет: мы используем его для работы, проводим в нем финансовые операции, делаем покупки, общаемся с коллегами и родными. Поэтому на первый план все более выходят вопросы безопасности и конфиденциальности. Основная тенденция последних лет — переход на защищенные протоколы и уже сегодня использование HTTPS является обязательной нормой, но оставалось еще одно слабое звено — протокол DNS, данные в котором передавались открытым текстом. Устранить этот пробел призван новый протокол DNS over HTTPS (DoH), поддержка которого появилась в RouterOS.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Чтобы понять суть проблемы незащищенного DNS немного углубимся в историю: на заре формирования глобальной сети интернет в том виде, в каком мы ее знаем встал вопрос использования простых и запоминающихся имен вместо цифровых адресов. Для того чтобы решить эту задачу был создана система DNS, которая должна была хранить соответствия имен цифровым адресам и сообщать их, получив запрос по специальному протоколу. Со временем возможности DNS росли и расширялись, но основной функцией по-прежнему остается сопоставление доменных имен IP-адресам, это одна из ключевых служб современного интернета, обойтись без нее невозможно.
В далеком 1987 году, когда принимались первые спецификации DNS вопросы безопасности были далеко не на первом месте и поэтому протокол дожил до наших дней практически в первозданном виде, передавая данные без какой-либо защиты. Чем это чревато? Давайте посмотрим.
Мы развернули в нашей виртуальной лаборатории небольшую сеть, которая выходит в интернет через виртуальный роутер Mikrotik. Вышестоящим узлом для него (читай — провайдером) является наш домашний роутер, с которого мы сняли дамп проходящего трафика. Даже беглого взгляда хватает, чтобы понять — вся интернет жизнь абонента как на ладони.
При этом, обратите внимание, абонент не использовал DNS-сервера провайдера, а работал с публичными серверами Google, но все равно провайдер имеет полную картину запросов пользователя. Эта же самая информация доступна каждому промежуточному узлу, через который проходит абонентский трафик.
— Позвольте, — скажет иной пользователь, — но мне нечего скрывать!
К сожалению, это не так. Информацию на основе ваших DNS-запросов могут использовать в рекламных целях и далеко не факт, что это будет ненавязчивая реклама в браузере. Кроме того, она позволяет составить достаточно наглядную картину вашей интернет-деятельности и далеко не все ее эпизоды вы захотите сделать общественным достоянием. Причем речь тут даже не о каких-то порочащих моментах, но вряд ли широкой общественности надо знать, что вы храните деньги в банке А и регулярно делаете покупки на площадке Б.
Поэтому сокрытие данной информации — это вопрос личной цифровой безопасности, а не попытка скрыть какие-либо неприглядные факты, тем более что провайдер может легко сопоставить такие запросы с реальной личностью: IP-адрес — номер договора — ФИО — адрес — паспортные данные.
Чтобы избежать раскрытия данных о DNS-запросах был реализован протокол DNS over HTTPS (DoH), который осуществляет взаимодействие с DNS-серверами по защищенному HTTPS-каналу, что исключает перехват запросов, теперь о вашей интернет активности будете знать только вы и DNS-сервер.
В RouterOS возможность использовать DoH появилась начиная с версии 6.47, но в ней имеется ряд уязвимостей, которые могут привести к утечке DNS, поэтому минимальной версией для DoH следует считать 6.47.1.
Следующий вопрос — какие сервера DoH использовать? Мы рекомендуем крупных публичных провайдеров, благо есть из чего выбирать, ниже приведены провайдеры и URL-адреса DoH серверов:
Для настройки DNS over HTTPS перейдем в IP — DNS и внесем в поле Use DoH Server URL-адрес одного из DoH-серверов, в нашем случае это Cloudflare. Также обязательно установим флаг Verify DoH Certificate.
Здесь возникает один интересный парадокс: DoH-сервер указан в виде URL, и чтобы достичь его нам нужно будет выполнить разрешение имен на обычном DNS-сервере. Поэтому в настройках выше у вас должен быть указан хотя бы один DNS-сервер. Наиболее правильно будет не трогать текущие настройки DNS, так как при указании DoH все запросы будут автоматически направляться к нему. Таким образом ваш провайдер будет знать, что вы используете DoH, но ваша интернет активность будет от него полностью скрыта.
Вроде бы все настроено правильно, но после применения данных настроек доступ в интернет на клиентах пропадет. А в качестве причины будет указана невозможность разрешения DNS-запросов.
В чем же дело? А дело в флаге Verify DoH Certificate, который предписывает роутеру проверить предъявляемый DoH сертификат. Можно, кончено, обойтись и без проверки, но это позволит любому злоумышленнику перехватить запрос и отправить собственный ответ, который будет принят роутером, что сведет на нет весь смысл защиты DNS с помощью HTTPS.
Но почему сертификат не проходит проверку? Да потому что 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. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 