Ситуация знакомая многим: сеть вроде бы жива, пинг на 8.8.8.8 проходит, роутер отвечает быстро, а браузер упрямо молчит. Адреса по имени не резолвятся, сайты не открываются, и первое подозрение почти всегда падает на DNS. На MikroTik такие истории встречаются чаще, чем кажется, особенно если конфигурацию собирали по частям, меняли провайдеров или включали дополнительные правила фильтрации.

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

Что на самом деле проверяет пинг и почему он не заменяет DNS

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

Если MikroTik пингует адреса, а сайты не открываются, сеть на третьем уровне модели OSI может быть в порядке. Сбой часто прячется на уровне имен, и тогда доступ к ресурсам ломается выборочно. По прямому IP страница может открываться, а по доменному имени нет.

На практике это выглядит так: роутер пингует 1.1.1.1, ноутбук получает адрес по DHCP, но при открытии сайта браузер зависает на стадии поиска домена. В такие моменты удобно отделять транспортную доступность от работы резолвера. Это экономит время и не заставляет сразу менять все подряд.

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

С чего начать проверку DNS на MikroTik

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

В RouterOS для этого обычно смотрят /ip dns print. Там видны статические серверы, включен ли удаленный запрос по умолчанию и используется ли кэш. Если поле servers пустое или туда попали недоступные адреса, картина становится понятной довольно быстро.

Еще один полезный тест, который часто экономит полчаса блужданий, это запрос имени прямо с самого MikroTik через /tool dns-resolve. Если домен не резолвится с роутера, проблема уже не в клиентском ноутбуке и не в браузере. Она либо в самих DNS-серверах, либо в пути до них, либо в фильтрации.

Проверка	Что означает	Что делать дальше
Пинг IP проходит	Маршрутизация и связь по адресу работают	Проверять DNS и правила фильтрации
Резолв имени с MikroTik не работает	Проблема на уровне роутера или DNS-сервера	Смотреть настройки /ip dns
Резолв на роутере работает, на клиенте нет	Клиент не получает нужный DNS или использует другой	Проверять DHCP, статические адреса, вручную заданные серверы

Если один и тот же сайт открывается по IP и не открывается по имени, причина почти всегда на стороне DNS, а не канала связи.

Как проверить настройки DNS на самом MikroTik

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

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

Встречается и другая история: на MikroTik вручную вписали публичные DNS, но сверху осталась галочка «получать от провайдера». В результате список серверов может меняться после переподключения, и поведение становится непредсказуемым. Такие вещи особенно заметны после перезагрузки или смены линка.

Что проверить в настройках

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

• адреса DNS-серверов в /ip dns;
• включен ли allow-remote-requests;
• получает ли роутер DNS по DHCP-клиенту;
• нет ли конфликтов с DNS, заданным вручную на клиентах;
• доступен ли сам DNS-сервер с интерфейса WAN.

Если allow-remote-requests выключен, клиенты могут остаться без ответов, даже если сам MikroTik успешно резолвит имена для собственных нужд. Это частая ловушка. Роутер как будто все умеет, но дальше себя ответы не раздает.

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

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

Когда MikroTik работает, а ломается клиентская часть

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

Если DHCP-сервер MikroTik раздает адрес, но не передает DNS-адрес роутера или внешних серверов, клиент может получить сеть без нормального имени. На Windows, macOS, Linux и в телефонах это проявляется по-разному, но суть одна: IP есть, домены не открываются.

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

DHCP и DNS: связка, которую легко упустить

В DHCP-пуле важно, чтобы клиентам выдавался корректный параметр DNS-server. Если в сети используется сам MikroTik как кэширующий DNS-прокси, логично указывать именно его адрес. Тогда клиенты отправляют запросы на роутер, а он уже обращается к внешним серверам.

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

Удобно проверить это с помощью обычного ipconfig /all на Windows или аналогов в других системах. Если там указан неожиданный сервер, вопрос уже почти решен. Остается понять, откуда он взялся.

Фаервол и фильтрация: когда DNS-пакеты не доходят

DNS может ломаться не из-за настроек резолвера, а из-за банальной блокировки. На MikroTik это особенно вероятно, если на WAN или в цепочке forward стоят жесткие правила. UDP 53 и TCP 53 должны проходить туда, куда им положено.

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

Еще одна распространенная проблема связана с тем, что DNS-запросы клиентов вообще не доходят до MikroTik, потому что перенаправление сломано правилом NAT или очередностью фильтрации. Поэтому полезно смотреть не только список правил, но и счетчики пакетов. Если счетчик на нужном правиле не растет, трафик идет в обход.

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

Проверка с практическим сценарием

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

У меня однажды на небольшом офисном MikroTik ситуация выглядела именно так: пинг до внешнего сервера проходил, а сайты на рабочих станциях не открывались. Оказалось, что после смены провайдера в настройках остались старые DNS из его сети, а новый канал работал через другой набор серверов. Роутер честно ходил по IP, но имена зависали на первом же запросе.

После замены DNS на актуальные и проверки DHCP клиенты поднялись почти сразу. Ничего экзотического там не было. Именно такие случаи и обманчивы: пока не посмотришь на резолв по шагам, кажется, что проблема должна быть сложнее.

Удобная последовательность проверки

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

1. Проверить пинг до внешнего IP, например 1.1.1.1 или 8.8.8.8.
2. Запустить DNS-resolve с самого MikroTik.
3. Посмотреть, какие DNS-серверы настроены в /ip dns.
4. Проверить, что DHCP раздает нужный DNS клиентам.
5. Убедиться, что фаервол не режет UDP и TCP 53.

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

Когда проблема не в DNS, а рядом с ним

Иногда DNS выглядит виноватым, хотя источник сбоев находится чуть в стороне. Например, если на MikroTik неправильно настроен маршрут по умолчанию, пинг на один адрес проходит, а другие сервисы ведут себя странно. Или если есть асимметрия на нескольких каналах.

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

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

Что помогает вернуть нормальную работу без лишних экспериментов

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

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

И еще один практический момент: после изменений не стоит тестировать только один сайт. Лучше открыть несколько доменов, проверить резолв с роутера и с клиента, а потом посмотреть логи. Так становится ясно, что проблема действительно ушла, а не просто спряталась за кэшем или случайным совпадением.

Если коротко свести все к одному наблюдению, то история с тем, что MikroTik пингует IP-адреса, но сайты не открываются, чаще всего упирается именно в DNS-цепочку. Она может сломаться в самом роутере, в DHCP, в правилах фильтрации или в клиентах. Но если идти по шагам и не смешивать IP-доступность с именами доменов, причина находится довольно быстро.