Добавить в корзинуПозвонить
Найти в Дзене

Некоторые мысли по поводу организации DNS-трафика в сетях с Mikrotik

Последние нововведения буквально уже прямым текстом говорят, что незащищенный DNS-трафик становится небезопасен и может потенциально принести множество проблем на ровном месте. Сегодня мы рассмотрим один из возможных вариантов в сетях с использованием в качестве шлюза роутеров Mikrotik. Ой, да что там думать, скажет иной читатель, включаем DoH и понеслась! Но не все так просто. При включении DoH перестают работать записи типа FWD, что во многих случаях неприемлемо, поэтому нужно искать другое решение. Завернуть DNS-запросы в трубу… Ну такое себе решение, скажем честно. Труба в наше время может отвалиться в любой момент, и тогда вся ваша сеть вообще окажется без DNS. Поэтому работать надо через основное подключение, но исключительно по защищенным протоколам. Сегодня в домашней сети был опробован данный вариант и результат его можно считать отличным. Мы не будем вдаваться в технические подробности, сделаем это позже, в других заметках, а обрисуем общую канву, тем более что вариатив

Некоторые мысли по поводу организации DNS-трафика в сетях с Mikrotik

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

Сегодня мы рассмотрим один из возможных вариантов в сетях с использованием в качестве шлюза роутеров Mikrotik.

Ой, да что там думать, скажет иной читатель, включаем DoH и понеслась! Но не все так просто. При включении DoH перестают работать записи типа FWD, что во многих случаях неприемлемо, поэтому нужно искать другое решение.

Завернуть DNS-запросы в трубу… Ну такое себе решение, скажем честно. Труба в наше время может отвалиться в любой момент, и тогда вся ваша сеть вообще окажется без DNS.

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

Сегодня в домашней сети был опробован данный вариант и результат его можно считать отличным.

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

Для разрешения запросов мы подняли дополнительный кеширующий DNS-сервер Unbound, но вы можете использовать любое иное решение, главное, чтобы оно умело использовать в качестве апстрима сервера DoT/DoH.

Как вы уже должны были понять, в качестве вышестоящего сервера для Unbound мы использовали один из публичных серверов по протоколу DoT.

Почему DoT, а не DoH? DoT проще в настройке и позволяет четко определять такой трафик, что полезно если вы используете сложные правила фильтрации. С другой стороны, это делает видимым такой трафик для провайдера, но доступа к нему он все равно не имеет.

Смысла прятать факт наличия DNS-трафика в зашифрованном виде особо нет, но если вы хотите скрыть такую активность, то лучше использовать DoH. В общем – на ваш выбор.

После чего в качестве используемого DNS-сервера для Mikrotik указываем адрес нашего Unbound. Для клиентов сети основным DNS как был Mikrotik, так и остался, это нужно для того, чтобы работали FWD записи и разные другие правила.

Этот режим показан на диаграмме зелеными стрелочками. DNS-запрос приходит на Mikrotik и если его не нужно перенаправлять на какой-либо специфический сервер, то он уходит на Unbound, а с него по DoT/DoH на выбранный вышестоящий DNS-сервер.

А что будет, если клиент явно укажет на своем устройстве другие DNS-сервера? Все просто, решаем при помощи правила на Mikrotik:

/ip firewall nat

add action=dst-nat chain=dstnat comment="SAFE DNS" dst-address=!192.168.1.0/24 dst-port=53 protocol=udp to-addresses=192.168.1.53

Где 192.168.1.0/24 – адрес вашей внутренней сети, а 192.168.1.53 – адрес сервера Unbound.

После чего ваш роутер будет перехватывать все транзитные DNS-запросы и отправлять их на ваш Unbound-сервер. Этот режим показан на схеме голубыми стрелочками.

Также для контроля возможной утечки DNS советуем вам на первых порах добавить в брандмауэр, на самый верх, еще два правила:

/ip firewall filter

add action=passthrough chain=output dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp

add action=passthrough chain=forward dst-address=!192.168.1.0/24 dst-port=53 log=yes log-prefix=LEAK_DNS protocol=udp

Если вдруг счетчики по этим правилам показывают значения отличные от нуля, то переходим в лог и ищем записи с префиксом LEAK_DNS по которым смотрим кто и куда пытался пойти в обход нашей схемы.

Сразу дадим одну наколку, если у вас используются коммутируемые подключения или вы получаете настройки по DHCP – обязательно снимите галочку Use Peer DNS.

Данная схема не претендует на полноту и оригинальность, но поставленную задачу она полностью решила – открытые DNS запросы более за пределы локальной сети не уходят.