
При работе с RouterOS часто требуется направлять часть пакетов через защищённый туннель, оставляя остальной поток в основном канале. Такое разбиение помогает изолировать служебные подключения, доступ к корпоративным ресурсам или трафик отдельных клиентов. Для корректной конфигурации важно учитывать тип VPN, порядок загрузки маршрутов и взаимосвязь между правилами маркировки и таблицами маршрутизации.
Перед настройкой стоит определить конкретные подсети, которые должны идти через туннель, а также проверить, поддерживает ли выбранный протокол передачу маршрутов или понадобится ручное добавление статических записей. MikroTik позволяет гибко управлять потоками за счёт mangle-правил, PBR и собственных таблиц маршрутизации, поэтому структура конфигурации должна быть чёткой, без пересекающихся условий.
При создании схемы следует проверить MTU интерфейсов, порядок правил в Firewall, корректность маршрутов и наличие ответа от удалённого VPN-сервера. Это снижает риск зацикливания трафика, пропадания доступа к сети или непредвиденной перегрузки CPU. Дополнительно полезно вывести отладочные данные через torch, ping и traceroute, чтобы увидеть реальное движение пакетов.
Подготовка интерфейсов и создание VPN-туннеля в RouterOS

Перед созданием туннеля необходимо проверить состояние физических и логических интерфейсов, чтобы исключить конфликтующие настройки. Для работы через WAN-интерфейс должны быть заданы корректные IP-адреса и шлюз по умолчанию, иначе установление сессии будет прерываться.
- Проверить IP-адреса на WAN и LAN: /ip address print.
- Убедиться в отсутствии DHCP-клиентов и статических маршрутов, которые могут перехватывать трафик VPN.
- Отключить старые PPP-профили, если они связаны с ранее созданными туннелями.
После проверки интерфейсов можно переходить к созданию профиля подключения. Конкретные параметры зависят от выбранного протокола, но в RouterOS обычно используются L2TP/IPsec, SSTP или OpenVPN. Важно задать точный адрес сервера, шифрование и учетные данные, иначе устройство не поднимет сессию.
- Создать профиль: /ppp profile add name=vpn-profile use-mpls=no use-compression=no.
- Добавить секреты для подключения: /ppp secret add name=user password=pass profile=vpn-profile.
- Создать VPN-клиент: /interface l2tp-client add connect-to=X.X.X.X user=user password=pass use-ipsec=yes ipsec-secret=key.
После запуска туннеля стоит убедиться, что интерфейс появился в списке: /interface print. Отсутствие адресов или статус connecting указывает на ошибку параметров, блокировку на стороне провайдера либо несоответствие ключей IPsec.
Для стабильной работы рекомендуется задать фиксированное MTU и включить проверку доступности сервера с помощью netwatch, чтобы при падении туннеля устройство автоматически переключало маршруты.
Настройка маршрутов для направления выбранного трафика в VPN

После подъёма туннеля необходимо определить, какой трафик должен уходить через VPN-интерфейс. Для этого создаются статические маршруты с указанием отдельной таблицы, чтобы исключить смешивание потоков и случайную отправку пакетов в основной канал.
Перед добавлением маршрутов стоит проверить, получил ли туннельный интерфейс удалённый адрес: /ip address print. Если адрес отсутствует, RouterOS не сможет установить маршрут по следующему хопу.
Создание отдельной таблицы маршрутизации выполняется через параметр routing table. Это позволяет изолировать правила, связанные с VPN-потоком:
/routing table add name=vpn-route
Затем добавляется маршрут, указывающий путь через интерфейс туннеля:
/ip route add dst-address=0.0.0.0/0 gateway=<VPN-INTERFACE> routing-table=vpn-route
Если требуется направить только отдельные подсети, вместо нулевого маршрута задаются конкретные диапазоны. Например, чтобы отправлять запросы в подсеть 10.20.30.0/24:
/ip route add dst-address=10.20.30.0/24 gateway=<VPN-INTERFACE> routing-table=vpn-route
После создания маршрутов следует проверить их состояние: /ip route print where routing-table=vpn-route. Неверный шлюз, неправильный интерфейс или отсутствие ответа от удалённой стороны приводят к метке unreachable, что указывает на необходимость проверки туннеля и параметров IPsec.
Создание и применение mangle-правил для маркировки пакетов

