Механизм Detect Internet в роутерах MikroTik — это встроенный инструмент фоновой диагностики, который определяет статус подключения к глобальной сети. В отличие от простого отслеживания физического линка (подключен ли кабель), детектор проверяет способность устройства обмениваться пакетами с внешними узлами. Эта функция является фундаментом для автоматического переключения каналов связи (Failover) и распределения нагрузки.
Принцип действия и архитектура
Алгоритм работы основан на периодической отправке тестовых запросов (обычно ICMP ping) к заданным IP-адресам или доменным именам. Если ответы поступают в течение установленного таймаута, интерфейс помечается как активный (WAN). При отсутствии реакции система считает канал недоступным и может инициировать переключение трафика на резервный путь.
Ключевое отличие современного детектора от простых скриптов пинга заключается в учете таблицы маршрутизации. В актуальных версиях RouterOS механизм анализирует маршрут по умолчанию: если шлюз ведет через определенный интерфейс, проверка его доступности приоритетна. Это снижает вероятность ложных срабатываний, когда интернет есть, но не через тот порт, который ожидает проверить скрипт.
Важно: Использование публичных DNS-серверов (например, 8.8.8.8) в корпоративных сетях может триггерить системы безопасности. Рекомендуется согласовывать списки проверяемых адресов с политикой ИБ или использовать внутренние шлюзы провайдеров.
Сценарии применения
Функция используется не изолированно, а как источник данных для других компонентов системы:
- Отказоустойчивость (Failover): Основной канал имеет меньшую метрику маршрута. Пока детектор фиксирует онлайн-статус, весь трафик идет по нему. При обрыве метрика основного канала повышается, и трафик перенаправляется на резерв (4G/5G модем, второй провайдер).
- Балансировка нагрузки: Детектор контролирует доступность нескольких активных каналов. При падении одного из них его доля трафика распределяется между оставшимися рабочими интерфейсами.
- Управление периферией: Статус детектора может служить триггером для внешних устройств. Например, при пропадании связи роутер может подать сигнал на GSM-шлюз для отправки SMS или включить питание генератора через управляемый коммутатор.
Конфигурация через графический интерфейс
Для визуальной настройки перейдите в раздел System > Detect Internet. Здесь отображается список всех интерфейсов роутера с их текущим статусом:
- none — интерфейс не участвует в определении статуса интернета.
- lan — интерфейс определен как внутренний.
- wan — интерфейс определен как внешний (выход в интернет).
Система пытается автоматически присвоить роли на основе анализа маршрутов, но эта логика не всегда идеальна. Вы можете вручную зафиксировать роль интерфейса, например, принудительно назначить ether1 как WAN, даже если временные проблемы с проверкой адреса делают его статус неопределенным.
Настройка через командную строку (CLI)
Администраторы предпочитают терминал для точечной настройки и интеграции в скрипты. Базовая команда добавляет интерфейс в список отслеживаемых:
/system detect-internet add interface=ether1 detect-time=10s
Параметр detect-time задает интервал между проверками. Для группировки интерфейсов используется ключ detect-internet-list, что удобно при наличии нескольких независимых провайдеров. Изменения применяются мгновенно, но для сохранения после перезагрузки необходимо выполнить команду /system backup save.
Таблица параметров оптимизации
Настройка чувствительности детектора требует баланса между скоростью реакции и нагрузкой на систему. Рекомендуемые значения зависят от типа канала связи:
Проведите по таблице влево, чтобы увидеть остальные столбцы
| Параметр | Рекомендуемое значение | Влияние на работу |
|---|---|---|
| Интервал проверки | 10–30 секунд | Частые опросы ускоряют обнаружение обрыва, но увеличивают нагрузку на CPU роутера. |
| Таймаут ответа | 3–5 секунд | Слишком малый таймаут вызывает ложные срабатывания при кратковременных задержках пакетов. |
| Количество попыток | 3–5 раз | Повышает надежность определения статуса, но замедляет общую реакцию на изменение сети. |
| Целевые адреса | 2–3 разных IP | Использование нескольких узлов исключает влияние сбоя одного конкретного сервера. |
Для критически важных линий уменьшайте интервалы. Для мобильных резервных каналов (3G/4G) увеличивайте их, чтобы экономить трафик и заряд батареи модема.
Диагностика и устранение проблем
Если детектор работает некорректно, первым шагом включите подробное логирование:
/system logging add topics=detect-internet
Все события будут записываться в журнал. Просмотреть их можно через вкладку Log в WinBox или командой /log print. Анализируя записи, обращайте внимание на характер ошибок:
- Таймауты: Целевой сервер недоступен или блокирует ICMP-запросы. Попробуйте заменить адрес проверки на другой.
- Ошибки интерфейса: Проблема на уровне драйвера, физического подключения или конфигурации фаервола.
Распространенная проблема — «залипание» статуса. Интернет восстановлен, но роутер продолжает считать канал нерабочим. Помогает ручной сброс статуса или временное отключение правила маршрутизации. Также проверьте, не блокирует ли фаервол исходящие ICMP-запросы от самого роутера, так как детектор проходит через цепочки вывода.
Лучшие практики и ограничения
Несмотря на полезность, у механизма есть технические ограничения. Частые опросы множества интерфейсов создают нагрузку на процессор, особенно на моделях начального уровня (RB750, hAP lite). В таких случаях рекомендуется сокращать количество проверяемых адресов.
Зависимость от DNS: если детектор настроен на проверку доменных имен, а DNS-серверы недоступны, система ложно диагностирует отсутствие интернета. Всегда используйте прямые IP-адреса для проверок.
Разделяйте логику: Детектор должен только сообщать о статусе. Принятие решений о маршрутизации выносите в отдельные скрипты или правила. Это упрощает отладку: если что-то пойдет не так, вы точно знаете, где искать ошибку — в механизме обнаружения или в механизме реакции.
При миграции с RouterOS v6 на v7 учитывайте изменения в архитектуре. Настройки могут не перенестись автоматически, а синтаксис скриптов мог измениться. Перед обновлением всегда делайте бэкап конфигурации.
Часто задаваемые вопросы
Может ли детектор интернета заменить полноценный мониторинг?
Нет, детектор — это инструмент для внутреннего принятия решений роутером. Для сбора статистики, графиков и алертов лучше использовать внешние системы (Zabbix, The Dude), которые собирают SNMP-данные.
Почему детектор показывает «online», а интернета у клиентов нет?
Детектор проверяет доступность сети для самого роутера, а не для конечных пользователей. Проблема может быть в ошибках NAT, настройках фаервола, DNS или параметрах MTU/MRU.
Как часто нужно менять адреса для проверки?
В обычной ситуации адреса менять не нужно. Однако если конкретный IP часто недоступен или блокирует ICMP, его следует заменить. Рекомендуется иметь в списке 2–3 адреса от разных провайдеров.
Влияет ли работа детектора на скорость интернета?
Влияние минимально, так как пакеты весят несколько байт. Однако на очень медленных или лимитированных каналах (спутниковый интернет, GPRS) даже этот трафик стоит учитывать, увеличивая интервалы проверки.
Работает ли детектор на беспроводных интерфейсах?
Да, детектор может отслеживать Wi-Fi интерфейсы (например, клиентский режим). Однако беспроводное соединение менее стабильно, поэтому количество ложных срабатываний может быть выше.