Зачем нужно резервирование каналов на MikroTik и какие проблемы оно решает

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

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

Роутеры MikroTik, включая такие модели, как hAP ac², отлично справляются с этой задачей. При этом настройка не требует дорогих лицензий или специализированного оборудования — достаточно двух подключений и базовых знаний. В этой статье мы покажем, как реализовать надёжную схему резервного подключения, которая будет работать круглосуточно без вмешательства человека.

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

Основных подходов к организации резервирования интернет-каналов три:

1. Приоритизация маршрутов через Distance (дистанцию). Каждый маршрут к сети интернет (чаще всего это default route — маршрут по умолчанию) получает числовой приоритет. Чем меньше значение distance, тем выше приоритет маршрута. В нормальном состоянии активен только маршрут с наименьшей дистанцией, например, distance=1. Второй, резервный маршрут имеет большее значение дистанции (например, distance=2) и находится в режиме ожидания. Как только система обнаруживает, что основной шлюз (gateway) недоступен, она деактивирует первый маршрут, и автоматически вступает в силу второй.
2. Рекурсивная маршрутизация с проверкой доступности. Более интеллектуальный метод. Маршрут по умолчанию указывает не на шлюз провайдера напрямую, а использует рекурсивную проверку через внешний хост (например, 8.8.8.8). Для достижения этого адреса прописаны два пути с разным Distance. Этот подход надёжнее первого, но сложнее в первоначальном понимании и конфигурации.
3. Использование Netwatch и скриптов (Failover). Самый надёжный и рекомендуемый метод, который детально разбирается в нашем руководстве. Утилита Netwatch постоянно мониторит доступность выбранного IP-адреса в интернете (целевой хост). При его недоступности срабатывает заранее написанный скрипт, который, например, отключает основной маршрут, вынуждая трафик идти через резервный. Этот метод обеспечивает автоматическое переключение при любом типе проблем — от падения интерфейса до потери связи с ключевым DNS-сервером.

Для наглядности сравним ключевые характеристики методов:

Прежде чем приступить к настройке резервирования интернета на MikroTik, убедитесь, что у вас есть всё необходимое. Подойдёт любой роутер MikroTik с RouterOS — от бюджетного hAP lite до мощного CCR. Например, hAP ac² (RBD52G-5HacD2HnD-TC) отлично подходит для небольшого офиса: у него пять гигабитных портов, USB-порт для подключения модема и четырёхъядерный процессор, способный обрабатывать сложные правила маршрутизации без задержек.

Что необходимо подготовить перед началом настройки:

1. Доступ к роутеру. Убедитесь, что вы можете подключиться к своему роутеру MikroTik для управления, используя WinBox (через MAC-адрес), веб-интерфейс или консоль (SSH/Telnet).
2. Два работающих интернет-подключения. Это могут быть две отдельные линии от разных провайдеров или технологии (например, оптоволокно + 4G-модем). Каждое подключение должно быть подведено к своему WAN-порту устройства.
3. Сетевые данные от провайдеров. Вам нужно знать IP-адреса, которые назначаются вашим WAN-интерфейсам, и, что критически важно, IP-адреса шлюзов (gateway) для каждого канала. Эти данные обычно предоставляются в договоре или настраиваются автоматически через DHCP-клиент на интерфейсе.
4. Базовая схема. Полезно набросать простую схему: какие физические порты (ether1, ether2) к какому провайдеру ведут и какой интерфейс (bridge или отдельный порт) используется для локальной сети.

Не стоит пугаться — от вас не требуется углублённых знаний в маршрутизации. Если вы знаете, как назначить IP-адрес на интерфейс и где посмотреть адрес шлюза, этих данных будет достаточно, чтобы успешно пройти все этапы настройки, описанные далее.

Совет: перед началом работ сделайте бэкап текущей конфигурации: в WinBox — Files → Backup, в терминале — команда /system backup save.

Теперь, имея на руках все необходимые данные, мы переходим к сердцу системы резервирования — настройке таблицы маршрутизации. Наша задача — указать роутеру два возможных пути «наружу», в интернет, и чётко определить, какой из них основной, а какой резервный.