Маркировка пакетов в разделе /ip firewall mangle позволяет направлять выбранный трафик в отдельный маршрут или таблицу. Основой служит точное определение критериев: интерфейс, адрес назначения, протокол, порт, маршрутная таблица или наличие установленного соединения.
Для пометки исходящих пакетов создаётся правило в цепочке prerouting или output. Например, чтобы выделить трафик определённого устройства, указывается источник src-address и действие mark-routing с собственным тегом. Важно включать флаг passthrough=no, если требуется остановить дальнейшую обработку пакета и исключить конфликт с другими правилами.
При маршрутизации через VPN используется отдельная таблица, созданная в /ip route. Маркирование, выполненное через mangle, связывает соединения и последующие пакеты с нужной таблицей. Ошибка – маркировать только пакеты без пометки соединений. Чтобы избежать этого, добавляют правило в цепочке prerouting с действием mark-connection, а затем второе правило, которое помечает сами пакеты по распознанному соединению.
Перед вводом в эксплуатацию конфигурацию проверяют через torch или connection tracking для подтверждения, что метки применяются к нужным потокам. При обнаружении неправильной маркировки корректируется порядок правил, поскольку RouterOS выполняет их последовательно.
Настройка policy-based routing для разделения потоков

В разделе /ip route создаётся таблица с указанием шлюза VPN-интерфейса. В параметре routing-mark указывается тег, присвоенный пакетам на этапе mangle. Таблица должна содержать как основной маршрут через туннель, так и маршрут по умолчанию, если требуется перенаправлять весь поток выбранной категории.
При работе с несколькими каналами важно разделять метки, чтобы избежать пересечения потоков. Для каждого VPN-подключения формируются собственные маршруты, а порядок их обработки в RouterOS зависит только от марки, поэтому при корректной настройке таблицы не конфликтуют.
Для проверки используется команда /ip route print detail where routing-mark=имя_метки. Отсутствие активного маршрута говорит о проблемах с доступностью шлюза или неверной маской сети на VPN-стороне. Дополнительно проверяется статус туннеля через /interface print.
При передаче трафика, чувствительного к задержкам, рекомендуется фиксировать конкретные диапазоны адресов и исключать широкие правила. Это уменьшает вероятность попадания в некорректную таблицу и ускоряет обработку. При необходимости корректировки структуры правил применяется их последовательная сортировка без перекрывающихся условий.
Проверка доступности узлов и диагностика таблиц маршрутизации

Для проверки доступности узлов через VPN используется встроенная утилита MikroTik – ping. Рекомендуется проверять соединение как по IP-адресу конечного узла, так и по внутреннему адресному пространству VPN. Пример команды:
/ping 10.8.0.1 count=5
| Параметр | Описание | Рекомендация |
|---|---|---|
| Dst. Address | Целевая сеть или IP | Убедиться, что диапазон адресов совпадает с VPN-сетью |
| Gateway | Шлюз для маршрута | Проверить, что шлюз доступен и относится к VPN-интерфейсу |
| Distance | Метрика маршрута | Выбирать маршрут с наименьшей метрикой для основного трафика |
| Scope | Область видимости маршрута | Для VPN-директоров рекомендуется scope=30–255 |
Для более детального анализа используется traceroute, позволяющий выявить узлы, где теряется трафик. Команда:
/tool traceroute 8.8.8.8
Проверка корректности маршрутов включает контроль таблиц mangle, если трафик маркируется для VPN. Команда:
/ip firewall mangle print
В случаях недоступности узлов следует сверять: наличие маршрута до VPN-шлюза, активность интерфейса, корректность масок сети и приоритет маршрутов. Рекомендуется сохранять конфигурацию после внесения изменений:
/system backup save name=vpn-check
Настройка fallback-механизма при недоступности VPN-канала

