Настройка Failover на MikroTik с DHCP от провайдера

Представьте типичную задачу: у вас есть MikroTik-роутер и два канала интернета от провайдера. Цель — настроить автоматическое переключение на резервный канал, если основной упал.

В реальности, особенно у домашних и бизнес-пользователей, интернет часто предоставляется по DHCP. Это значит, что провайдер автоматически назначает вашему роутеру IP-адрес, маску подсети и, что самое важное, адрес шлюза по умолчанию. И вот здесь кроется главная ловушка.

Когда вы настраиваете DHCP-клиент на WAN-порту MikroTik, он по умолчанию (add-default-route=yes) автоматически создаёт в таблице маршрутизации динамический маршрут по умолчанию (0.0.0.0/0) с минимальным административным расстоянием (обычно 1). Если вы запустите два таких клиента на двух интерфейсах, произойдет конфликт: второй динамический маршрут перезапишет первый. В итоге у вас будет работать только тот канал, DHCP-ответ от которого пришёл последним. Резервирование (failover) не сработает.

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

Когда вы сталкиваетесь с ограничениями DHCP-клиентов, стандартные статические маршруты перестают быть надёжной основой для failover. Но RouterOS предлагает изящное решение — рекурсивную маршрутизацию. Этот механизм позволяет создавать маршруты, которые «смотрят» не на физический шлюз провайдера, а на доступность конкретного хоста в интернете (например, публичного DNS-сервера). И именно этот подход лежит в основе стабильного резервирования при динамических IP.

Как это работает? Представьте, что у вас есть два канала: основной и резервный. Вы создаёте маршрут к «маяку» — например, к 8.8.8.8 — через каждый из них. Затем вы строите основной маршрут по умолчанию, но указываете в качестве шлюза не IP провайдера, а… сам этот «маяк». Звучит странно? На самом деле, MikroTik автоматически разрешает (resolve) такой маршрут: он смотрит, через какой интерфейс сейчас доступен 8.8.8.8, и направляет весь трафик туда. Если основной канал падает — маршрут к «маяку» исчезает, и MikroTik переключается на резервный путь, где «маяк» всё ещё отвечает.

Но как система понимает, какие маршруты можно использовать для разрешения других? Здесь в игру вступают два важных параметра: scope и target-scope.

• Scope — это «область видимости» маршрута. Он определяет, может ли данный маршрут быть использован как «опора» для других.
• Target-scope — это требование: «этот маршрут может быть активен только если существует другой маршрут с scope ≥ target-scope».

В нашем случае:

• Маршрут к 8.8.8.8 получает высокий scope (например, 30);
• Рекурсивный маршрут по умолчанию указывает target-scope = 30, то есть «я активен, только если есть маршрут к цели с scope ≥ 30».

Если пинг до «маяка» пропадает, маршрут к нему удаляется — и вместе с ним исчезает и рекурсивный маршрут по умолчанию, потому что его условие (target-scope) больше не выполняется. Тогда вступает в силу резервный маршрут, построенный по тому же принципу, но с бо́льшим distance (например, 2 вместо 1), что делает его менее приоритетным в нормальном состоянии.

Этот подход решает главную проблему DHCP-каналов: он не полагается на состояние линка или наличие IP-адреса, а проверяет реальную доступность интернета. Даже если провайдер «дал» IP, но трафик не проходит дальше его шлюза, система это заметит и переключится.

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

Почему именно 8.8.8.8? Это публичный DNS от Google, известный своей стабильностью и доступностью.

Прежде чем строить сложную логику резервирования, необходимо правильно настроить сами DHCP-клиенты. От этого зависит, не будет ли RouterOS «бороться» с вашей конфигурацией, добавляя собственные маршруты в обход ваших правил.

Предположим, у вас два WAN-интерфейса:

• ether1 — основной канал от провайдера A
• ether2 — резервный канал от провайдера B

