Dns mikrotik static: Расширенная настройка DNS и DHCP в роутерах Mikrotik

DNS в Mikrotik — Делюсь опытом

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

Итак, начнем. Если вы используете winbox, то первый этап выполняется в несколько кликов: IP->DNS. В появившемся окне указываете серверы пересылки, не забыв при этом поставить галку «Allow remote requests».

…или в терминале выполнить

/ip dns
set allow-remote-requests=yes servers=77.88.8.8,77.88.8.1,8.8.8.8

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

Конечно, не все запросы будут пересылаться, для этого есть кэш. Он же cache. О проблеме с кэшем (мелочь, а неприятно), с которой я столкнулся, напишу ниже.

Все работает, но… Есть моменты, на которых я хотел бы заострить внимание.

Давайте не будем использовать только дефолт. Обезопасим себя и роутер от лишнего и абсолютно ненужного траффика.

При такой дефолтной настройке mikrotik будет отвечать на DNS запросы по всем интерфейсам. (Конечно же в том случае, если вы еще не настроили firewall) Нужны ли такие «левые» запросы? Конечно нет.
Поэтому в настройке firewall до «всеобщего DROP» в цепочке INPUT надо либо явно указать интерфейсы, с которых принимать DNS запросы (по одному правилу на интерфейс), либо указать диапазон IP, с которого принимать эти запросы):

/ip firewall filter
# еще какие-то разрешающие правила
# разрешим DNS-запросы с интерфейса ether2, который «смотрит» в локалку
add chain=input comment=»Allow DNS from ether2″ dst-port=53 in-interface=ether2 protocol=udp
#мы уверены, что все нужное разрешили выше
#поэтому запретим весь остальной траффик в цепочке INPUT
add action=drop chain=input comment=»Drop Another INPUT»

Либо разрешить DNS на всех интерфейсах, кроме «внешнего». Вот так, например:

# разрешим везде, кроме myISP, «внешнего» интерфейса
add chain=input comment=»Allow DNS from ether2″ dst-port=53 in-interface=!myISP protocol=udp

Либо… Либо… Способов много, firewall заслуживает отдельной большой темы даже для базовой настройки. Поэтому углубляться я тут не буду. Просто изложу принципы.

Реклама:

Допустим, мы написали нужные правила, определили откуда можно присылать DNS-запросы, все остальное отсекли. И тут DNS перестал работать. Все верно, т.к. мы забыли очень важную вещь: мы забыли разрешить серверам пересылки отвечать нашему роутеру. Т.е. mikrotik получает запрос из локалки, пересылает запрос, например, гуглу (8.8.8.8), гугл пытается ответить нашему роутеру и этот ответ отсекается последним правилом

/ip firewall filter
#…
#…
#…
#поэтому запретим весь остальной траффик в цепочке INPUT
# следующее правило отправит ответ гугла в небытие…
add action=drop chain=input comment=»Drop Another INPUT»

Нехорошо. Надо разрешить. Добавляем еще правило перед последним. Здесь я разрешу только серверу 8.8.8.8 ответить на запрос нашего роутера. Это для примера. Можно не указывать src-address, если вы не хотите писать отдельное правило для каждого сервера.

add chain=input comment=»Allow DNS request» in-interface=myISP protocol=udp src-address=8.8.8.8 src-port=53

Обратите внимание, что надо указывать src-port=53 а не dst-port=53. Наш роутер обратится к 8.8.8.8 с произвольного порта, а вот гугл будет отвечать именно с 53-го.

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

/ip firewall filter
# еще какие-то правила
# …
# разрешим DNS-запросы с интерфейса ether2, который «смотрит» в локалку
# в первом примере было так:
# add chain=input comment=»Allow DNS from ether2″ dst-port=53 in-interface=ether2 protocol=udp
# здесь я поступлю немного по-другому. Запрещу DNS запросы со всех интерфейсов, кроме ether2
add action=drop chain=input comment=»Drop DNS from !ether2″ dst-port=53 in-interface=!ether2 protocol=udp
# теперь разрешу всем DNS-серверам отвечать своему роутеру (уберу src-address=8.8.8.8)
add chain=input comment=»Allow DNS request» in-interface=myISP protocol=udp src-port=53
#теперь мы точно уверены, что все нужное разрешили выше
#поэтому запретим весь остальной траффик в цепочке INPUT
add action=drop chain=input comment=»Drop Another INPUT»

Кто-то пытливый обратил внимание, что в примерах отсутствуют action=accept. Accept используется по-умолчанию. Поэтому, когда мы хотим что-то разрешить, явно указывать «разрешаю» не обязательно.

Реклама:

Если у вас в локалке есть какие-то ресурсы, которым вы хотите присвоить имя, то вы можете добавить запись IP->DNS->Static. Когда это нужно? Да повсеместно. Например, у вас в сети есть файловый сервер или другой внутренний-ресурс, который постоянно мигрирует по разным IP-адресам и вам лень каждый раз перенастраивать подключение у каждого клиента.

Нажимаете «Static» и устанавливаете взаимосвязь между IP и именем хоста. Чтобы не листать наверх, вот вам еще раз рисунок из начала страницы:

Увидите следующее окно и, нажимая «+», добавляйте свои записи. Вот, собственно:

Или через терминал:

/ip dns static
add address=192.168.1.5 name=file-serv-1.lcl
add address=192.168.1.7 name=media-serv-1.lcl
add address=192.168.1.6 name=file-serv-2.lcl

Гораздо легче будет потом жить. Ваши пользователи будут обращаться к file-serv-1.lcl, а вы втихую менять его IP на микротике в случае переезда сервера.

Есть еще кнопка Cache, нажав которую, вы увидите, что в данный момент закешировал mikrotik и сможете этот кеш очистить, нажав в открывшемся окне Flush cache.

С настройкой вкратце все. Теперь мелкая неприятность, с которой я как-то столкнулся. Кроется она во взаимодействии кэша DNS микротика и статических записей. Не знаю, на каких версиях это еще проявляется, я словил на CCR1036-8G-2S+ RouterOS v6.15. Может, я вообще единственный, кто это наблюдал. Но, тем не менее, поделюсь. Вдруг кому поможет.

Если сменился IP хоста и вам надо отредактировать статическую запись, то лучше удалить старую и создать новую. Если просто отредактировать существующую, то в кэше могут остаться старые записи и ни кнопка Flush cache не поможет, ни /ip dns cache flush через терминал.

Глюк проявляется не систематически, но как-то раз заставил меня изрядно напрячь мозг, прежде чем я понял, в чем дело. Проверяйте кэш после редактирования статических записей. Если видите старое в дополнение к новому, то надо заново создать старую запись и удалить ее. Тогда она также удалится и из кэша.

Реклама:

Читайте также

Mikrotik dns static regexp — Вэб-шпаргалка для интернет предпринимателей!

— Блоги экспертов — Блог технического специалиста — Настройка условной пересылки DNS-запросов в Mikrotik RouterOS

Настройка условной пересылки DNS-запросов в Mikrotik RouterOS

Чтобы настроить пересылку dns-запросов для определенного домена на определенный dns-сервер (Conditional DNS forwarding), можно использовать возможность инспектирования пакетов на Уровне 7 (Layer7 Protocols) в Firewall RouterOS.

Имеем роутер MikroTik, версия RouterOS 6.27, ip-адрес dns-сервера на Микротике 192.168.15.1, требуется перенаправлять запросы для domain.local на dns-сервер домена Active Directory 192.168.55.2.

Для решения указанной задачи нужно выполнить в консоли RouterOS следующие команды:

Технический блог специалистов ООО»Интерфейс»

• Главная
• Расширенная настройка DNS и DHCP в роутерах Mikrotik

Расширенная настройка DNS и DHCP в роутерах Mikrotik

• Автор: Уваров А.С.
• 19.05.2019

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

DNS (Domain Name System)

В отличие от DHCP считается, что свой DNS — это удел крупных сетей, а небольшие организации вполне могут жить и без нее, используя сервера провайдера или публичные сервера. Отчасти это так, но упуская из своих рук одну из ключевых сетевых служб администратор теряет многие инструменты контроля и управления в собственной сети.

Как работает система DNS мы рассказывали в одной из наших статей, рекомендуем ее к прочтению, особенно если вы не до конца разбираетесь в вопросе. Основное, на что нужно обратить внимание — это иерархичность системы. Данные зон хранятся на собственных серверах и для получения информации из них следует прибегать к рекурсии. Это достаточно затратный процесс, поэтому многие сервера кешируют запросы и отвечают на повторные обращения самостоятельно.

Скорость ответа на DNS-запрос очень важна для комфортного использования интернета. Внешне это может проявляться как «задумчивость» браузера, который некоторое время «думает», а только потом начинает грузить страницу. При этом сама скорость канала может быть высокой, а пинг к требуемому серверу небольшим. Неопытного админа такая ситуация может сильно озадачить, но все просто — это долго отвечает используемый DNS-сервер. Ведь прежде, чем начать взаимодействие с сервером, браузер должен получить от DNS-клиента его адрес, передав последнему доменное имя.