В RouterOS это реализуется через создание двух статических маршрутов с одинаковой целью (сеть 0.0.0.0/0, которая и является маршрутом по умолчанию), но с разными шлюзами (gateway) — IP-адресами, выданными вашими провайдерами. Критически важным параметром здесь выступает дистанция (distance).

Принцип работы предельно прост: маршрут с меньшим значением distance имеет более высокий приоритет и используется всегда, когда он активен.

На практике это выглядит так:

• Для основного канала (например, от первого провайдера) вы создаёте маршрут с distance=1.
• Для резервного канала (от второго провайдера) вы создаёте маршрут с distance=2.

В нормальном состоянии роутер будет направлять весь исходящий трафик через основной шлюз, так как его маршрут имеет наивысший приоритет. Маршрут через канал второго провайдера с distance=2 будет присутствовать в таблице, но оставаться неактивным — он в режиме ожидания. Система сама управляет их состоянием (enable/disable) на основе мониторинга, который мы настроим позже.

Важно: MikroTik проверяет доступность шлюза только в том случае, если в настройках маршрута включена опция check-gateway (обычно это arp или ping). Без неё переключение не произойдёт, даже если интернет пропал — роутер будет «думать», что шлюз жив, потому что физически интерфейс подключён.

Таким образом, параметр distance в маршруте выполняет роль переключателя приоритетов. Если основной маршрут будет отключён (состояние disabled), система автоматически начнёт использовать следующий доступный маршрут с наименьшей дистанцией — в нашем случае резервный с distance=2. После восстановления основного канала и включения (enable) его маршрута трафик снова переключится на него, так как его приоритет (distance=1) снова станет самым высоким.

Совет: всегда присваивайте комментарии (comment=ISP1, comment=ISP2) — они упростят управление маршрутами через скрипты.

Давайте воплотим теорию в конкретные настройки. Предположим, шлюз основного провайдера (ISP1) — 10.0.1.1, а резервного (ISP2) — 192.168.100.1. Нам нужно добавить два маршрута.

Через WinBox (графический интерфейс):

1. Откройте раздел IP → Routes.
2. Нажмите на синий знак + (Add).
3. В поле Dst. Address оставьте 0.0.0.0/0.
4. В поле Gateway укажите 10.0.1.1 (шлюз ISP1).
5. В поле Distance установите 1.
6. Важный шаг: в поле Comment введите уникальное имя, например, ISP1. Этот комментарий будет ключом для работы скриптов.
7. Нажмите Apply и OK.
8. Повторите шаги 2–7 для второго маршрута:
   • Dst. Address: 0.0.0.0/0
   • Gateway: 192.168.100.1
   • Distance: 2
   • Comment: ISP2

Через терминал (CLI):

Используйте команды add в разделе маршрутизации. Обратите внимание на параметр comment.

Проверка и управление через find:

После создания вы можете проверить маршруты командой /ip route print. Для точечного управления конкретным маршрутом по его комментарию используется команда find. Например, чтобы временно отключить основной маршрут:

А для его включения:

Эти конструкции disable [find comment=...] и enable [find comment=...] — основа для скриптов автоматического переключения, которые мы создадим в следующем разделе. Убедитесь, что комментарии прописаны точно, без опечаток.

Базовый метод с check-gateway имеет существенный недостаток: он проверяет доступность только ближайшего шлюза провайдера. Если шлюз отвечает, но дальше на сети провайдера произошла авария, роутер этого не заметит — и ваши пользователи останутся без интернета при «живом» маршруте.

Решение — рекурсивная маршрутизация. Этот метод позволяет проверять доступность не шлюза, а реального хоста в интернете (например, Google DNS 8.8.8.8), при этом не требует скриптов и работает исключительно средствами таблицы маршрутизации.

Как это работает

Идея заключается в «хитрости» с маршрутами:

1. Default route указывает не на шлюз провайдера, а на публичный IP (например, 8.8.8.8). Звучит абсурдно — мы же не подключены к Google напрямую. Но RouterOS умеет искать путь рекурсивно.
2. Отдельный маршрут к этому публичному IP ведёт через реальный шлюз провайдера. Именно на этом маршруте включается check-gateway=ping.
3. Рекурсия: когда роутер видит default route через 8.8.8.8, он спрашивает себя: «А как мне добраться до 8.8.8.8?» — и находит второй маршрут через шлюз провайдера.
4. Проверка: если пинг до 8.8.8.8 пропадает (неважно, по какой причине — упал шлюз или магистраль провайдера), маршрут к 8.8.8.8 деактивируется, а вместе с ним «ломается» и рекурсивный default route. Автоматически активируется резервный маршрут.

Ключевые параметры, которые делают это возможным:

• scope — определяет «видимость» маршрута для рекурсивного поиска;
• target-scope — указывает, маршруты с каким scope могут использоваться как следующий хоп.

Правило: scope маршрута-посредника должен быть меньше, чем target-scope рекурсивного маршрута.

Конфигурация: три строки для надёжного failover

Предположим, шлюз основного провайдера (ISP1) — 10.0.1.1, резервного (ISP2) — 192.168.100.1.

Шаг 1: Рекурсивный default route через Google DNS

Этот маршрут говорит: «Весь трафик отправляй на 8.8.8.8». Но поскольку мы не подключены к Google напрямую, маршрут пока неактивен.

Шаг 2: Маршрут к Google через основной шлюз

Теперь роутер знает: чтобы достичь 8.8.8.8, нужно идти через 10.0.1.1. Параметр scope=10 меньше, чем target-scope=15 у первого маршрута — рекурсия работает. Check-gateway=ping постоянно проверяет, отвечает ли 8.8.8.8.

Шаг 3: Резервный default route

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

Проверка работы

После добавления всех трёх маршрутов выполните /ip route print:

Обратите внимание на слово recursive — оно подтверждает, что рекурсия работает.

Тест отказоустойчивости:

1. Отключите кабель от ether1 (основной провайдер)
2. Через 10–20 секунд пинг до 8.8.8.8 пропадёт
3. Маршрут check_ISP1 станет неактивным
4. Рекурсивный default route тоже деактивируется
5. Автоматически включится резервный маршрут через ISP2

Расширение: несколько контрольных хостов

Что если Google DNS временно недоступен, но интернет работает? Чтобы избежать ложных срабатываний, добавьте проверку через несколько хостов:

Теперь переключение на резерв произойдёт только если оба хоста (8.8.8.8 и 1.1.1.1) станут недоступны через основной канал.

Преимущества и ограничения метода

Когда выбрать этот метод: если вам нужен надёжный failover без сложной настройки и вы не планируете отправлять уведомления или вести логи переключений. Это золотая середина между простым check-gateway и продвинутым Netwatch.

Статических маршрутов с разным distance недостаточно, если вы хотите, чтобы переключение происходило только при реальной потере интернета, а не просто при недоступности шлюза. Для этого в MikroTik есть встроенный инструмент — Netwatch. Он периодически проверяет доступность удалённого хоста (например, DNS-сервера Google 8.8.8.8) и при обрыве связи запускает заданное действие.

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

Маршрут до тестового хоста через основной канал ISP1

Чтобы настроить Netwatch, перейдите в раздел Tools → Netwatch в WinBox или используйте CLI:

Здесь:

• host — IP-адрес, который будет пинговаться;
• interval — частота проверки (рекомендуется 5–10 секунд);
• timeout — время ожидания ответа;
• down-script — скрипт, который запустится, если хост перестанет отвечать;
• up-script — скрипт, который сработает при восстановлении связи.

Важно: Netwatch проверяет именно доступность интернета, а не состояние локального интерфейса. Это позволяет обнаруживать «мягкие» сбои — когда кабель подключён, шлюз отвечает, но внешние ресурсы недоступны. Такой подход значительно надёжнее простой проверки gateway ping или настройки check-gateway у маршрута.