Оба получают IP-адреса по DHCP. Начнём с настройки клиентов.

Настройка основного DHCP-клиента (ether1)

Настройка резервного DHCP-клиента (ether2)

Важно! Параметр add-default-route=no указан для обоих клиентов. Это ключевой момент.

Как DHCP-клиент управляет маршрутами?

Когда вы создаёте DHCP-клиент, RouterOS по умолчанию делает две вещи:

1. Получает IP-адрес и шлюз от провайдера.
2. Автоматически добавляет маршрут по умолчанию (0.0.0.0/0) через полученный шлюз — если add-default-route=yes (значение по умолчанию).

Это удобно для одиночного подключения, но катастрофично для failover: оба клиента будут пытаться установить свой маршрут по умолчанию, и MikroTik выберет один из них (обычно с меньшим distance), игнорируя вашу логику резервирования.

Если же вы указываете add-default-route=no, DHCP-клиент не создаёт маршрут по умолчанию, но всё равно сохраняет информацию о шлюзе. Более того, он добавляет хостовый маршрут к самому шлюзу провайдера (например, 192.168.10.1/32), что позволяет вам использовать этот IP позже — в рекурсивных маршрутах.

Пример: что видно в таблице маршрутов

Именно такой «чистый» режим нам и нужен: мы сами будем управлять маршрутами, а DHCP-клиент лишь обеспечит актуальный IP шлюза.

Почему у резервного клиента default-route-distance=2?

Хотя мы отключили автоматические маршруты, параметр default-route-distance всё равно влияет на внутреннюю логику RouterOS. Указав default-route-distance=2 для резервного канала, мы задаём приоритет по умолчанию, который будет использован, если в будущем вы временно включите add-default-route. Это страховка от ошибок. Кроме того, некоторые версии RouterOS используют это значение при диагностике.

Также обратите внимание на use-peer-dns=no и use-peer-ntp=no — это предотвращает автоматическую подстановку DNS-серверов провайдера, что особенно полезно, если вы используете собственные (например, Cloudflare или AdGuard Home).

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

Проверка: после применения этих команд выполните /ip dhcp-client print. Убедитесь, что оба клиента в статусе bound и имеют полученные IP и шлюзы. Если нет — диагностику смотрите в разделе «Почему MikroTik не получает IP по DHCP?».

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

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

Давайте перейдем к конкретным командам. Предположим, что основной канал (ether1) получил шлюз 10.0.1.1, а резервный (ether2) — 192.168.88.1.

1. Создание маршрута-«маяка»

Этот маршрут определяет точку в интернете, доступность которой мы будем постоянно мониторить. Классический выбор — публичный DNS-сервер Google.

• dst-address=8.8.8.8/32: Мы создаем маршрут к конкретному IP (хосту), а не ко всей сети. Это точная цель для проверки.
• gateway=172.16.1.1: Виртуальный шлюз. Пока нет маршрута к нему самому, этот маршрут неактивен.
• scope=30: Явно указываем, что шлюз — удаленный (>30 — это обычно маршруты в черной дыре). Это разрешает рекурсию.
• check-gateway=ping: Ключевая опция! RouterOS будет каждые 10 секунд отправлять ping на адрес шлюза (172.16.1.1). Если ответа не последует, маршрут пометит шлюз как недостижимый.

2. Создание рекурсивного маршрута для ОСНОВНОГО канала

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

• dst-address=172.16.1.1/32: Цель — наш виртуальный адрес.
• gateway=10.0.1.1: Реальный шлюз провайдера для основного канала. Как его узнать? Выполните команду /ip dhcp-client print и найдите адрес в столбце GATEWAY для интерфейса ether1.
• scope=10: Указывает, что шлюз (10.0.1.1) находится в локальной (достижимой) сети. Этот маршрут будет активным.
• distance=2: Административное расстояние. Оно выше, чем у стандартного DHCP (1), поэтому не конфликтует, но ниже, чем у резервного маршрута (3), что делает его предпочтительным.