Fallback-механизм позволяет перенаправлять трафик через альтернативный маршрут при потере соединения VPN. Настройка реализуется через проверку доступности VPN-шлюза и динамическое изменение маршрутов.
- Создание маршрута по умолчанию через VPN:
/ip route add dst-address=0.0.0.0/0 gateway=10.8.0.1 distance=1 check-gateway=pingПараметр
check-gateway=pingпозволяет автоматически отключать маршрут, если VPN-шлюз недоступен. - Добавление резервного маршрута через основной интернет-канал:
/ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1 distance=2Маршрут с большей метрикой активируется автоматически, когда VPN-шлюз недоступен.
- Настройка скрипта для мониторинга VPN:
- Создать скрипт проверки состояния интерфейса VPN:
- Запланировать выполнение скрипта каждые 30 секунд:
/system script add name=vpn-fallback source=":if ([/interface get [find name=vpn-out] running]=false) do={/ip route enable [find gateway=192.168.1.1]} else={/ip route disable [find gateway=192.168.1.1]}"/system scheduler add name=check-vpn interval=30s on-event=vpn-fallback - Проверка работы fallback:
- Отключить VPN и выполнить
/ping 8.8.8.8для проверки прохождения трафика через резервный маршрут. - Возобновить VPN и убедиться, что основной маршрут восстановлен.
- Отключить VPN и выполнить
- Рекомендации:
- Использовать
check-gateway=pingтолько для стабильных IP-шлюзов. - Скрипт мониторинга можно расширять для уведомлений через email или Telegram.
- Следить за метриками маршрутов, чтобы избежать конфликтов при переключении.
- Использовать
Вопрос-ответ:
Как проверить, через какой интерфейс MikroTik проходит определённый трафик после настройки VPN?
Для контроля маршрутизации можно использовать инструменты /ip route print и /tool sniffer. В таблице маршрутов отображается шлюз и интерфейс для каждой сети. Если трафик маркируется mangle-правилами, можно дополнительно проверить счетчики пакетов, чтобы убедиться, что трафик идет через VPN-интерфейс.
Что делать, если после настройки VPN часть трафика идет напрямую, минуя туннель?
Причина чаще всего в неправильной настройке маршрутов или mangle-правил. Нужно проверить: 1) метки пакетов (/ip firewall mangle print), 2) маршруты с соответствующими метками (/ip route print), 3) наличие конфликтующих маршрутов по умолчанию. Исправление включает корректировку dst-address и gateway, а также проверку distance маршрутов, чтобы VPN-канал имел приоритет.
Как настроить fallback-механизм на случай недоступности VPN?
Создаётся основной маршрут через VPN с check-gateway=ping и резервный маршрут через основной интернет-канал с большей метрикой. Дополнительно можно использовать скрипт, который проверяет состояние VPN-интерфейса и включает резервный маршрут при недоступности VPN, затем отключает его при восстановлении соединения.
Можно ли направить трафик отдельных устройств в локальной сети через VPN, а остальной трафик напрямую?
Да, это делается через mangle-правила и маршруты по меткам. Для каждого устройства создаётся правило маркировки пакетов по src-address, затем создаётся маршрут с использованием этой метки через VPN-шлюз. Остальной трафик будет использовать маршрут по умолчанию через основной интернет.
Как правильно разделить трафик между VPN и обычным интернет-соединением на MikroTik?
Для разделения трафика используют mangle-правила и маршруты с метками. Сначала создаются правила маркировки пакетов по источнику или типу трафика через /ip firewall mangle add. Каждой метке присваивается маршрут через VPN-шлюз с помощью /ip route add routing-mark=метка gateway=VPN-шлюз. Оставшийся трафик автоматически идет через маршрут по умолчанию, настроенный на основной интернет. После настройки рекомендуется проверять счетчики пакетов в mangle и тестировать доступ к ресурсам, чтобы убедиться, что правила применяются корректно.