Mikrotik дает нам возможность использовать кеширующий DNS-сервер прямо на роутере и если вы настроили использование роутера в качестве DNS — то вы его уже используете. Еще раз перейдем в IP — DNS и внимательно посмотрим на настройки:

В самом низу расположены настройки кеша: его размер (Cache Size) и максимальное время хранения записей (Cache Max TTL). Еще ниже располагается показатель использования кеша — Cache Used — который показывает его текущий размер. Если он начинает приближаться к размеру кеша, то последний следует увеличить. Просмотреть кеш можно нажав на кнопку Cache.

Глядя на значение TTL, можно подумать, что это очень много, целая неделя. Но это — максимальное время хранения записи, реальное время хранения определяется временем TTL в SOA-записи домена, причем Mikrotik использует минимальное значение — Minimum TTL. В этом несложно убедиться, мы очистили кеш и посетили один из своих сайтов, минимальный TTL которого равен 4 часам:

Как видим, Mikrotik использовал значение TTL из SOA-записей, ни о каких 7 днях речи не идет. Тогда для чего нужна эта настройка? Вы можете обновлять кеш чаще, чем это указано в TTL-домена. Если значение максимального TTL Mikrotik будет меньше, чем указанное в SOA-домена, то будет использоваться именно оно.

Это может быть полезным, если вы внесли какие-либо изменения во внешнюю зону и желаете быстрее обновить кеш. Как показывает практика, публичные сервера, такие как Google, OpenDNS или Яндекс тоже часто игнорируют TTL из SOA и обновляют свой кеш чаще.

Очистить кеш можно кнопкой Flush Cache в окне Cache или командой в терминале:

Но это еще не всё, изучение кеша может быть полезным для изучения сетевой активности пользователей, если они используют в качестве DNS ваш роутер — то вся их сетевая активность отразится в кеше. Говорите, никто не сидит в соцсетях?

Поэтому, если у вас нет иных инструментов логирования и статистики, то изучение записей кеша вполне позволит получить картину сетевой активности ваших пользователей.

На этом закончим с кешем и перейдем к другому разделу — Static. Он позволяет создавать нам собственные записи типа A (и больше ничего кроме них). Не густо, но основную часть потребностей это перекрывает. Перенесли сайт на новый сервер? Не нужно ждать пока обновятся DNS-записи, заходим в раздел Static и создаем собственную запись:

Проверим, как это работает. Выполним разрешение имени на клиенте:

Как видим — все работает отлично.

Отдельный разговор — плоские имена. В одноранговой сети часто бывает нужно указать имя узла, который не поддерживает NetBIOS, скажем ноду Hyper-V Server или машину с Linuх. Аналогично создаем запись:

Но имейте ввиду, работать такое разрешение имен будет только на Windows машинах, на Linux вы получите ошибку:

Но так как большинство сетей имеет преимущественно Windows ПК, то особых проблем плоские имена не доставят, и вы можете смело добавлять их записи на DNS Mikrotik вместо того, чтобы прописывать в hosts на каждой машине.

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

Проверим?

Вроде бы работает, но недостаток такого метода, что мы заблокировали только основной домен и пользователь легко сможет зайти через мобильный поддомен:

Чтобы этого избежать следует использовать регулярные выражения. К сожалению, в большинстве инструкций в интернете приводятся неправильные выражения, с которыми фильтр работать не будет, поэтому мы советуем использовать для создания и проверки регулярных выражений ресурс regex101.com. Это избавит вас от ошибок и вопросов в стиле «я сделал все как написано в статье, но ничего не работает».

Скажем, чтобы заблокировать домен vk.com со всеми поддоменами нам потребуется выражение:

Внесем его в соответствующее поле Mikrotik:

И проверим, теперь любое, даже заведомо не существующее имя в домене vk.com будет разрешаться в 127.0.0.1, что нам и требовалось.

Но это правило заблокирует также любые ресурсы, которые заканчиваются на vk.com, для того, чтобы этого избежать, нам потребуется более сложное выражение:

В небольших сетях, где пользователи имеют достаточно прав, всю эту идиллию можно быстро перечеркнуть, вручную прописав собственные DNS. Как с этим бороться? Решение в лоб — заблокировать прохождение DNS-запросов в цепочке FORWARD, но тогда у «продвинутого» пользователя вообще перестанет работать интернет, поэтому мы поступим по-другому.

Откроем IP — Firewall — NAT и добавим правило: Chain: dstnat, protocol: udp, Dst. Port: 53 и на закладке Action выберем действие redirect.

Потом создаем точно такое же правило для протокола tcp. Эти же самые действия можно быстро выполнить в терминале:

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

Как видим, DNS-сервер роутера Mikrotik, несмотря на кажущуюся простоту, в общем не так уж и прост и дает в руки администратора достаточно широкие возможности.

DHCP (Dynamic Host Configuration Protocol)

Когда речь заходит о DHCP, то обычно имеют ввиду автоматическое присвоение сетевых параметров, таких как IP-адрес, маска, шлюз и DNS-сервера. Но на самом деле возможности протокола намного шире и позволяют настроить очень многие сетевые параметры. Все возможности протокола описаны в RFC 2132, но мы не будем забираться столь глубоко, а рассмотрим в качестве примера только несколько наиболее популярных опций.

Прежде всего это Option 15 (DNS Domain Name) — которая позволяет автоматически настроить DNS-суффикс подключения, что позволяет снять определенный ряд проблем, связанный с использованием плоских имен.

Чтобы создать любую DHCP опцию потребуется перейти в IP — DHCP Server — Options и добавить там новую запись:

Поле Name содержит имя опции, можем задать его произвольно, так чтобы нам потом было понятно, что это такое и для чего нужно. Code — код опции, в нашем случае 15, Value — значение, в нашем случае это строка, поэтому обрамляем ее одиночной кавычкой. Тоже самое можно быстро сделать в терминале:

Обратите внимание, что значение value берется в кавычки два раза, в двойные и одинарные.

Опции можно (и нужно) объединять в наборы — Option Set, даже несмотря на то, что во многих сценариях их можно указывать непосредственно. Если в будущем вы надумаете что-то поменять, то достаточно будет просто изменить состав набора, в противном случае вам нужно будет вспомнить все места, где вы использовали некую опцию и заменить ее на новую (или удалить / добавить). Перейдем на одноименную закладку и создадим новый набор. Пока в него будет входить только одна опция:

Наборам желательно давать осмысленные названия, чтобы впоследствии вы легко могли понять для чего он предназначен. Теперь назначим его для применения на всю область DHCP-сервера. Перейдем на закладку DHCP и откроем запись нашего сервера, в поле DHCP Option Set укажем имя созданного нами набора.

Теперь обновим параметры DHCP и сразу увидим полученный DNS-суффикс:

После этого все плоские имена, которые вы добавили на DNS-сервер следует дополнить до FQDN, т.е. вместо HV-CORE-01 написать hv-core-01.interface31.lab (регистр записи значение не имеет).

Проверим:

Как видим, одной проблемой стало меньше, плоские имена нормально дополняются до FQDN и нормально разрешаются на нашем DNS вне зависимости от используемой ОС.

Также довольно часто используются опции: 42 (NTP Servers), 60, 66 (TFTP Server Name), 67 (Bootfile-Name). Имейте ввиду, что ОС Windows не запрашивает у DHCP-сервера опцию 42 и для нее установить таким образом сервер времени не удастся.

Отдельно коснемся того, как указывать IP-адреса. Протокол предусматривает передачу значений в шестнадцатеричном (Hex) формате, но RouterOS позволяет использовать и строковые значение, для этого значение Value должно содержать привычное написание адреса, взятое в одинарные кавычки:

или его шестнадцатеричное значение, которое должно начинаться с префикса 0х:

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

В шестнадцатеричном виде мы добавляем второе значение в конец строки, также без пробелов:

В терминале это будет выглядеть так:

Для перевода значений IP-адреса в шестнадцатеричное значение, можно использовать любой онлайн-калькулятор, мы при подготовке данного материала использовали этот.

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

Суть ее состоит в следующем: мы выборочно изменяем DNS-сервера детских сетевых устройств на безопасные DNS, например, Яндекс Семейный, SkyDNS, AdGuard и т.д. Тем, кто захочет реализовать этот сценарий в сети предприятия следует иметь ввиду, что в этом случае таким клиентам будут недоступны возможности собственного DNS-сервера, т.е. все то, о чем мы говорили в первой части статьи.

Итак, сначала создадим новую DHCP опцию с кодом 6 и укажем в значении сервера Яндекс Семейного:

Теперь создадим новый набор опций и добавим туда опцию YandexDNS.

Теперь перейдем на закладку Leases, где находится список выданных в аренду адресов и найдем там детское устройство, после чего откроем запись и выполним резервирование адреса, нажав Make Static:

Закроем и заново откроем эту запись и в поле DHCP Option Set укажем созданный нами набор с безопасными серверами:

Теперь проверим на клиенте, какие DNS-сервера он получил:

Все верно, это семейные сервера Яндекса. Попробуем посетить какой-нибудь сайт «для взрослых»:

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

В прошлой части статьи мы рассказывали, как предотвратить подмену DNS на клиентском ПК, данное решение совместно с этими правилами работать не будет. Можно, конечно, добавить исключение, но мы подойдем с другой стороны. Наша основная цель в этом сценарии — это оградить ребенка от посещения ненадлежащих ресурсов, поэтому при попытке подмены DNS мы должны направлять все запросы не на роутер, а на безопасные DNS, в противном случае попытка обхода фильтрации достигнет своей цели.

Поэтому заменим в правилах действие redirect на действие dst-nat, в поле To Addresses указываем один из серверов семейного Яндекса, а в поле To Ports — порт 53.

Также можно быстро добавить нужные правила командой:

Напоследок рассмотрим опции 121 (Classless Static Routes) и 249 (MS Routes), которые предназначены для передачи статических маршрутов. Первая опция предусмотрена RFC 2132, вторая является «художественной самодеятельностью» Microsoft, поэтому следует указывать обе из них с одинаковым содержимым.

Во избежание ошибок мы советуем задавать маршруты в HEX-формате, синтаксис предусмотрен следующий:

Если маршрутов несколько — добавляем значения к конец строки, без пробелов. Допустим, мы хотим добавить маршрут в сеть 192.168.4.0/22 через 192.168.186.92 и в сеть 10.8.0.0/24 через 192.168.186.94. Чтобы правильно получить шестнадцатеричное значение маски следует использовать такое представление: 0.0.0.22 или 0.0.0.24, забьем все значения в онлайн калькулятор и получим:

А вот теперь начнется небольшая магия, прежде всего обратим внимание на то, что количество символов в шестнадцатеричном числе всегда должно быть четным, но в строке, соответствующей 10.8.0.0 — нечетное количество символов, так как калькулятор отбросил ведущий ноль, поэтому вместо a080000 мы должны использовать 0a08000. Имеем это ввиду, так как разные калькуляторы могут по-разному обрабатывать ведущий ноль.

Затем от адреса сети, мы должны отбросить столько нулевых октетов, сколько нулей содержится в маске, в HEX-значении это по два нуля. Проще говоря для сетей /24 — /17 мы должны убрать в HEX-значении сзади два нуля, для сетей /16 — /9 — четыре нуля, для сетей /8 — /1 — шесть нулей. Таким образом 0a08000 должно превратиться в 0a0800, а c0a80400 в c0a804.

Таким образом первый маршрут должен выглядеть так:

Итоговое значение будет (не забываем про 0x вначале):

Добавим опции командами:

или через графический интерфейс:

Обновим параметры DHCP и проверим таблицы маршрутизации на клиентах. Windows-клиент:

Linux-клиент:

Как видим — все работает, маршруты добавились и еще одной заботой у администратора стало меньше.

В заключение хочется добавить, что данная статья не должна рассматриваться вами как догма, все пункты которой требуется обязательно применить. Данный материал имеет цель показать те скрытые возможности привычных сервисов, которые обычно не затрагиваются в руководствах по базовой настройке. После чего уже сам администратор должен решать, что он будет применять в своей сети и зачем. К сожалению, объем статьи не позволяет нам охватить все возможности DHCP, что-то из них мы отразим в будущих статьях, а что-то вам придется изучать самостоятельно. Но надеемся, что данный материал окажется вам полезен и даст дополнительный стимул к изучению всех возможностей используемых протоколов.

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

Итак, начнем. Если вы используете winbox, то первый этап выполняется в несколько кликов: IP->DNS. В появившемся окне указываете серверы пересылки, не забыв при этом поставить галку «Allow remote requests».

…или в терминале выполнить

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

Конечно, не все запросы будут пересылаться, для этого есть кэш. Он же cache. О проблеме с кэшем (мелочь, а неприятно), с которой я столкнулся, напишу ниже.

Все работает, но… Есть моменты, на которых я хотел бы заострить внимание.

Давайте не будем использовать только дефолт. Обезопасим себя и роутер от лишнего и абсолютно ненужного траффика.

При такой дефолтной настройке mikrotik будет отвечать на DNS запросы по всем интерфейсам. (Конечно же в том случае, если вы еще не настроили firewall) Нужны ли такие «левые» запросы? Конечно нет.
Поэтому в настройке firewall до «всеобщего DROP» в цепочке INPUT надо либо явно указать интерфейсы, с которых принимать DNS запросы (по одному правилу на интерфейс), либо указать диапазон IP, с которого принимать эти запросы):

Либо разрешить DNS на всех интерфейсах, кроме «внешнего». Вот так, например:

Либо… Либо… Способов много, firewall заслуживает отдельной большой темы даже для базовой настройки. Поэтому углубляться я тут не буду. Просто изложу принципы.

Нехорошо. Надо разрешить. Добавляем еще правило перед последним. Здесь я разрешу только серверу 8.8.8.8 ответить на запрос нашего роутера. Это для примера. Можно не указывать src-address, если вы не хотите писать отдельное правило для каждого сервера.

Обратите внимание, что надо указывать src-port=53 а не dst-port=53. Наш роутер обратится к 8.8.8.8 с произвольного порта, а вот гугл будет отвечать именно с 53-го.

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

Кто-то пытливый обратил внимание, что в примерах отсутствуют action=accept. Accept используется по-умолчанию. Поэтому, когда мы хотим что-то разрешить, явно указывать «разрешаю» не обязательно.

Нажимаете «Static» и устанавливаете взаимосвязь между IP и именем хоста. Чтобы не листать наверх, вот вам еще раз рисунок из начала страницы:

Увидите следующее окно и, нажимая «+», добавляйте свои записи. Вот, собственно:

Или через терминал:

Гораздо легче будет потом жить. Ваши пользователи будут обращаться к file-serv-1.lcl, а вы втихую менять его IP на микротике в случае переезда сервера.

Есть еще кнопка Cache, нажав которую, вы увидите, что в данный момент закешировал mikrotik и сможете этот кеш очистить, нажав в открывшемся окне Flush cache.

С настройкой вкратце все. Теперь мелкая неприятность, с которой я как-то столкнулся. Кроется она во взаимодействии кэша DNS микротика и статических записей. Не знаю, на каких версиях это еще проявляется, я словил на CCR1036-8G-2S+ RouterOS v6.15. Может, я вообще единственный, кто это наблюдал. Но, тем не менее, поделюсь. Вдруг кому поможет.

Если сменился IP хоста и вам надо отредактировать статическую запись, то лучше удалить старую и создать новую. Если просто отредактировать существующую, то в кэше могут остаться старые записи и ни кнопка Flush cache не поможет, ни /ip dns cache flush через терминал.

Глюк проявляется не систематически, но как-то раз заставил меня изрядно напрячь мозг, прежде чем я понял, в чем дело. Проверяйте кэш после редактирования статических записей. Если видите старое в дополнение к новому, то надо заново создать старую запись и удалить ее. Тогда она также удалится и из кэша.

Рекомендуем к прочтению

Как открыть свой сайт внутри локальной сети по доменному имени? Настройка NAT и DNS. — Хомячье логово

Содержание:

1. Постановка задачи.
2. Решение задачи.

2.1. Настройка правил NAT в MikroTik.
2.2. Настройка локального DNS в MikroTik.

3. Оригиналы источников информации.

Хочешь уметь больше? Научиться тонкостям настройки MikroTik можно из русскоязычного онлайн-курса по MikroTik от автора курсов Дмитрия Скромнова. Здесь можно изучить MikroTik и RouterOS самостоятельно по курсу «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA, но содержит больше информации. Это 162 видеоурока и большая практическая задача, разбитая на 45 лабораторных работ. Время на изучение неограниченно – все материалы передаются бессрочно и их можно пересматривать сколько нужно. Первые 25 уроков можно посмотреть бесплатно, оставив заявку на странице курса.

1. Постановка задачи.

Внутри сети имеется сервер с Nginx, который настроен на трансляцию сайта во внешнюю сеть. Всё традиционно: пользователь обращается по доменному имени к ресурсу, доменное имя ведет на IP-адрес и порт маршрутизатора, маршрутизатор обращается к web-серверу внутри локальной сети и пользователь получает сайт на экран своего устройства.

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

2. Решение задачи.

2.1. Настройка правил NAT в MikroTik.

Для просмотра своих ресурсов внутри локальной сети по традиционному запросу с доменного имени потребуется правильно настроить NAT своего роутера. Сделаем проброс порта 80 и порта 443 за пределы локальной сети и кроссировку внутри локальной сети для всех устройств внутри своей локальной сети.