3. Создание рекурсивного маршрута для РЕЗЕРВНОГО канала

Аналогично создаем маршрут для резервного канала.

• gateway=192.168.88.1: Реальный шлюз для резервного канала (с интерфейса ether2).
• distance=3: Более низкий приоритет, чем у основного (2). Этот маршрут будет использоваться только если маршрут с distance=2 станет неактивным.

Как это работает вместе?

1. Роутер хочет отправить пакет в интернет (например, на 8.8.4.4). Он ищет самый специфичный маршрут.
2. Находит маршрут по умолчанию? Нет, мы его не создавали. Но находит маршрут к 8.8.8.8/32.
3. Чтобы использовать этот маршрут, нужно достичь шлюза 172.16.1.1. Роутер ищет маршрут к нему.
4. Он видит ДВА маршрута к 172.16.1.1/32: через 10.0.1.1 (distance=2) и через 192.168.88.1 (distance=3).
5. Выбирается маршрут с наименьшим distance — через основной шлюз 10.0.1.1.
6. Пакет отправляется через основной канал. Раз в 10 секунд система пингует 172.16.1.1, используя активный маршрут к нему (т.е. через 10.0.1.1). Пока пинг проходит, статус соединения «маяка» — доступен.

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

Проверка в штатном режиме

Выполните следующие команды:

1. Посмотрите таблицу маршрутов:

В рабочем состоянии вы должны увидеть примерно такую картину:

Обратите внимание:

• Только один маршрут по умолчанию активен (флаг A) — тот, у которого distance=1;
• Только один маршрут к 8.8.8.8 активен — через основной шлюз;
• Резервные маршруты есть в таблице, но неактивны (нет флага A).

2. Проверьте доступность интернета:

Оба пинга должны проходить без потерь.

Моделирование сбоя основного канала

Теперь имитируем обрыв основного интернета:

1. Отключите кабель от ether1
   (или отключите порт: /interface set ether1 disabled=yes)
2. Подождите ~30 секунд
   RouterOS отправляет пинги каждые 10 секунд по умолчанию. После 3-x пропущенных пингов маршрут будет признан недоступным.
3. Снова выполните /ip route print
   Теперь вывод должен измениться:

Что изменилось:

• Активным стал маршрут с distance=2 (резервный).
• Активным стал маршрут к 8.8.8.8 через шлюз 10.45.22.1.

4. Проверьте интернет:

Трафик теперь идёт через резервный канал — пинг должен работать.

Возврат к основному каналу

Теперь подключите кабель обратно (или включите интерфейс: /interface set ether1 disabled=no).

Через 10 секунд выполните снова:

Вы увидите, что система автоматически вернулась к основному каналу (маршрут с distance=1 снова активен). Это демонстрирует полноценный failover и failback — без участия пользователя.

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

1. Выбор надежного «маяка» (альтернативы 8.8.8.8)

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

Команда для добавления второго маяка:

Принцип работы check-gateway=arp

RouterOS будет отслеживать наличие MAC-адреса шлюза (172.16.1.1) в своей ARP-таблице. Но здесь есть ключевое ограничение: этот метод проверяет доступность только первого хопа (шлюза провайдера 10.0.1.1 или 192.168.88.1), а не доступность интернета. Если у провайдера внутренние проблемы, но линк до его оборудования есть, ARP будет проходить, и маршрут будет считаться активным, даже если интернета нет.

Используйте arp только если ping действительно заблокирован. Помните, что в этом случае метод проверяет только «линк», а не «интернет». В подавляющем большинстве случаев (99%) при аварии интернета линк провайдера остается поднят, поэтому arp не является надежным методом для проверки доступности интернета. Используйте его только если ping действительно заблокирован, понимая это ограничение.

