Резервный интернет в офисе: два провайдера и автоматическое переключение на MikroTik

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

Почему простой проверки шлюза недостаточно

Самый простой вариант - два маршрута по умолчанию с разной дистанцией и параметром check-gateway=ping. Проблема в том, что так проверяется только доступность ближайшего шлюза провайдера. Частая ситуация: шлюз отвечает, а дальше интернет не работает — авария у провайдера глубже в сети. Роутер считает канал рабочим, и офис остаётся без связи.

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

Рекурсивные маршруты: настройка

Идея такая: к выбранному внешнему адресу (у каждого провайдера свой) прописывается маршрут строго через шлюз этого провайдера. А маршрут по умолчанию указывает не на шлюз, а на этот внешний адрес. Если адрес перестаёт отвечать на ping, маршрут по умолчанию становится неактивным, и трафик уходит на резервный канал.

# адреса шлюзов — из документации (203.0.113.1 и 198.51.100.1), подставьте свои
/ip route
add dst-address=8.8.8.8/32 gateway=203.0.113.1 scope=10 comment="проверка ISP1"
add dst-address=1.1.1.1/32 gateway=198.51.100.1 scope=10 comment="проверка ISP2"

add dst-address=0.0.0.0/0 gateway=8.8.8.8 target-scope=11 check-gateway=ping distance=1 comment="ISP1 основной"
add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=2 comment="ISP2 резерв"

/ip firewall nat
add chain=srcnat out-interface=ether1-isp1 action=masquerade
add chain=srcnat out-interface=ether2-isp2 action=masquerade

Что ещё нужно учесть

Возврат на основной канал

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

Входящие подключения и VPN

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

Лимитированный резервный канал

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

Как проверить, что всё работает

Настроить переключение - половина дела. Вторая половина — проверить его в контролируемых условиях, а не в момент реальной аварии. Я делаю так:

1. Отключаю кабель основного провайдера и смотрю, через сколько секунд пропадает и возвращается связь у тестового компьютера.
2. Имитирую ситуацию «шлюз жив, интернет нет»: блокирую на роутере ping до проверочного адреса и убеждаюсь, что маршрут становится неактивным.
3. Проверяю, что работают телефония и VPN - они чувствительнее всего к переключению.
4. Настраиваю уведомление о переключении: офис не должен месяцами сидеть на резервном канале, не зная об этом.

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