Пройдем по вкладкам IP —> Firewall, откроется таблица Firewall роутера.

И создаем такие правила для порта 80 и порта 443:

Правило №1 (первая пара): проброс порта 80 ориентирован на пакеты из внешней сети на внутренний IP адрес.

Правило №2 (вторая пара): на компьютер в порт 80 можно зайти из локальной сети по внешнему IP адресу.

Правило №3 (третья пара): при запросе порта 80 из локальной сети роутер подменяет ответ внешним IP адресом и портом 80, чтобы обмануть Nginx в его прослушке адреса, с которого пришел запрос.

Правило №4, Правило №5, Правило №6 для порта 443 сделайте точно также по аналогии, вместо порта 80 подставьте порт 443 так же 3 раза и готово.

2.2. Настройка локального DNS в MikroTik.

Как компьютеры в локальной сети определяют путь до сайта? Правильно обращаются к DNS! Так как мы сами себе локальный DNS в нашей сети, то сделаем о сайте соответствующую запись в роутере!

Проходим IP —> DNS.

И объясняем роутеру во вкладке DNS, что при запросе из локальной сети доменного имени, выдавать IP адрес этого же роутера, а дальше правила NAT выдадут на сайт по локальной сети на ваше локальное устройство сети.

Выполняем по шагам:

1. Открывается окно DNS Settings: заходим в раздел Static
2. Открывается окно DNS Static: нажимаем жирный синий плюс.
3. Открывается окно DNS Static Entry: заполняем анкету DNS.
4. Графа Name: пишем свое доменное имя сайта site.ru, как в настройках сайта. Для доменного имени уровня www так же создаем отдельную запись в DNS по аналогии. Будет www.site.ru.
5. Графа Address: здесь пишем традиционный внешний IP адрес вашего роутера, который прописан DNS за пределами локальной сети.
6. Apply применяем.
7. ОК подтверждаем и закрываем окна DNS Static Entry и DNS Static.
8. В окне DNS Settings нажимаем Apply.
9. В окне DNS Settings нажимаем ОК и закрываем окно.

Готово! Теперь можете пробовать открывать свои локальные сайты из локальной сети так же, как если бы вы открывали их из внешней сети.

3. Оригиналы источников информации.

Нет.

Хочешь уметь больше? Научиться тонкостям настройки MikroTik можно из русскоязычного онлайн-курса по MikroTik от автора курсов Дмитрия Скромнова. Здесь можно изучить MikroTik и RouterOS самостоятельно по курсу «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA, но содержит больше информации. Это 162 видеоурока и большая практическая задача, разбитая на 45 лабораторных работ. Время на изучение неограниченно – все материалы передаются бессрочно и их можно пересматривать сколько нужно. Первые 25 уроков можно посмотреть бесплатно, оставив заявку на странице курса.

Настройка кэширующего DNS-сервера на роутере Mikrotik

В RouterOS есть простейший DNS-сервер, который, не смотря на свою простоту, может оказаться вполне применимым для небольших сетей.

Базовую настройку DNS можно выполнить в графическом интерфейсе WinBox:

1. Войдем в меню IP
2. Пункт DNS
3. В параметре Servers введем адреса DNS провайдера
4. Поставим галочку Allow Remote Requests (без нее сервер DNS не будет обрабатывать DNS-запросы клиентов)
5. Установим размер кэша DNS

6. И установим TTL для записей в кэше DNS, по истечению которого записи будут обновляться

Настроим статические записи DNS:

1. В DNS Settings нажимаем Static
2. В появившемся окне нажимаем +
3. Вводим DNS-адрес в поле Name
4. Вводим IP-адрес в поле Address
5. Устанавливаем TTL в соответствующее поле

Статические записи DNS позволяют ускорить работу DNS для часто используемых узлов, либо подменить узлы своими web-страницами (например, для запрещенных в вашей компании сайтов).

Рассмотрим кэш DNS чуть подробнее:

1. В DNS Settings нажимаем Cache. Перед нами предстанет список скэшированных DNS-записей. Обратите внимание: ранее введенные статические адреса тут присутствуют с флагом S (static) в виде записей типа A и PTR.
2. Если необходимо очистить кэш — жмем Flush Cache.

Более тонкая настройка DNS доступна только из консоли:

1. Запускаем терминал в меню
2. Входим в меню /ip dns. Чтобы увидеть все доступные команды внутри меню, набираем на клавиатуре ? — консоль выдаст все доступные команды и их описание. Аналогичная справка появляется и внутри подменю. Например, чтобы увидеть все команды в подменю set, необходимо набрать на клавиатуре set ?.

MikroTik Split or Forwarding DNS

В логах беты версии 6.47 увидел что есть изменения в работе DNS сервера на MikroTik.

Ну что-же интересно, необходимо проверить, работу и посмотреть что к чему.

Решил не использовать GNS, а взял с полки специально для тестов HAP ac2 и естественно обновил на последнюю beta версию.

IP адрес маршрутизатора с бета версией 172.20.17.100

Естественно по наитию пошли смотреть в /ip dns static

И видим нововведения, ну что же надо разобраться и проверить.

Не только A но и другие типы записей.

Раньше нем было доступно только A и AAAA записи для IPv4 и соответственно IPv6, как видим сейчас стало значительно больше.

Ну что-же давайте проверим все эти записи.

Проверять мы будет работу с помощью nsloopkup.

CNAME

Тип ссылки, когда мы говорим, что для данной записи ищи значение в другой записи.

/ip dns static> 
add type=CNAME name=test.mikrotik.me cname=blabla.mikrotik.me 

Проверка.

kirillvasilev@MacBook-Pro-Kirill ~ % nslookup -type=cname test.mikrotik.me 172.20.17.100 
Server:     172.20.17.100
Address:    172.20.17.100#53

Non-authoritative answer:
test.mikrotik.me    canonical name = blabla.mikrotik.me.

Работает!!!

MX

Записи MX необходимы для корректной работы, а точнее поиска сервера для получения почты по протоколу SMTP.

Создадим две записи для вымышленного домена, с разными весами.

[admin@MT-Station-01] /ip dns static> 
add type=MX name=mail.com mx-exchange=1.1.1.1 mx-preference=10
add type=MX name=mail.com mx-exchange=2.2.2.2 mx-preference=20 

Проверка.

kirillvasilev@MacBook-Pro-Kirill ~ % nslookup -type=mx mail.com 172.20.17.100 
Server:     172.20.17.100
Address:    172.20.17.100#53

Non-authoritative answer:
mail.com    mail exchanger = 10 1.1.1.1.
mail.com    mail exchanger = 20 2.2.2.2.

Работает!!!

NS

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

/ip dns static> 
add type=NS ns=1.1.1.1 name=mail.com 

Проверка.

kirillvasilev@MacBook-Pro-Kirill ~ % nslookup -type=ns mail.com 172.20.17.100 
Server:     172.20.17.100
Address:    172.20.17.100#53

Non-authoritative answer:
mail.com    nameserver = 1.1.1.1.

Работает!!!

TXT

Вы можете сохранять произвольное значение, частно используется для того чтобы проходить валидация SPF для перечисления записей разрешённых хостов для отправки почты. Также при использовании DKIM подписи.

И ещё мы написали программку knockme которая также может использовать TXT для получения параметров knock-a.

/ip dns static> 
add type=TXT text="MikroTik.Me this Me" name=mail.com 

Проверка.

kirillvasilev@MacBook-Pro-Kirill ~ % nslookup -type=TXT  mail.com 172.20.17.100 
Server:     172.20.17.100
Address:    172.20.17.100#53

Non-authoritative answer:
mail.com    text = "MikroTik.Me this Me"

Работает!!!

SRV

Многие сервисы могут использовать для автоматического получения списка серверов например SIP, XMPP, LDAP и прочее.

/ip dns static> 
add type=SRV srv-port=5060 srv-target=sip.mikrotik.me srv-weight=50 srv-priority=10 name=mail.ru

Проверка.

kirillvasilev@MacBook-Pro-Kirill ~ % nslookup -type=SRV  mail.ru 172.20.17.100 
Server:     172.20.17.100
Address:    172.20.17.100#53

Non-authoritative answer:
mail.ru service = 10 50 5060 sip.mikrotik.me.

Работает!!!

Ну что же вроде всё работает.

И самая долгожданная штука это так называемый SPLIT DNS.

MikroTik Split DNS

Для начало, для чего он нужен.

Данный режим ещё называется forward zone

Представим себе ваш MikroTik выступает в роли маршрутизатора удалённого филиала. На нём поднимается VPN до центрального филиала прописываются маршруты и прочее. У вас доменная авторизация все компьютеры в домене, естественно хорошей практикой на компьютерах прописать DNS сервера который обслуживают Active Directory службы. Но в таком случае если туннель по какой-то причине упадёт ваш филиал останется без интернета, а ведь интернета может не быть в центральном филиале. Да перестанут работать различные шары и прочее, конечно для этих целей существует как минимум RODC, но навсегда есть возможность установить подобный сервис в филиале ввиду множества различных проблем.