Совет: не используйте IP-адреса самих провайдеров или их DNS — они могут быть недоступны при проблемах у конкретного оператора. Лучше выбрать публичные и стабильные хосты, такие как 8.8.8.8, 1.1.1.1 или 77.88.8.8.

Скрипты — это «мозг» системы резервирования. Именно они управляют маршрутизацией в зависимости от состояния канала, отслеживаемого Netwatch. В нашем случае нужны два скрипта: один срабатывает при потере связи с основным провайдером, другой — при её восстановлении.

Логика работы:

1. Скрипт ISP1_Down — срабатывает, когда Netwatch фиксирует недоступность хоста для основного канала. Его действия: отключить (disable) основной маршрут и включить (enable) резервный.
2. Скрипт ISP1_Up — срабатывает, когда связь по основному каналу восстановилась. Его действия: включить (enable) основной маршрут и отключить (disable) резервный.

Создание скриптов в System → Scripts:

Создайте скрипт с именем ISP1_Down (имя должно совпадать с тем, что указано в down-script при настройке Netwatch):

Этот код отключает основной маршрут (ISP1) и включает резервный (ISP2). Аналогично, скрипт ISP1_Up возвращает всё обратно:

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

Совет: чтобы избежать «дребезга» (частого переключения при нестабильной связи), добавьте в Netwatch параметр down-delay=30s — тогда скрипт сработает только после 30 секунд устойчивого обрыва.

Проверить, какой маршрут активен, можно через команду /ip route print — активные строки отображаются без пометки D (disabled). Если всё настроено верно, при обрыве основного канала роутер автоматически переключится на резервный, а при восстановлении — вернётся к исходному состоянию.

Готово! Теперь у вас работает полностью автоматизированная система. При обрыве основного канала Netwatch выполнит скрипт ISP1_Down, который отключит основной маршрут и включит резервный. Как только пинги начнут приходить вновь, сработает скрипт ISP1_Up и произойдёт обратное переключение. Запись в системный лог поможет отслеживать эти события.

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

Чтобы гарантировать, что весь трафик конкретного сеанса связи (исходящие запросы и входящие ответы) ходит через один и тот же интерфейс, применяется связка из двух техник: маркировка соединений и раздельный NAT.

1. Маркировка соединений (Mangle)

Мы «помечаем» новые соединения, исходящие из локальной сети, специальными метками. Затем на основе этих меток настраиваем маршрутизацию. Для этого создаются правила в /ip firewall mangle.

2. Раздельный NAT (Masquerade)

Классическое правило srcnat с masquerade на всех WAN-интерфейсах может работать некорректно в схеме резервирования. Вместо него настраиваются два отдельных правила, каждое со своим out-interface:

• Правило NAT для ISP1: преобразует адреса (srcnat) только для трафика, выходящего через interface=ether1.
• Правило NAT для ISP2: преобразует адреса только для трафика, выходящего через interface=ether2.

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

Ниже приведены примеры конфигурации для типичной сети, где локальная сеть — 192.168.88.0/24, основной WAN — ether1, резервный WAN — ether2. Выполняйте команды в терминале или создавайте соответствующие правила в разделах WinBox.

1. Маркировка соединений (Mangle)

Помечаем новые соединения, исходящие из локальной сети, в цепочке output и forward:

2. Раздельные правила NAT (Srcnat)

Настраиваем преобразование адресов (Masquerade) для каждого интерфейса отдельно:

Пояснение: Каждое правило применяет маскарадинг только к трафику, выходящему через указанный out-interface. Это гарантирует, что обратный трафик из интернета будет правильно направлен в локальную сеть через тот же интерфейс, с которого ушёл запрос, предотвращая его потерю.

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

1. Проверка текущего состояния

• Таблица маршрутов: выполните команду /ip route print. Найдите ваши маршруты с комментариями ISP1 и ISP2. Активный маршрут будет отмечен флагом A (active), а неактивный — флагом X (disabled). Убедитесь, что активен маршрут с distance=1.
• Состояние Netwatch: перейдите в Tools → Netwatch или выполните /tool netwatch print. Смотрите на колонку Status. Для добавленной задачи должен отображаться статус «up», если хост отвечает.
• Системный лог: выполните /log print. Здесь вы должны видеть информационные записи от ваших скриптов, если они уже срабатывали.