В самых сложных случаях можно написать собственный скрипт, который, например, проверяет доступность через TCP-порт 53 (DNS) или 443 (HTTPS), и на основе его результатов включать или отключать маршруты. Однако это тема для отдельной статьи.

2. Учет приоритета DNS

В нашей настройке оба DHCP-клиента имеют параметр use-peer-dns=no. Это предотвращает получение DNS-серверов от провайдера. Однако для гарантированно стабильной работы рекомендуется вручную задать статические, надежные DNS-серверы (например, 77.88.8.8 и 77.88.8.1) в настройках DNS самого MikroTik.

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

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

Даже при тщательной настройке что-то может пойти не так. Ниже — разбор самых распространённых сценариев, почему failover не работает или DHCP-клиент «молчит». Подход — от простого к сложному.

Почему MikroTik не получает IP-адрес по DHCP?

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

Уровень 1: Физика и интерфейс

Есть ли линк на порту? Выполните:

Интерфейс должен быть в состоянии R (running), а не D (disabled) или без флага.
Проверьте кабель, SFP-модуль, индикаторы на роутере и оборудовании провайдера.

Уровень 2: Настройка DHCP-клиента

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

Столбец INTERFACE должен совпадать с вашим WAN-портом.
Клиент не должен быть отключён (disabled=no).

Уровень 3: Анализ логов

Включите логирование DHCP (если ещё не включено):

Посмотрите логи:

Уровень 4: Проброс VLAN-тега

Некоторые провайдеры (особенно в GPON/FttH) требуют VLAN-тег на WAN-порту. Если вы не настроили VLAN, DHCP-запросы просто не дойдут до сервера.

Решение: создайте VLAN-интерфейс и привяжите DHCP-клиент к нему:

Совет: если ничего не помогает — попробуйте подключить ПК напрямую к тому же порту. Получает ли он IP? Если да — проблема в MikroTik. Если нет — проблема на стороне провайдера.

Маршруты не переключаются при обрыве канала

Если интернет падает, но MikroTik не переключается на резерв, проверьте:

1. Указан ли правильный шлюз в маршруте к «маяку»?

• Шлюз должен быть точно таким, какой выдал DHCP-клиент;
• Если провайдер изменил шлюз (редко, но бывает), маршрут станет «битым»;

Решение: обновите gateway вручную или настройте скрипт-обновление.

2. Есть ли check-gateway=ping?

Без этого параметра MikroTik не проверяет доступность шлюза, и маршрут остаётся активным даже при полном обрыве.

3. Совпадают ли scope и target-scope?

У маршрута к «маяку» должен быть scope=30.
У рекурсивного маршрута — target-scope=30.
Если значения не совпадают, зависимость не сработает.
Проверьте:

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

4. Не блокирует ли провайдер ICMP?

Как обсуждалось ранее, если пинги не проходят, check-gateway не работает. Попробуйте пинг с самого MikroTik:

Если пинг не проходит, но интернет работает — нужна альтернатива через netwatch.

Команды для быстрой диагностики

Если после всех проверок проблема остаётся — скорее всего, причина в особенностях оборудования или политики провайдера. В таких случаях полезно временно подключить PPPoE или статический IP для тестирования: если failover заработает — значит, проблема именно в DHCP-логике.

Настройка Failover на MikroTik с DHCP через рекурсивную маршрутизацию — это мощный шаг вперед по сравнению с простым переключением дистанций.

Что дальше? Ваша сеть теперь обладает профессиональным уровнем отказоустойчивости. Вы можете спокойно проводить профилактические работы на оборудовании основного провайдера, не прерывая рабочий процесс. Для дальнейшего углубления знаний рекомендуется изучить работу Mangle-правил для маркировки трафика и познакомиться с протоколом BGP, если вы работаете с выделенными каналами и статическими IP.

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

Если вы внедряете эту схему в бизнес-инфраструктуре или хотите адаптировать её под сложную сеть — наша команда предоставляет профессиональную послепродажную поддержку.