Представим что наш dns suffix равен mycom.loc

Соответственно, а что если мы на компьютерах припишем DNS сервер адрес MikroTik, а на MikroTik укажем, что если запрос содержит mycom.loc то перенаправлять такие запросы на сервера DNS AD, а все остальные запросы перенаправлять допустим на 8.8.8.8.

Установим на MikroTik сервер DNS 8.8.8.8

/ip dns set servers=8.8.8.8

и настроим forwarding зоны

/ip dns static> add type=FWD forward-to=10.11.254.251 regexp=".*mycom\\.loc"

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

Давайте проверим. Я решил взять реальный прод, поэтому DNS суффикс скрыл, не переживайте всё по подобию.

И так в скриншотах, с замазанным суффиксом.

Проверка.

И немного логов.

Работает!!!

Настоятельно рекомендую пока данный функционал не использовать в проде, так как это всё ещё бета версия.

Рассказать друзьям

Чатик телеграм

Настройка DoH в Mikrotik

Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».

Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.

Далее идем в IP -> DNS. Сразу же стоит обратить внимание, что вы можете получать DNS динамически (вышестоящий провайдер или настройки APN) и надо бы убрать автоматику. Чаще всего выглядит это как-то так:

Теперь нужно провести небольшую артподготовку, а именно скачать и импортировать список корневых сертификатов. Делается это двумя командами:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert

После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:

Провести проверку можно с помощью torch или в connection tracker:

Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).

Тестируем и проверяем на сайте Cloudflare

На всякий случай привожу листинг команд:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes
/ip dns set servers=""

UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare 🙂

Условная переадресация DNS-запросов на MikroTik

Автор Андрей Смирнов На чтение 4 мин. Просмотров 4.2k. Опубликовано 24.07.2017

Научиться настройке 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 и вставьте следующие команды:

/ip firewall layer7-protocol add name=mycompany.ru regexp=mycompany.ru

/ip firewall mangle add chain=prerouting dst-address=172.16.100.1 layer7-protocol=mycompany.ru action=mark-connection new-connection-mark=mycompany.ru-forward protocol=tcp dst-port=53

/ip firewall mangle add chain=prerouting dst-address=172.16.100.1 layer7-protocol=mycompany.ru action=mark-connection new-connection-mark=mycompany.ru-forward protocol=udp dst-port=53

/ip firewall nat add action=dst-nat chain=dstnat connection-mark=mycompany.ru-forward to-addresses=10.100.100.2

/ip firewall nat add action=masquerade chain=srcnat connection-mark=mycompany.ru-forward

2. В списке команд выше необходимо изменить внутренний IP-адрес вашего маршрутизатора (зеленый цвет), имя внутреннего домена (оранжевый цвет) и адрес внутреннего DNS сервера (синий цвет) в соответствии с вашими настройками в текстовом редакторе.

3. Откройте ssh-сеанс на маршрутизаторе MikroTik и вставьте отредактированное содержимое текстового редактора в командную строку.

4. Перезагрузите маршрутизатор, чтобы изменения вступили  в силу

/system reboot

Поиск неисправностей

Нам необходимо проверить, сможем ли попасть на сайты интрасети с другой стороны VPN. Если вы не можете, убедитесь, что туннель vpn запущен и работает, и что сайты действительно доступны через их внутренние IP-адреса, например, проверка по ping-протоколу нашего DNS-сервера 10.100.100.2. Следующим шагом является устранение проблемы с разрешением DNS при помощи таких команд, как nslookup. Сначала убедитесь, что DNS-сервер с другой стороны туннеля отвечает на запросы NS, выдавая команду:

C:\>nslookup - 10.100.100.2

Default Server : dns.mycompany.ru

Address: 10.100.100.2

>

где 10.100.100.2 DNS-сервер Интранета.

После приглашения > введите имя одного из ваших сайтов интрасети, и сервер имен должен сообщить его IP-адрес:

Default Server : dns.mycompany.ru
Address: 10.100.100.2

>server1.mycompany.ru

Name: server1.mycompany.ru
Address: 10.100.100.50

Если проверка проходит, то это означает, что туннель и DNS-сервер работают как нужно. Проверим перенаправление запросов через наш маршрутизатор, для этого выполним команду на клиентском устройстве:

C:\>nslookup - 172.16.100.1  

где 172.16.100.1 – внутренний IP-адрес нашего маршрутизатора MikroTik.

Default Server : router
Address: 172.16.100.1

>server1.mycompany.ru

Name: server1.mycompany.ru
Address: 10.100.100.50

Если результат не совпадает с вышеописанным, необходимо вернутся к списку команд в текстовом редакторе и убедитесь, что всё введено правильно. Исправьте ошибки и попробуйте еще раз.

MikroTik: куда нажать, чтобы заработало?
При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс «Настройка оборудования MikroTik». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.

DNS в Mikrotik — Делюсь опытом

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

Итак, начнем. Если вы используете winbox, то первый этап выполняется в несколько кликов: IP-> DNS. В появившемся окне указываете серверы пересылки, не забыв при этом поставить галку «Разрешить удаленные запросы».

… или в терминале выполнить

/ IP DNS
установите allow-remote-requests = yes servers = 77.88.8.8,77.88.8.1,8.8.8.8

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

Конечно, не все запросы будут пересылаться, для этого есть кэш. Он же cache. О проблеме с кэшем (мелочь, а неприятно), с которой я столкнулся, напишу ниже.

Все работает, но… Есть моменты, на которых я хотел бы заострить внимание.

Давайте не будем использовать только дефолт. Обезопасим себя и роутер от лишнего и абсолютно ненужного траффика.

При такой дефолтной настройке mikrotik будет отвечать на запросы DNS по всем интерфейсам. (Конечно же в том случае, если вы еще не настроили firewall) Нужны ли такие «левые» запросы? Конечно нет.
в настройке брандмауэра до «цепного DROP» в INPUT надо либо указать интерфейсы, которые принимают запросы DNS (по одному правилу на интерфейс), либо указать диапазон IP, с которого принимать эти запросы):

/ ip фильтр межсетевого экрана
# еще какие-то разрешающие правила
# разрешим DNS-запросы с интерфейса ether2, который «смотрит» в локалку
add chain = input comment = «Разрешить DNS от ether2» dst-port = 53 in-interface = ether2 protocol = udp
# мы уверены, что все нужное разрешили выше
# поэтому запретим весь остальной траффик в цепочке INPUT
add action = drop chain = input comment = «Drop Another INPUT»

Либо разрешить DNS на всех интерфейсах, кроме «внешнего».Вот так, например:

# разрешим везде, кроме myISP, «внешнего» интерфейса
add chain = input comment = «Разрешить DNS от ether2» dst-port = 53 in-interface =! myISP protocol = udp

Либо… Либо… Способов много, брандмауэр отдельной большой темы даже для настройки.Поэтому углубляться я тут не буду. Просто изложу принципы.

Реклама:

Допустим, мы написали нужные правила, определили откуда можно присылать DNS-запросы, все остальное отсекли. И тут DNS перестал работать. Все верно, т.к. мы забыли очень важную вещь: мы забыли разрешить серверм переки ответить нашей роутеру. Т.е. mikrotik получает запрос из локалки, пересылает запрос, например, гуглу (8.8.8.8), гугл пытается ответить нашей роутеру и этот ответекается последним правилом

/ ip фильтр межсетевого экрана
#…
# …
# …
# поэтому запретим весь остальной траффик в цепочке INPUT
# следующее правило отправит ответ гугла в небытие …
add action = drop chain = input comment = «Drop Another INPUT»

Нехорошо. Надо разрешить. Добавляем еще правило перед последним. Здесь я разрешу только серверу 8.8.8.8 ответить на запрос нашего роутера. Это для примера. Можно не указывать src-address, если вы не хотите писать отдельное правило для каждого сервера.

add chain = input comment = «Разрешить DNS-запрос» in-interface = myISP protocol = udp src-address = 8.8.8.8 src-порт = 53

Обратите внимание, что надо указывать src-port = 53 а не dst-port = 53. Наш роутер обратится к 8.8.8.8 с произвольного порта, а вот гугл будет отвечать именно с 53-го.

В конечном виде правила будут следующим следующим образом.

/ ip фильтр межсетевого экрана
# еще какие-то правила
# …
# разрешим DNS-запросы с интерфейса ether2, который «смотрит» в локалку
# в первом примере было так:
# add chain = input comment = «Разрешить DNS от ether2» dst-port = 53 in-interface = ether2 protocol = udp
# здесь я поступлю немного по-другому. Запрещу DNS запросы со всеми интерфейсами, кроме ether2
add action = drop chain = input comment = «Удалить DNS из! ether2» dst-port = 53 in-interface =! ether2 protocol = udp
# теперь разрешу всем DNS-сервера отвечать своему роутеру (уберу src-address = 8.8.8.8)
add chain = input comment = «Разрешить DNS-запрос» in-interface = myISP protocol = udp src-port = 53
# теперь мы точно уверены, что все нужное разрешили выше
# поэтому запретим весь остальной траффик в цепочке INPUT
add action = drop chain = input comment = «Drop Another INPUT»