2. Тестирование автоматического переключения (моделирование аварии)

Это ключевой тест. Отключите кабель от основного WAN-порта (ether1) или выключите модем основного провайдера.

• Подождите несколько интервалов Netwatch (например, 30 секунд).
• Снова выполните /ip route print. Теперь активным (флаг A) должен стать резервный маршрут с distance=2, а основной — отключён (X).
• Проверьте лог (/log print). Должна появиться запись «Netwatch: Основной канал (ISP1) недоступен...».
• Проверьте доступность интернета из локальной сети, выполнив ping до какого-либо публичного адреса (например, ya.ru). Трафик должен идти, хотя и через резервный канал.

3. Проверка восстановления

Подключите кабель основного канала обратно.

• Подождите, пока Netwatch зафиксирует восстановление (статус станет «up»).
• В логе появится запись о возврате на основной маршрут.
• В таблице маршрутов основной маршрут снова станет активным (A), а резервный — отключённым (X).

Дополнительная диагностика трассировки:

Чтобы наглядно увидеть, через какой канал сейчас идёт трафик, используйте команду /tool traceroute 8.8.8.8. Первый хоп в выводе будет IP-адресом активного шлюза (gateway) провайдера, что сразу укажет на используемый маршрут.

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

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

1. Маршруты не переключаются. Частая причина — несовпадение комментариев в маршрутах и скриптах. Проверьте точное написание comment в выводе /ip route print и сравните с текстом в скриптах. Убедитесь, что скрипты правильно привязаны к событиям в Tools → Netwatch и что сам Netwatch видит хост (статус «up»).
2. Интернет не работает после переключения. Если после перехода на резервный канал доступ пропадает, в первую очередь проверьте настройки NAT. Убедитесь, что для резервного WAN-интерфейса (например, ether2) существует своё правило masquerade в /ip firewall nat print. Также убедитесь, что на резервном интерфейсе получен IP-адрес — проверьте статус DHCP-клиента командой /ip dhcp-client print.
3. Ложные срабатывания Netwatch. Если Netwatch постоянно фиксирует падение, хотя канал работает, возможно, выбранный для проверки хост неудачен. Некоторые провайдеры блокируют ICMP. Попробуйте сменить хост на 8.8.4.4 или 77.88.8.1. Также увеличьте параметры timeout (например, до 5s) и добавьте down-delay (до 30s), чтобы система была устойчивее к кратковременным потерям пакетов.
4. Скрипт не выполняется. Если скрипт не срабатывает, откройте его в System → Scripts и проверьте синтаксис. Частые ошибки: пропущенные кавычки или опечатки в именах комментариев. Запустите скрипт вручную кнопкой Run Script и наблюдайте за реакцией в логе. Если в логе появляется ошибка — исправьте её в коде.

Общие советы по диагностике:

Всегда смотрите системный лог (/log print) — там появляются сообщения об ошибках и записи от ваших скриптов. Используйте встроенные в MikroTik утилиты ping и traceroute для проверки доступности через конкретный интерфейс. После любых изменений сохраняйте конфигурацию командой /system backup save.

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

Реализованная схема легко масштабируется: достаточно подключить LTE/3G-модем через USB и добавить его как третий маршрут — и ваша сеть станет ещё устойчивее. Особенно это актуально в регионах с нестабильной проводной инфраструктурой.

Что сделать прямо сейчас:

1. Сохраните бэкап конфигурации командой /system backup save — это страховка от потери настроек;
2. Протестируйте переключение, физически отключив основной канал;
3. Настройте уведомления в логе или через email, чтобы оперативно узнавать о сбоях.

MikroTik превращает обычный роутер в интеллектуальный шлюз, который автоматически переключается на резерв при обрыве основного интернета, а при восстановлении — возвращает всё в штатный режим. Это и есть настоящая отказоустойчивость: незаметная для пользователя, но критически важная для бизнеса.