Кто-то пытливый обратил внимание, что в примерах отсутствуют action = accept . Принимаю используется по-умолчанию. Поэтому, когда мы хотим что-то разрешить, явно указывать «разрешаю» не обязательно.

Реклама:

Если у вас в локалке есть какие-то ресурсы, которыми вы хотите присвоить имя, вы можете добавить запись IP-> DNS-> Static. Когда это нужно? Да повсеместно. Например, у вас в сети есть файловый сервер или другой внутренний ресурс, который постоянно мигрирует по разным IP-адресам и вам лень каждый раз перенастраивать подключение у каждого клиента.

Нажимаете «Static» и устанавливаете взаимосвязь между IP и именем хоста. Чтобы не листать наверх, вот вам еще раз рисунок из начала страницы:

Увидите следующее окно и, нажимая «+», добавляйте свои записи. Вот, собственно:

Или через терминал:

/ ip dns static
добавить адрес = 192.168.1.5 name = file-serv-1.lcl
добавить адрес = 192.168.1.7 name = media-serv-1.lcl
добавить адрес = 192.168.1.6 name = file-serv-2.lcl

Гораздо легче будет потом жить. Ваши пользователи будут обращаться к file-serv-1.lcl, а вы втихую менять его IP на микротике в случае переезда сервера.

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

С настройкой вкратце все. Теперь мелкая неприятность, с которой я как-то столкнулся. Кроется во взаимодействии кэша DNS микротика и статических записей. Не знаю, на каких версиях это еще проявляется, я словил на CCR1036-8G-2S + RouterOS v6.15. Может, я вообще единственный, кто это наблюдал. Но, тем не менее, поделюсь.Вдруг кому поможет.

Если сменился IP-хоста и вам надо отредактировать статическую запись, то лучше удалить старую и создать новую. Если просто отредактировать существующую, чтобы в кэше остались старые записи, ни кнопка Flush cache не поможет, ни / ip dns cache flush через терминал.

Глюк проявляется не систематически, но как-то раз заставил меня изрядно напрячь мозг, прежде чем я понял, в чем дело. Проверяйте кэш после редактирования статических записей.Если видите старое в дополнение к новому, то надо заново создать старую запись и удалить ее. Тогда она также удалится и из кэша.

Реклама:

Читайте также

.

Mikrotik dns static regexp — Вэб-шпаргалка для интернет предпринимателей!

— Блоги экспертов — Технический специалиста — Настройка условной пересылки DNS-запросов в Mikrotik RouterOS

Настройка условной пересылки DNS-запросов в Mikrotik RouterOS

Чтобы настроить пересылку dns-запросов для определенного домена на определенном dns-сервере (условное перенаправление DNS), можно использовать возможность инспектирования пакетов на Уровне 7 (протоколы Layer7) в Firewall RouterOS.

Имеем роутер MikroTik, версия RouterOS 6.27, ip-адрес dns-сервера на Микротике 192.168.15.1, требуется перенаправлять запросы для domain.local на dns-сервер домена Active Directory 192.168.55.2.

Для решения задачи нужно выполнить в консоли RouterOS следующие команды:

Технический блог специалистов ООО «Интерфейс»

• Главная
• Настройка расширенных DNS и DHCP в роутерах Mikrotik

Расширенная настройка DNS и DHCP в роутерах Mikrotik

• Автор: Уваров А.С.
• 19.05.2019

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

DNS (система доменных имен)

В отличие от DHCP считается, что свой DNS — это крупные сети, небольшие организации вполне могут жить и без нее, используя сервера провайдера или публичные сервера. Отчасти это так, но упуская из своих рук одну из ключевых служб служб администратор теряет многие инструменты контроля и управления в собственной сети.

Как работает система DNS, мы рассказывали в одной из наших статей, рекомендуем ее к прочтению, особенно если вы не до конца разбираетесь в вопросе.Основное, на что нужно обратить внимание — это иерархичность системы. Данные зонируются на собственных серверах и для получения информации из них прибегать к рекурсии. Это достаточно затратный процесс, поэтому многие сервера кешируют запросы и требуют повторного обращения самостоятельно.

Скорость ответа на DNS-запрос очень важна для комфортного использования интернета. Внешне это может проявляться как «задумчивость».При этом сама скорость канала может быть высокой, а пинг к необходимому серверу небольшой. Неопытного админа такая ситуация может сильно озадачить, но все просто — это долго использует DNS-сервер. Ведь прежде, чем начать взаимодействие с сервером, браузер должен получить от DNS-клиента его адрес, передав последнему доменное имя.

Mikrotik дает нам возможность использовать кеширующий DNS-сервер прямо на роутере и если вы настроили использование роутера в качестве DNS — то вы его уже используете.Еще раз перейдем в IP — DNS и внимательно посмотрим на настройки:

В самом низу установлены настройки кеша: его размер ( Cache Size ) и максимальное время хранения записей ( Cache Max TTL ). Еще ниже использует показатель использования кеша — Cache Used — который показывает его текущий размер. Если он начинает приближаться к размеру кеша, то последний следует увеличить. Просмотреть кеш можно на кнопку Cache .

показывает на значение TTL, можно подумать, что это очень много, целая неделя.Но это — максимальное время хранения записи, реальное время хранения определяет время TTL в SOA-записи домена, причем Mikrotik использует минимальное значение — Минимальный TTL. В этом несложно убедиться, что мы очистили кеш и один из своих сайтов, минимальный TTL которого равен 4 часам:

Как видим, Mikrotik использовал значение TTL из SOA-записей, ни о каких 7 днях речи не идет. Тогда для чего нужна эта настройка? Вы можете обновлять кеш чаще, чем это указано в TTL-домене. Если значение TTL Mikrotik будет меньше, чем указанное в SOA-домене, то будет именно оно оно.

Это может быть полезным, если вы внесли какие-либо изменения во внешнюю зону и желаете быстрее обновить кеш. Как показывает практика, публичные сервера, такие как Google, OpenDNS или Яндекс тоже часто игнорируют TTL из SOA и обновляют свой кеш чаще.

Очистить кеш можно кнопкой Очистить кеш в окне Кэш или командой в терминале:

. Используйте в качестве DNS ваш роутер — то вся их сетевая активность отразится в кеше.Говорите, никто не сидит в соцсетях?

Поэтому, если у вас нет используемых инструментов логирования и статистики, изучение записей кеша вполне позволит получить картину сетевой активности ваших пользователей.

На этом закончим с кешем и перейдем к другому разделу — Статический . Он позволяет создать нам собственные записи типа A (и больше ничего кроме них). Не густо, но основную часть потребностей это перекрывает. Перенесли сайт на новый сервер? Не нужно ждать пока обновятся DNS-записи, заходим в раздел Static и создаем собственную запись:

Проверим, как это работает.Выполним разрешение имени на клиенте:

Как видим — все работает отлично.

Отдельный разговор — плоские имена. В одноранговой сети бывает нужно указать имя узла, который не часто поддерживает NetBIOS, скажем ноду Hyper-V Server или машину с Linuх. Аналогично создаем запись:

Но имейте ввиду, работать такое разрешение имен будет только на Windows, машинах, на Linux вы получите ошибку:

Но так как большинство сетей имеет преимущественно Windows, то есть проблемы плоские имена не доставят, и вы можете смело добавить их записи на DNS Mikrotik вместо того, чтобы прописывать в хосты на каждой машине.

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

Проверим?

Вроде бы работает, но недостаток такого метода, что мы заблокировали только основной домен, и пользователь легко может зайти через мобильный поддомен:

Чтобы этого избежать следует использовать регулярные выражения.К сожалению, в большинстве инструкций в интернете приводятся неправильные выражения, с которыми фильтр работать не будет, поэтому мы советуем использовать для создания и проверки регулярных выражений ресурс regex101.com. Это избавит вас от ошибок и вопросов в стиле «я сделал все как написано в статье, но ничего не работает».

Скажем, чтобы заблокировать домен vk.com со всеми поддоменами нам выражение:

Внесем его в соответствующее поле Mikrotik:

И проверим, теперь любое, даже заведомо не существующее имя в домене vk.com будет разрешаться в 127.0.0.1, что нам и требовалось.

Но это правило заблокировано также любые ресурсы, которые заканчиваются на vk.com, для того, чтобы этого избежать, нам нужно более сложное выражение:

В небольших сетях, где пользователи достаточно прав, всю эту идиллию можно быстро перечеркнуть, вручную прописав собственные DNS. Как с этим бороться? Решение в лоб — заблокировать прохождение DNS-запросов в цепочке FORWARD, но тогда у «продвинутого» пользователя вообще перестанет работать в Интернете, поэтому мы поступим по-другому.

Откроем IP — Межсетевой экран — NAT и добавим правило: Цепочка: dstnat , протокол : udp , Dst. Порт: 53 и на закладке Действие выберем действие редирект .

Потом создаем точно такое же правило для протокола tcp . Эти же самые действия можно быстро выполнить в терминале:

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

Как видим, DNS-сервер роутера Mikrotik, несмотря на кажущуюся простоту, в общем не так уж и прост и дает в руки администратора достаточно широкие возможности.

DHCP (протокол динамической конфигурации хоста)

Когда речь заходит о DHCP, то обычно имеют ввиду автоматическое присвоение сетевых параметров, таких как IP-адрес, маска, шлюз и DNS-сервера. Но на самом деле возможности протокола намного шире и настроить очень многие сетевые параметры. Все возможности но продвижения в RFC 2132, мы не будем забираться столь же, а рассмотрим пример в качестве нескольких наиболее популярных опций.

Прежде всего это Вариант 15 (доменное имя DNS) — позволяет автоматически настроить DNS-суффикс подключения, что позволяет снять ряд проблем, связанных с использованием плоских имен.

Чтобы создать любую DHCP опцию необходимо перейти в IP — DHCP Server — Options и добавить там новую запись:

Поле Имя включает имя опции, может задать его произвольно, чтобы нам было потом понятно, что это такое и для чего нужно. Код — код опции, в нашем случае 15 , Значение — значение, в нашем случае это строка, поэтому обрамляем ее одиночной кавычкой. Тоже самое можно быстро сделать в терминале:

Обратите внимание, что значение value берется в кавычки два раза, в двойные и одинарные.

Опции можно (и нужно) объединить в наборы — Набор опций , даже несмотря на то, что многие сценариях их можно указывать непосредственно. Если в будущем вам нужно будет вспомнить, что-то поменять, то достаточно будет просто изменить состав, в противном случае вам нужно будет вспомнить все места, где вы использовали некую опцию и заменить ее на новую (или удалить / добавить).Перейдем на одноименную закладку и создадим новый набор. Пока в него будет входить только одна опция:

Желательно использовать осмысленное название, чтобы вы легко могли понять для чего он предназначенный. Теперь назначим его для применения на всю область DHCP-сервера. Перейдем на закладку DHCP и откроем запись нашего сервера, в поле DHCP Option Set укажем имя созданного нами набора.

Теперь обновим параметры DHCP и сразу увидим полученный DNS-суффикс:

После этого все плоские имена, которые вы добавили на DNS-сервер, следует дополнить до FQDN, т.е. вместо HV-CORE-01 написать hv-core-01.interface31.lab (регистр записи значение не имеет).

Проверим:

Как видим, одной проблемой стало меньше, плоские имена нормально дополняются до FQDN и нормально разрешаются на нашем DNS вне зависимости от используемой ОС.

Также довольно часто используются опции: 42 (серверы NTP), 60, 66 (имя сервера TFTP), 67 (имя загрузочного файла) . Имейте ввиду, что ОС Windows не запрашивает у DHCP-сервера опцию 42 и для нее установить таким образом сервер времени не удастся.

Отдельно коснемся того, как указывать IP-адрес. Протокол обеспечивает передачу значений в шестнадцатеричном (Hex) формате, но RouterOS позволяет использовать и строковые значения, для этого значения Значение должно содержать привычное написание адреса, взятое в одинарные кавычки:

или его шестнадцатеричное значение, которое должно начинаться с префикса 0х:

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

В шестнадцатеричный виде мы добавляем второе значение в конец строки, также без пробелов:

В терминале это будет так выглядеть:

Для перевода значений IP-адреса в шестнадцатеричное значение, можно использовать любой онлайн-калькулятор.

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

В следующем следующем: выбор изменяем DNS-сервера детских сетевых устройств на безопасные DNS, например, Яндекс Семейный, SkyDNS, AdGuard и т.д. Тем, кто захочет следует реализовать этот сценарий в сети предприятия иметь ввиду, что в этом случае таким клиентам будут недоступны возможности собственного DNS-сервера, т.е. все то, о чем мы говорили в первой части статьи.

Итак, сначала создадим новую DHCP опцию с кодом 6 и укажем в значении сервера Яндекс Семейного:

Теперь создадим новый набор опций и добавим туда опцию YandexDNS .

Теперь перейдем на закладку Аренда, где находится список выданных в аренду адресов и найдем там детское устройство, после чего откроем запись и выполним резервирование адреса ударного Make Static :

Закроем и заново откроем эту запись и в поле Параметр DHCP Установить укажем созданный набор с безопасными серверами:

Теперь проверим на клиенте, какие DNS-сервера он получил:

Все верно, это семейные сервера Яндекса.Попробуем посетить какой-нибудь сайт «для взрослых»:

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

В прошлой части мы рассказывали, как предотвратить подмену DNS на клиентском ПК, через данное решение с ограничением работать не будет. Можно, конечно, добавить исключение, но мы подойдем с другой стороны. Наша основная цель в этой сценарии — это предотвратить попытку атаки от посещения ненадлежащих ресурсов, поэтому при попытке подмены DNS мы должны направлять все запросы не на роутер, а на безопасные DNS, в противном случае попытка обхода достигнет своей цели.

Поэтому заменим в правилах действия редирект на действие dst-nat , в поле To Addresses указываем один из серверов семейного Яндекса, а в поле To Ports — порт 53.

Также можно быстро добавить нужные правила командой:

Напоследок рассмотрим опции 121 (Бесклассовые статические маршруты) и 249 (Маршруты MS) , предназначенные для передачи статических маршрутов. Первая опция предоставена RFC 2132, вторая является «художественной самодеостью» Microsoft, поэтому следует указывать обе из них с одинаковым содержимым.

Во избежание ошибок мы советуем задавать маршруты в HEX-формате, синтаксис предусмотрен следующий:

Если маршрутов несколько — добавляем значения к конец строки, без пробелов. Допустим, мы хотим добавить маршрут в сеть 192.168.4.0/22 ​​через 192.168.186.92 и в сеть 10.8.0.0/24 через 192.168.186.94. Чтобы получить шестнадцатеричное значение маски следует использовать такое представление: 0.0.0.22 или 0.0.0.24, забьем все значения в онлайн калькулятор и забьем:

А вот теперь начнется небольшая магия, прежде всего обратим внимание на то, что количество символов в шестнадцатеричном числе должно быть четным, но в строке, вводимой 10.8.0.0 — нечетное количество символов, так как калькулятор отбросил ведущий ноль, поэтому вместо a080000 мы должны использовать 0a08000 . Имеем это ввиду, так как разные калькуляторы могут по-разному обрабатывать ведущий ноль.

Затем от адреса сети, мы должны отбросить количество нулевых октетов, сколько нулей содержится в маске, в HEX-значении это по два нуля. Проще говоря для сетей / 24 — / 17 мы должны убрать в HEX-значении сзади два нуля, для сетей / 16 — / 9 — четыре нуля, для сетей / 8 — / 1 — шесть нулей.Таким образом 0a08000 должно превратиться в 0a0800 , а c0a80400 в c0a804.

Таким образом первый маршрут должен так выглядеть:

Итоговое значение будет (не забываем про 0x вначале):

Добавим опции командами:

или через графический интерфейс:

Обновим параметры DHCP и проверим таблицы маршрутизации на клиента. Windows-клиент:

Linux-клиент:

Как видим — все работает, маршруты добавились и еще одной заботой у администратора стало меньше.

В заключение требуется добавить, что статья не должна рассматриваться как догма, все условия которой обязательно применить. Материал показывает те скрытые возможности привычных сервисов, которые обычно не используются в руководствех по цели настройки. После чего уже сам администратор должен решать, что он будет применять в своей сети и зачем. К сожалению, объем статьи не позволяет нам охватить все возможности DHCP, что-то из них мы отразим в будущих статьях, а что-то вам придется изучать самостоятельно.Но надеемся, что данный материал данный вам полезен и даст дополнительный стимул к изучению всех возможных протоколов.

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

Итак, начнем. Если вы используете winbox, то первый этап выполняется в несколько кликов: IP-> DNS. В появившемся окне указываете серверы пересылки, не забыв при этом поставить галку «Разрешить удаленные запросы».

… или в терминале выполнить

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

Конечно, не все запросы будут пересылаться, для этого есть кэш. Он же cache. О проблеме с кэшем (мелочь, а неприятно), с которой я столкнулся, напишу ниже.

Все работает, но… Есть моменты, на которых я хотел бы заострить внимание.

Давайте не будем использовать только дефолт. Обезопасим себя и роутер от лишнего и абсолютно ненужного траффика.

При такой дефолтной настройке mikrotik будет отвечать на запросы DNS по всем интерфейсам. (Конечно же в том случае, если вы еще не настроили firewall) Нужны ли такие «левые» запросы? Конечно нет.
Поэтому в настройке брандмауэра до «цепного DROP» в INPUT надо явно указать принимать интерфейсы, с которых принимаются запросы DNS (по одному правилу на интерфейс), либо указать диапазон IP, с которого эти запросы):

Либо разрешить DNS на всех интерфейсах, кроме «внешнего».Вот так, например:

Либо… Либо… Способов много, брандмауэр отдельной большой темы даже для настройки. Поэтому углубляться я тут не буду. Просто изложу принципы.

Нехорошо. Надо разрешить. Добавляем еще правило перед последним. Здесь я разрешу только серверу 8.8.8.8 ответить на запрос нашего роутера. Это для примера. Можно не указывать src-address, если вы не хотите писать отдельное правило для каждого сервера.

Обратите внимание, что надо указывать src-port = 53, а не dst-port = 53.Наш роутер обратится к 8.8.8.8 с произвольного порта, а вот гугл будет отвечать именно с 53-го.

В конечном виде правила будут следующим следующим образом.

Кто-то пытливый обратил внимание, что в примерах отсутствуют action = accept . Accept используется по-умолчанию. Поэтому, когда мы хотим что-то разрешить, явно указывать «разрешаю» не обязательно.

Нажимаете «Static» и устанавливаете взаимосвязь между IP и именем хоста. Чтобы не листать наверх, вот вам еще раз рисунок из начала страницы:

Увидите следующее окно и, нажимая «+», добавляйте свои записи.Вот, собственно:

Или через терминал:

Гораздо легче будет потом жить. Ваши пользователи будут обращаться к file-serv-1.lcl, а вы втихую менять его IP на микротике в случае переезда сервера.

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

С настройкой вкратце все. Теперь мелкая неприятность, с которой я как-то столкнулся.Кроется во взаимодействии кэша DNS микротика и статических записей. Не знаю, на каких версиях это еще проявляется, я словил на CCR1036-8G-2S + RouterOS v6.15. Может, я вообще единственный, кто это наблюдал. Но, тем не менее, поделюсь. Вдруг кому поможет.

Если сменился IP-хоста и вам надо отредактировать статическую запись, то лучше удалить старую и создать новую. Если просто отредактировать существующую, чтобы в кэше остались старые записи, ни кнопка Flush cache не поможет, ни / ip dns cache flush через терминал.

Глюк проявляется не систематически, но как-то раз заставил меня изрядно напрячь мозг, прежде чем я понял, в чем дело. Проверяйте кэш после редактирования статических записей. Если видите старое в дополнение к новому, то надо заново создать старую запись и удалить ее. Тогда она также удалится и из кэша.

Рекомендуем к прочтению

.

Настройка кэширующего DNS-сервера на роутере Mikrotik

.

В RouterOS есть простейший DNS-сервер , который, не смотря на свою простоту, может оказаться вполне применимым для небольших сетей.

Базовую настройку DNS можно выполнить в графическом интерфейсе WinBox:

1. Войдем в меню IP
2. Пункт DNS
3. В параметре Серверы введем адреса DNS провайдера
4. Поставим галочку Разрешить удаленные запросы (без нее сервер DNS не будет обрабатывать DNS-запросы клиентов)
5. Установил размер кэша DNS
6. И установим TTL для записей в кэше DNS, по истечению которого записи будут обновляться

Настроим статические записи DNS:

1. В Настройки DNS нажимаем Статический
2. В появившемся окне нажимаем +
3. Вводим DNS-адрес в поле Имя
4. Вводим IP-адрес в поле Адрес
5. Устанавливаем TTL в соответствующее поле

Статические записи DNS позволяют ускорить работу DNS для часто используемых узлов, либо изменить узлы на свои веб-страницы (например, для запрещенных в вашей компании сайтов).

Рассмотрим кэш DNS чуть подробнее:

1. В Настройки DNS нажимаем Cache. Перед нами предстанет список скэшированных DNS-записей. Обратите внимание: ранее введенные статические адреса тут присутствуют с флагом S (статический) в виде записей типа A и PTR.
2. Если необходимо очистить кэш — жмем Flush Cache.

Более тонкая настройка DNS доступна только из консоли:

1. Запускаем терминал в меню
2. Входим в меню / ip dns .Чтобы увидеть все доступные команды внутри меню, набираем на клавиатуре ? — консоль выдаст все доступные команды и их описание. Аналогичная справка появляется и внутри подменю. Например, чтобы увидеть все команды в подменю set, необходимо набрать на клавиатуре набор? .

.

Как открыть свой сайт внутри локальной сети по доменному имени? Настройка NAT и DNS. — Хомячье логово

Содержание:

1. Постановка задачи.
2. Решение задачи.

2.1. Настройка правил NAT в MikroTik.
2.2. Настройка локального DNS в MikroTik.

3. Оригиналы источников информации.

Хочешь уметь больше? Научиться тонкостям настройки MikroTik можно из русскоязычного онлайн-курса по MikroTik от автора курсов Дмитрия Скромнова.Здесь можно изучить MikroTik и RouterOS самостоятельно по курсу «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA, но содержит больше информации. Это 162 видеоурока и большая практическая задача, разбитая на 45 лабораторных работ. Время на неограниченно — все материалы передаются бессрочно и их можно пересматривать сколько нужно. Первые 25 уроков можно посмотреть бесплатно, оставив заявку на странице курса.

1. Постановка задачи.

Внутри сети имеется сервер с Nginx , который настроен на трансляцию сайта во внешнюю сеть.Всё традиционно: пользователь обращается по доменному имени к ресурсу, доменное имя ведет на IP-адрес и порт маршрутизатора, маршрутизатор обращается к веб-серверу внутри локальной сети и пользователь получает сайт на своем экране устройства.

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

2. Решение задачи.

2.1. Настройка правил NAT в MikroTik.

Для просмотра своих ресурсов внутри локальной сети по традиционному запросу с доменного имени потребуется правильно настроить NAT своего роутера. Сделаем проброс порта 80 и порта 443 за пределы сети и кроссировку внутри локальной сети для всех устройств внутри своей сети.

Пройдем по вкладкам IP -> Firewall , откроется таблица Firewall роутера.

И создаем такие правила для порта 80 и порта 443 :

Правило №1 (первая пара) : проброс порта 80 ориентирован на пакеты из внешней сети на внутренний IP-адрес.

Правило №2 (вторая пара) : на компьютер в порт 80 можно зайти из локальной сети по внешнему IP адресу.

Правило №3 (третье пара) : при запросе порта 80 из локальной сети роутер подменяет ответ внешний IP-адрес и портом 80 , чтобы обмануть Nginx в его прослушке адреса, с которым пришел запрос.

Правило №4 , Правило №5 , Правило №6 для порта 443 сделайте точно также по аналогии, вместо порта 80 подставьте порт 443 так же 3 раза и готово.

2.2. Настройка локального DNS в MikroTik.

Как компьютеры в локальной сети определить путь до сайта? Правильно обращаются к DNS ! Так как мы сами себе локальный DNS в нашей сети, сделаем о соответствующей записи в роутере!

Проходим IP -> DNS .

И объясняем роутеру во взаимодействии DNS , что при запросе из локальной сети доменного имени, выдавать IP-адрес же роутера, а правила NAT выдадут на сайт в локальной сети вашего локального устройства сети.

Выполняем по шагам:

1. Открывается окно Настройки DNS: заходим в раздел Статический
2. Открывается окно DNS Static: нажимаем жирный синий плюс.
3. Открывается окно DNS Static Entry : заполняем анкету DNS .
4. Графа Имя : пишем свое доменное имя сайта site.ru , как в настройках сайта. Для доменного имени www так же создаем отдельную запись в DNS по уровню аналогии. Будет www.site.ru .
5. Графа Адрес : здесь пишем внешний IP-адрес вашего роутера, который прописан DNS за пределами локальной сети.
6. Применяем применяем.
7. ОК подтверждаем и закрываем окна DNS Static Entry и DNS Static .
8. В окне Настройки DNS нажимаем Применить .
9. В окне DNS Settings нажимаем ОК и закрываем окно.

Готово! Теперь можете пробовать открывать свои локальные сайты из локальной сети так же, как если бы вы открывали их из внешней сети.

3.Оригиналы источников информации.

Нет.

Хочешь уметь больше? Научиться тонкостям настройки MikroTik можно из русскоязычного онлайн-курса по MikroTik от автора курсов Дмитрия Скромнова. Здесь можно изучить MikroTik и RouterOS самостоятельно по курсу «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA, но содержит больше информации. Это 162 видеоурока и большая практическая задача, разбитая на 45 лабораторных работ. Время на неограниченно — все материалы передаются бессрочно и их можно пересматривать сколько нужно.Первые 25 уроков можно посмотреть бесплатно, оставив заявку на странице курса.

.