Два провайдера на MikroTik: резервирование интернет-канала

Что резервируем и где остаются точки отказа

LAN → MikroTik
Рабочие места и серверы

WAN1 — основной
Проверка через своего провайдера

WAN2 — резервный
Отдельная проверка и выход

При отказе основного новые подключения переходят на резерв.

Уточните физические трассы: два договора могут использовать одну кабельную канализацию, один ввод или общее питание оборудования. Для резервного LTE/5G проверьте покрытие, лимит трафика, CGNAT, задержку и устойчивость под нагрузкой. Управление роутером лучше выделить в отдельный VLAN, а тесты проводить с доступом из локальной сети. Пример сегментации — в инструкции по VLAN на MikroTik.

IP-план учебной схемы и условия запуска

Сети 192.0.2.0/24 и 198.51.100.0/24 — документационные примеры. Они не заработают у вашего оператора: замените адреса и шлюзы данными договора. Контрольные адреса — примеры публичных узлов; заранее проверьте доступность ICMP и допустимость использования. Это не настройка DNS для клиентов.

• ether1 и ether2 не входят в LAN bridge.
• В основной таблице main нет конкурирующих default route, DHCP/PPPoE-маршрутов и ECMP.
• Нет правил policy routing, которые отправляют тестовый LAN в другую таблицу.
• Базовый firewall уже защищает роутер и пропускает разрешённый исходящий трафик LAN. Подробная политика разобрана в статье о firewall MikroTik.
• Схема только IPv4: IPv6 требует отдельного проектирования и тестов.

Если условия отличаются, сначала составьте план изменений. Нельзя отключать все старые маршруты наугад или удалять ether-порт из bridge, через который вы сейчас управляете роутером.

Шаг 1. Сохраните конфигурацию и проверьте исходное состояние

Где: Terminal в WinBox или SSH из LAN. Зачем: Сохранить текстовую конфигурацию и увидеть параметры, влияющие на выбор пути.

/export file=before-dualwan
/system resource print
/interface print
/interface bridge port print
/ip address print detail
/ip dhcp-client print detail
/interface pppoe-client print detail
/ip route print detail where dst-address=0.0.0.0/0
/routing rule print detail
/ip firewall mangle print detail

Ожидаемый результат: Файл before-dualwan.rsc и фактический список интерфейсов, адресов и маршрутов. Скачайте экспорт из Files и храните защищённо; он может содержать чувствительные сведения.

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

Перед небольшими группами изменений включайте Safe Mode клавишами Ctrl+X в терминале и проверяйте отметку SAFE. Он помогает вернуть изменения при потере сессии, но не заменяет резервную копию и локальный доступ. Завершайте группу и фиксируйте её только после проверки. Подробности — в документации по управлению конфигурацией.

Шаг 2. Подготовьте WAN-адреса и защиту второго входа

Где: RouterOS, только для чистой учебной схемы с двумя статическими каналами. Зачем: Добавить выданные адреса на отдельные интерфейсы.

/ip address add address=192.0.2.2/30 interface=ether1 comment="DW79-WAN1"
/ip address add address=198.51.100.2/30 interface=ether2 comment="DW79-WAN2"
/ip address print detail where comment~"^DW79-"
/ping 192.0.2.1 src-address=192.0.2.2 count=5
/ping 198.51.100.1 src-address=198.51.100.2 count=5

Ожидаемый результат: Адреса назначены без дублирования, доступны оба шлюза. Отсутствие ответа ICMP проверяйте вместе с ARP и условиями оператора; повторное добавление создаёт дубликаты.

В WinBox это IP → Addresses; членство портов проверяется в Bridge → Ports. Если адреса уже настроены, команды add не выполняют повторно. Проблемы маски, VLAN провайдера, согласования порта и авторизации нужно исправить до маршрутизации.

Где: RouterOS после проверки существующего списка WAN. Зачем: Убедиться, что firewall относит оба интерфейса к внешним.

/interface list print
/interface list member print detail
/ip firewall filter print stats
/ip service print

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

/interface list member add list=WAN interface=ether2 comment="DW79-WAN2-list"

Назначение этой команды: включить ether2 в существующий WAN; результат — одна новая запись списка. Выполнять её нужно только если записи нет. Если списка WAN нет, сначала адаптируйте firewall целиком; имя списка само по себе ничего не блокирует. Проверяйте порядок input/forward и ограничения удалённого управления, а не только наличие записей.

Шаг 3. Закрепите контрольные адреса за своими каналами

Где: RouterOS, таблица main. Зачем: Создать отдельные /32-маршруты, через которые будут разрешаться рекурсивные шлюзы.

/ip route add dst-address=1.1.1.1/32 gateway=192.0.2.1 routing-table=main scope=10 comment="DW79-PROBE1"
/ip route add dst-address=8.8.8.8/32 gateway=198.51.100.1 routing-table=main scope=10 comment="DW79-PROBE2"
/ping 1.1.1.1 src-address=192.0.2.2 count=5
/ping 8.8.8.8 src-address=198.51.100.2 count=5
/ip route print detail where comment~"^DW79-PROBE"

Ожидаемый результат: Каждый контрольный адрес достигается через назначенный шлюз. src-address выбирает исходный адрес; нужный выход обеспечивает маршрут /32, а не само указание src-address.

/32 — маршрут к одному узлу. Он специфичнее default route и не должен переключаться вместе с обычным трафиком. Иначе проверка основного провайдера может уйти через резерв и ошибочно показать, что основной исправен. scope=10 разрешает использовать этот маршрут для рекурсивного поиска следующего шлюза.

Проверьте, что ваши output-правила не запрещают ICMP-проверки от самого роутера и ответы на них допускаются. Пропуск LAN → интернет в forward не означает, что служебный трафик роутера в output разрешён.

Шаг 4. Добавьте основной и резервный default route

Где: RouterOS после успешного теста обоих контрольных узлов. Зачем: Выбирать основной выход, пока доступен его внешний контрольный адрес.

/ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=main distance=1 check-gateway=ping scope=30 target-scope=11 comment="DW79-DEFAULT1"
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=main distance=2 check-gateway=ping scope=30 target-scope=11 comment="DW79-DEFAULT2"
/ip route print detail where comment~"^DW79-"
/routing route print detail where dst-address=0.0.0.0/0

Ожидаемый результат: При исправных каналах основной маршрут выбран для пересылки, резервный доступен как кандидат. В immediate-gw ожидается реальный шлюз с интерфейсом, а не только адрес контрольного узла.

distance задаёт предпочтение среди подходящих маршрутов: меньше — предпочтительнее. check-gateway=ping проверяет рекурсивный шлюз. target-scope=11 позволяет разрешить его через /32 со scope=10; default route со scope=30 не должен становиться способом подтвердить самого себя через другой выход.

Принцип рекурсии описан в IP Routing, базовая конфигурация — в руководстве MikroTik по failover. При дополнительных таблицах, VRF и одинаковых адресах шлюзов у двух модемов схема требует изменений: одного копирования этих строк недостаточно.

Шаг 5. Проверьте NAT на обоих выходах

Где: RouterOS, до добавления новых правил. Зачем: Найти существующие преобразования, исключения для VPN и возможные перекрытия.

/ip firewall nat print detail
/ip firewall nat print stats

Ожидаемый результат: Видны порядок и счётчики правил. Если уже есть подходящий masquerade по out-interface-list=WAN, новые дублирующие правила не нужны.

Где: Только если для учебного LAN нет подходящего существующего NAT. Зачем: Разрешить исходящий IPv4 из LAN через каждый канал.

/ip firewall nat add chain=srcnat src-address=192.168.50.0/24 out-interface=ether1 action=masquerade comment="DW79-NAT1"
/ip firewall nat add chain=srcnat src-address=192.168.50.0/24 out-interface=ether2 action=masquerade comment="DW79-NAT2"

Ожидаемый результат: Новые исходящие соединения используют адрес соответствующего WAN. Сопоставьте счётчики с тестом с компьютера LAN; ping с самого роутера не проверяет этот NAT.

Исключения для трафика site-to-site VPN должны находиться перед общим srcnat, если выбранная VPN-схема их требует. Для фиксированных внешних IP возможен src-nat с заданным адресом; выбор согласуйте с поведением connection tracking. NAT не является заменой firewall.

Преобразование запоминается для соединения, поэтому после изменения правил проверяйте новое соединение. Не очищайте всю таблицу соединений в рабочее время ради одного теста. Особенности masquerade и повторного использования состояний объясняет официальная документация NAT.

Шаг 6. Проверьте доступ именно с компьютера LAN

Где: PowerShell на тестовом рабочем месте Windows. Зачем: Разделить IP-доступность, DNS и подключение по HTTPS.

ipconfig /all
Resolve-DnsName example.com
Test-NetConnection example.com -Port 443 -InformationLevel Detailed
tracert -d 9.9.9.9

Ожидаемый результат: У компьютера правильный шлюз и корпоративный DNS, имя разрешается, TCP 443 доступен. Отсутствие отдельных ответов tracert не равно обрыву: промежуточные узлы могут фильтровать ICMP.

Выберите также реальный рабочий сервис: облачную 1С, почту, VPN или CRM. Запишите внешний IP через согласованный сервис определения адреса либо журнал удалённого сервера. После переключения повторите проверку новым подключением.

DNS должен быть достижим через резерв. Не используйте единственный DNS провайдера WAN1, если он доступен только из его сети. В доменной инфраструктуре не заменяйте корпоративный DNS публичным на клиентах: настройте устойчивые форвардеры и доступ DNS-сервера к обоим каналам. Выбранные probe закреплены за определёнными каналами: не делайте один такой адрес единственным DNS, иначе при отказе его канала сломается разрешение имён. Для проверки предпочтительны отдельные согласованные узлы. Не открывайте рекурсивный DNS роутера для интернета.

Шаг 7. Испытайте отказ и возврат основного канала

Где: Локальный Terminal из LAN, согласованное тестовое окно. Зачем: Сымитировать потерю основного интерфейса, не затронув LAN.

/interface disable ether1
/ip route print detail where dst-address=0.0.0.0/0
/interface monitor-traffic ether2 once

Ожидаемый результат: Основной путь недоступен, новые соединения с LAN проходят через WAN2. Это тест отказа линии, а не обрыва интернета за живым шлюзом.

Где: Та же локальная сессия после записи результатов. Зачем: Вернуть физический канал и проверить обратное переключение.

/interface enable ether1
/ip route print detail where dst-address=0.0.0.0/0

Ожидаемый результат: После успешного контроля основной путь снова предпочтителен. Проверьте новые подключения и рабочие приложения; возврат может повторно изменить внешний IP.

Второй обязательный сценарий — отказ за шлюзом, когда Ethernet и ARP остаются исправными. В лаборатории это моделируют отключением upstream на отдельном эмуляторе провайдера или фильтрацией контрольного трафика именно за CPE. Не подменяйте такой тест простым disable default route: он проверяет выбор маршрута, но не обнаружение аварии.

Записывайте четыре времени: начало отказа, изменение маршрута, первое успешное новое подключение, восстановление конкретного приложения. Проверяйте также отказ резервного канала, отказ обоих и перезапуск роутера. Не обещайте «переключение за секунду»: результат зависит от интервалов проверки, потерь, приложений и переподключения.

Что произойдёт с 1С, VPN и телефонией

Смена маршрута не переносит TCP-сеанс между двумя публичными IP. Сохранённое NAT-состояние тоже не превращает адрес WAN1 в допустимый адрес WAN2. Массовый сброс conntrack оборвёт и исправные соединения; если очистка нужна для диагностики, её делают адресно и по согласованному плану. Механизм состояний разобран в Connection tracking.

Для входящих подключений одного failover недостаточно. Публикация на IP первого оператора не станет доступна через IP второго автоматически. Нужны отдельные адреса/пробросы, корректный обратный путь, поддержка клиентов и DNS либо внешний шлюз с устойчивым адресом. CGNAT на резерве может исключать прямые входящие подключения.

DHCP, PPPoE и два одинаковых шлюза

Основной пример использует статические адреса. При DHCP шлюз и маршрут получает клиент; при PPPoE рабочим выходом обычно служит pppoe-интерфейс. Подставлять Ethernet-шлюз из таблицы выше в эти схемы нельзя.

Где: RouterOS, только чтение динамических подключений. Зачем: Узнать действительный адрес, шлюз и источник default route.

/ip dhcp-client print detail
/interface pppoe-client print detail
/ip route print detail where dst-address=0.0.0.0/0
/routing route print detail where dst-address=0.0.0.0/0

Ожидаемый результат: Определено, какие маршруты создаёт клиент и куда ведут реальные next-hop. Сохраните lease-параметры и поведение после переподключения.

• Простой DHCP-резерв: разные default-route-distance дают приоритет, но контроль только шлюза не доказывает доступность интернета.
• Рекурсия с DHCP: /32-маршрут должен получать актуальный шлюз после renew/rebind. Скрипт проверяют при получении и потере аренды; старый статический gateway оставлять нельзя.
• PPPoE: контрольный маршрут привязывают к конкретному PPPoE-каналу; проверяют MTU/MSS, разрыв и автоматическое соединение.
• Оба модема 192.168.1.1: предпочтительно изменить их внутренние подсети. Иначе потребуется точная привязка к интерфейсу/VRF и отдельная проверка разрешения шлюза.

Параметры DHCP-клиента и установка маршрутов описаны в официальном руководстве DHCP. Для динамической схемы готовьте отдельный конфигурационный вариант, а не смесь статического примера и оставшихся автоматических default route.

Два контрольных узла, деградация и защита от дребезга

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

Вариант из руководства MikroTik — дополнительные рекурсивные маршруты одинакового приоритета через разные цели того же оператора. Один доступный путь может сохранить канал; это не проверка большинства. Не добавляйте второй probe без явного понимания, когда именно оператор должен считаться неисправным.

Полный обрыв и деградация — разные аварии. Для телефонии может быть критичен джиттер, для файлов — пропускная способность, для веб-сервиса — HTTPS-ответ. Netwatch поддерживает несколько типов проверок; перед автоматическим изменением маршрутов настройте диагностический режим и проверьте пороги. Не запускайте одновременно независимые скрипты, которые противоречиво включают и отключают один маршрут.

• Определите условия отказа и устойчивого восстановления.
• Не реагируйте на единичную потерю одного пакета.
• Если нужен отложенный возврат, реализуйте и протестируйте его отдельно: базовая distance-схема вернётся после признания маршрута доступным.
• Не сокращайте глобальные таймеры без оценки нагрузки и ложных переключений.

Выберите режим: резерв, ручной выбор или балансировка

Далее даны расширения базовой схемы. Третий канал можно добавить к обычному failover. PCC — отдельный режим с таблицами и mangle; его включают после подготовки всех частей. Политика по routing rules показана как альтернатива PCC. Не складывайте все примеры в один импорт: сначала выберите нужный сценарий.

Как добавить третьего провайдера в резервную цепочку

Где: RouterOS; ether3 свободен, не входит в LAN bridge и проверен локальный доступ. Зачем: Расширить статическую схему: WAN3 — третья очередь, без балансировки.

/ip address add address=203.0.113.2/30 interface=ether3 comment="DW79-WAN3"
/interface list member add list=WAN interface=ether3 comment="DW79-WAN3-list"
/ip route add dst-address=208.67.222.222/32 gateway=203.0.113.1 routing-table=main scope=10 comment="DW79-PROBE3"
/ip route add dst-address=0.0.0.0/0 gateway=208.67.222.222 routing-table=main distance=3 check-gateway=ping scope=30 target-scope=11 comment="DW79-DEFAULT3"
/ip firewall nat add chain=srcnat src-address=192.168.50.0/24 out-interface=ether3 action=masquerade comment="DW79-NAT3"
/ping 208.67.222.222 src-address=203.0.113.2 count=5
/ip route print detail where comment~"^DW79-"

Ожидаемый результат: WAN3 имеет свой адрес, контрольный путь и NAT. Он используется для новых соединений, когда недоступны маршруты приоритетов 1 и 2.

203.0.113.0/24 — ещё одна документационная сеть: замените её реальными данными. Список WAN должен существовать; не добавляйте уже имеющегося участника или NAT. Для LTE за модемом адреса, шлюз и CGNAT определяются его режимом, а не этим примером.

По строкам: address назначает адрес; list member распространяет существующую WAN-политику на ether3; /32 закрепляет probe за WAN3; default route задаёт третью очередь; NAT обслуживает исходящий LAN; ping и print проверяют результат. Испытайте отказ WAN1, затем WAN1+WAN2 и возврат в обратном порядке. Одновременно проверьте, что основной трафик не исчерпает мобильный тариф.

Как переключить канал вручную, не отключая Ethernet

Где: Локальная сессия RouterOS, базовый failover в main. Зачем: Временно исключить основной default route, сохранив его /32 для наблюдения.

/ip route disable [find where comment="DW79-DEFAULT1"]
/ip route print detail where dst-address=0.0.0.0/0
/ip route enable [find where comment="DW79-DEFAULT1"]

Ожидаемый результат: Первая команда выбирает следующий доступный путь; print позволяет его увидеть; последняя возвращает основной маршрут в отбор. Между disable и enable проведите тест с LAN, не вставляйте весь блок без паузы.

Перед выполнением убедитесь, что комментарий соответствует ровно одному объекту. Отключение default route не имитирует отказ upstream: это управляемый выбор пути. В PCC одного main-маршрута недостаточно — трафик обслуживают другие таблицы. Если работает контроллер качества ниже, сначала отключите его scheduler, иначе он вправе снова включить маршрут.

Другой способ — временно поднять distance основного выше резерва, записав прежнее значение. Для обслуживания задавайте понятное состояние «выведен вручную», а не правьте одновременно distance, mangle и DHCP-скрипт. При возврате существующие соединения не обязаны сохраниться.

По каким признакам считать канал неисправным

Практическая политика может звучать так: «оба независимых ICMP-узла недоступны три проверки подряд — исключаем канал; хотя бы один стабильно доступен шесть проверок — допускаем обратно». Это проектный пример, а не универсальная рекомендация интервалов. Для телефонии отдельно оценивают потери и джиттер, для удалённой 1С — время ответа и разрывы VPN.

Не переключайте весь офис из-за HTTP 500 одного сайта или недоступности единственного DNS. Загрузка WAN 95% тоже не означает аварию: сначала проверьте очереди, перегрузку upload, bufferbloat и требования приоритета. Переключение на ещё более медленный резерв может ухудшить ситуацию.

Netwatch: измерение доступности, потерь и задержки

Где: RouterOS 7 с поддержкой расширенного Netwatch; сначала только мониторинг. Зачем: Добавить вторую контрольную цель WAN1 и две серии ICMP-проверок без изменения маршрутов.

/ip route add dst-address=1.0.0.1/32 gateway=192.0.2.1 routing-table=main scope=10 comment="DW79-QPROBE1B"
/tool netwatch add host=1.1.1.1 src-address=192.0.2.2 type=icmp interval=10s timeout=3s packet-count=10 packet-interval=200ms thr-avg=150ms thr-max=2s thr-jitter=100ms thr-stdev=1s thr-loss-percent=20% comment="DW79-Q1"
/tool netwatch add host=1.0.0.1 src-address=192.0.2.2 type=icmp interval=10s timeout=3s packet-count=10 packet-interval=200ms thr-avg=150ms thr-max=2s thr-jitter=100ms thr-stdev=1s thr-loss-percent=20% comment="DW79-Q1B"
/tool netwatch print detail
/tool netwatch print stats

Ожидаемый результат: Обе цели проверяются через WAN1, видны состояние и статистика. Роутер не переключается по этим записям, пока не включён отдельный контроллер.

• host — цель; src-address — источник. Выход фиксирует маршрут /32, а не один src-address.
• interval — период проверок, packet-count и packet-interval — размер и шаг серии, timeout — ожидание ответа.
• thr-loss-percent, thr-avg, thr-max, thr-jitter, thr-stdev — пороги потерь и разных характеристик RTT. Срабатывание любого применимого порога может дать down.
• Проверьте все эффективные значения в detail: неуказанный параметр может иметь влияющее на результат значение по умолчанию.

Числа в примере — стартовые значения для лаборатории, не норматив SLA. Десять пакетов дают грубую оценку потерь; для выводов нужна история. Расширенные типы появились в RouterOS 7.4, доступность конкретных параметров проверяйте в справке установленной версии.

TCP-проверку порта можно добавить отдельным наблюдением:

Где: Тот же RouterOS; цель 1.1.1.1 уже закреплена за WAN1. Зачем: Отдельно проверить установление TCP к публичному HTTPS-порту.

/tool netwatch add host=1.1.1.1 src-address=192.0.2.2 type=tcp-conn port=443 interval=15s timeout=3s comment="DW79-TCP1"

Ожидаемый результат: Появилась независимая TCP-проба. Она не проверяет TLS-сертификат или содержимое HTTPS и не управляет маршрутом.

Где: Наблюдение Netwatch; 1.1.1.1 закреплён за WAN1. Зачем: Проверить ответ выбранного DNS по реальному запросу, отдельно от ICMP.

/tool netwatch add host=example.com type=dns dns-server=1.1.1.1 record-type=A src-address=192.0.2.2 interval=30s timeout=3s comment="DW79-DNS1"
/tool netwatch print stats where comment="DW79-DNS1"

Ожидаемый результат: Появилась DNS-проба для записи A example.com. Down здесь относится к данному DNS-маршруту; он не является достаточным основанием отключить весь WAN.

Для HTTPS используйте принадлежащий вам endpoint, ожидаемый код ответа, действительный сертификат, доверенный УЦ и закрепление его IP за нужным WAN. У DNS-пробы явно выберите резолвер. Если имя или IP endpoint меняется, обновлять нужно и контрольный маршрут. Подробные параметры — в руководстве Netwatch.

Автоматическое исключение по качеству и задержка возврата

Ниже — учебный контроллер только базового main failover. Netwatch измеряет, scheduler принимает решение; других скриптов управления этим маршрутом быть не должно. Контроллер не трогает /32-пробы: они должны продолжать работать после отключения default route.

Где: RouterOS после настройки двух Netwatch-проб выше. Зачем: Создать контроллер с тремя плохими и шестью хорошими наблюдениями; запуск по расписанию пока выключен.

/system script add name=DW79-QCTRL policy=read,write,test source={
    :global DW79bad
    :global DW79good
    :if ([:typeof $DW79bad] = "nothing") do={ :set DW79bad 0 }
    :if ([:typeof $DW79good] = "nothing") do={ :set DW79good 0 }
    :local a [/tool netwatch find where comment="DW79-Q1"]
    :local b [/tool netwatch find where comment="DW79-Q1B"]
    :local r [/ip route find where comment="DW79-DEFAULT1"]
    :if (([:len $a] != 1) || ([:len $b] != 1) || ([:len $r] != 1)) do={
        :error "DW79: expected exactly one probe and route per comment"
    }
    :local s1 [/tool netwatch get $a status]
    :local s2 [/tool netwatch get $b status]
    :if (($s1 = "down") && ($s2 = "down")) do={
        :set DW79good 0
        :if ($DW79bad < 3) do={ :set DW79bad ($DW79bad + 1) }
        :if (($DW79bad >= 3) && ([/ip route get $r disabled] = false)) do={
            /ip route set $r disabled=yes
            :log warning "DW79: main WAN1 route disabled by quality controller"
        }
    } else={
        :if (($s1 = "up") || ($s2 = "up")) do={
            :set DW79bad 0
            :if ($DW79good < 6) do={ :set DW79good ($DW79good + 1) }
            :if (($DW79good >= 6) && ([/ip route get $r disabled] = true)) do={
                /ip route set $r disabled=no
                :log info "DW79: main WAN1 route enabled after stable recovery"
            }
        } else={ :set DW79bad 0; :set DW79good 0 }
    }
}
/system scheduler add name=DW79-QCTRL interval=10s on-event=DW79-QCTRL policy=read,write,test disabled=yes

Ожидаемый результат: Сохранены script и отключённый scheduler. При unknown обоих датчиков счётчики сбрасываются. При down обоих на трёх чтениях основной маршрут исключается; при up хотя бы одного на шести чтениях возвращается.

Счётчики относятся к чтениям состояния scheduler, а не гарантированно к шести разным ICMP-сериям. Если Netwatch остановился, старое состояние может сохраняться; промышленный контроллер должен контролировать свежесть измерений. Политика «один up разрешает возврат» выбрана явно, она не равна большинству. Значения good/bad живут в окружении владельца scheduler и после перезапуска инициализируются заново.

Где: Тот же RouterOS, после проверки на отдельном стенде. Зачем: Включить контроллер и увидеть ошибки выполнения.

/system scheduler enable [find where name="DW79-QCTRL"]
/system scheduler print detail where name="DW79-QCTRL"
/log print where message~"DW79"
/system scheduler disable [find where name="DW79-QCTRL"]

Ожидаемый результат: Enable запускает контроль; print показывает состояние; log — решения и ошибки; disable останавливает автоматизацию. Последняя строка выполняется отдельно, когда нужно закончить тест или перейти к ручному обслуживанию.

Рекурсивный check-gateway продолжает быстрее обнаруживать полный обрыв. Контроллер добавляет исключение по качеству и задержку допуска, но не меняет внутренний таймер check-gateway. Для PCC нужно централизованно исключать WAN1 во всех таблицах, где он используется: этот пример управляет только DW79-DEFAULT1. Не включайте его как «готовый контроль PCC». Не отключайте проверки прав исполнения скриптов ради устранения ошибки.

Три метки: соединение, маршрут и пакет

1. Первый пакетPCC выбирает группу
2. Connection markМетка хранится в conntrack
3. Routing markВыбор таблицы для пакета
4. Packet markОтдельная задача очередей и учёта

• mark-connection закрепляет группу за соединением. Классифицируем новые connection-state=new, connection-mark=no-mark.
• mark-routing выбирает таблицу для каждого нужного пакета, включая последующие пакеты уже отмеченного соединения.
• mark-packet помечает пакет для очередей/учёта; не заменяет routing mark.
• passthrough=yes продолжает обработку mangle; passthrough=no прекращает её после назначения нужной метки.

prerouting используется до выбора маршрута пересылаемого трафика; output — для ответов и исходящих соединений самого роутера. Новую таблицу RouterOS 7 создают с fib до использования в mark-routing. Метки не синхронизируются автоматически с удалённым устройством. Справочник параметров — Mangle.

Подготовьте таблицы: у каждого предпочтительного WAN свой резерв

Где: Отдельный лабораторный вариант PCC поверх базовых двух WAN и /32-проб в main. Зачем: Создать две таблицы с противоположным приоритетом и проверкой внешней доступности.

/routing table add name=DW79_to1 fib
/routing table add name=DW79_to2 fib
/ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1@main routing-table=DW79_to1 distance=1 check-gateway=ping scope=30 target-scope=11 comment="DW79-T1-USE1"
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8@main routing-table=DW79_to1 distance=2 check-gateway=ping scope=30 target-scope=11 comment="DW79-T1-USE2"
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8@main routing-table=DW79_to2 distance=1 check-gateway=ping scope=30 target-scope=11 comment="DW79-T2-USE2"
/ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1@main routing-table=DW79_to2 distance=2 check-gateway=ping scope=30 target-scope=11 comment="DW79-T2-USE1"
/routing table print
/ip route print detail where comment~"^DW79-T"

Ожидаемый результат: Таблицы существуют, preferred и backup разрешаются через закреплённые /32 из main. @main указывает таблицу поиска next-hop. Main-маршруты для немаркированного трафика сохраняются.

В каждой таблице нужен исправный резерв. Иначе часть PCC-корзин продолжит отправлять новые соединения в таблицу без выхода. При аварии выбранная меткой таблица остаётся прежней, но её активный next-hop меняется. Это помогает новым соединениям, а не сохраняет старые NAT-сеансы.

Один компьютер можно направить правилом без PCC. Сначала исключают внутренние направления, затем выбирают таблицу:

Где: Альтернатива PCC, тестовый хост 192.168.50.20; FastTrack для этого трафика исключён. Зачем: Предпочитать WAN2 для внешних направлений одного хоста.

/routing rule add src-address=192.168.50.20/32 dst-address=10.0.0.0/8 action=lookup-only-in-table table=main comment="DW79-RULE-LOCAL10"
/routing rule add src-address=192.168.50.20/32 dst-address=172.16.0.0/12 action=lookup-only-in-table table=main comment="DW79-RULE-LOCAL172"
/routing rule add src-address=192.168.50.20/32 dst-address=192.168.0.0/16 action=lookup-only-in-table table=main comment="DW79-RULE-LOCAL192"
/routing rule add src-address=192.168.50.20/32 action=lookup-only-in-table table=DW79_to2 comment="DW79-RULE-HOST2"

Ожидаемый результат: Внутренние сети ищутся в main, остальное — в DW79_to2. При отказе WAN2 таблица сама допускает WAN1, потому что в ней есть резерв.

Добавьте свои публичные внутренние/VPN-подсети в исключения. lookup допускает следующий поиск при отсутствии подходящего маршрута, lookup-only-in-table ограничивает поиск выбранной таблицей. Но lookup-only не означает «только WAN2», если сама таблица содержит WAN1. Для запрета запасного IP нужна отдельная таблица без резервного выхода и проверенный отказ при недоступности. Совместная работа rules и mangle требует понимания приоритета; в данном примере выбираем один механизм. См. Policy Routing.

PCC: полная последовательность балансировки двух WAN

PCC хеширует выбранные поля и распределяет новые соединения по корзинам. Пример ниже — 1:1; приблизительно поровну по числу соединений, без гарантии равного количества байт. Вариант предназначен для одного bridge-lan и LAN 192.168.50.0/24, без Hotspot, действующих mangle-политик и routing rules из предыдущего альтернативного примера.

Где: Тестовый RouterOS до включения PCC. Зачем: Убрать FastTrack из пути лабораторного трафика и проверить запас CPU.

/ip firewall filter print detail where action=fasttrack-connection
/ip firewall filter disable [find where action=fasttrack-connection]
/system resource print

Ожидаемый результат: FastTrack выключен для лабораторного теста. Запишите исходные состояния правил; не включайте все найденные правила обратно одной командой. Уже ускоренные старые соединения проверяйте отдельно, тестируйте новые.

В production можно исключить маркированные соединения из согласованного FastTrack-правила, например matcher connection-mark=no-mark, сохранив остальные условия. Это не решает случай policy routing по rules без connection mark: такой трафик тоже требуется исключить. Производительность без ускорения измеряют под нагрузкой.

Где: RouterOS, до создания classifier. Зачем: Оставить локальные сети, WAN-служебные адреса и пробы вне балансировки.

/ip firewall address-list add list=DW79_LOCAL address=10.0.0.0/8 comment="DW79-LOCAL10"
/ip firewall address-list add list=DW79_LOCAL address=172.16.0.0/12 comment="DW79-LOCAL172"
/ip firewall address-list add list=DW79_LOCAL address=192.168.0.0/16 comment="DW79-LOCAL192"
/ip firewall address-list add list=DW79_LOCAL address=192.0.2.0/30 comment="DW79-LOCALWAN1"
/ip firewall address-list add list=DW79_LOCAL address=198.51.100.0/30 comment="DW79-LOCALWAN2"
/ip firewall address-list add list=DW79_LOCAL address=1.1.1.1 comment="DW79-LOCALPROBE1"
/ip firewall address-list add list=DW79_LOCAL address=8.8.8.8 comment="DW79-LOCALPROBE2"
/ip firewall address-list add list=DW79_LOCAL address=224.0.0.0/4 comment="DW79-LOCALMULTICAST"
/ip firewall address-list add list=DW79_LOCAL address=255.255.255.255 comment="DW79-LOCALBROADCAST"

Ожидаемый результат: Сформирован список обхода для примера. Добавьте собственные VPN/служебные/публичные внутренние подсети и дополнительные probe; адреса списка не становятся разрешёнными в firewall.

Где: RouterOS после создания DW79_to1/DW79_to2; уникальные имена и комментарии проверены. Зачем: Создать классификатор и восстановление routing mark; вход в цепочку пока отключён.

/ip firewall mangle add chain=DW79_LAN dst-address-list=DW79_LOCAL action=return comment="DW79-PCC-BYPASS"
/ip firewall mangle add chain=DW79_LAN connection-state=new connection-mark=no-mark per-connection-classifier=both-addresses-and-ports:2/0 action=mark-connection new-connection-mark=DW79_C1 passthrough=yes comment="DW79-PCC-B0"
/ip firewall mangle add chain=DW79_LAN connection-state=new connection-mark=no-mark per-connection-classifier=both-addresses-and-ports:2/1 action=mark-connection new-connection-mark=DW79_C2 passthrough=yes comment="DW79-PCC-B1"
/ip firewall mangle add chain=DW79_LAN connection-mark=DW79_C1 action=mark-routing new-routing-mark=DW79_to1 passthrough=no comment="DW79-PCC-R1"
/ip firewall mangle add chain=DW79_LAN connection-mark=DW79_C2 action=mark-routing new-routing-mark=DW79_to2 passthrough=no comment="DW79-PCC-R2"
/ip firewall mangle add chain=prerouting in-interface=bridge-lan src-address=192.168.50.0/24 dst-address-type=!local action=jump jump-target=DW79_LAN disabled=yes comment="DW79-PCC-ENTRY"
/ip firewall mangle print detail where comment~"^DW79-PCC-"

Ожидаемый результат: Оба непересекающихся остатка 2/0 и 2/1 покрывают новые соединения. При последующих пакетах connection mark восстанавливает выбор таблицы. Пока ENTRY отключён, эта цепочка не меняет LAN-трафик.

both-addresses-and-ports даёт хорошее распределение, но один клиент может открывать разные соединения через разные внешние IP. Для банков и сервисов с привязкой к IP используйте исключение. both-addresses закрепляет пару клиент–сервер; src-address закрепляет клиента, но при малом числе клиентов распределение может быть неравномерным. Описание алгоритма — PCC MikroTik.

Где: RouterOS после проверки таблиц, NAT, исключений и запаса производительности. Зачем: Включить только вход в подготовленную PCC-цепочку.

/ip firewall mangle enable [find where comment="DW79-PCC-ENTRY"]
/ip firewall mangle print stats where comment~"^DW79-PCC-"
/ip firewall connection print count-only where connection-mark=DW79_C1
/ip firewall connection print count-only where connection-mark=DW79_C2
/ip route print detail where routing-table=DW79_to1
/ip route print detail where routing-table=DW79_to2

Ожидаемый результат: Новые соединения из LAN попадают в разные группы, растут счётчики. Один speedtest или одна загрузка не подтверждают равенство распределения; проверьте несколько клиентов и направлений, затем отказ каждого WAN.

Для остановки новых назначений отключите DW79-PCC-ENTRY. Существующие connection mark сохранятся до завершения соединений; после изменения конфигурации тестируйте новые сеансы и не удаляйте весь conntrack без необходимости.

Вес 2:1, закрепление хоста и третий WAN в PCC

Где: Вариант с уже работающим PCC 1:1; это изменение, а не второй classifier поверх первого. Зачем: Выделить WAN1 две из трёх корзин, WAN2 — одну.

/ip firewall mangle disable [find where comment="DW79-PCC-ENTRY"]
/ip firewall mangle set [find where comment="DW79-PCC-B0"] per-connection-classifier=both-addresses-and-ports:3/0
/ip firewall mangle set [find where comment="DW79-PCC-B1"] per-connection-classifier=both-addresses-and-ports:3/2
/ip firewall mangle add chain=DW79_LAN connection-state=new connection-mark=no-mark per-connection-classifier=both-addresses-and-ports:3/1 action=mark-connection new-connection-mark=DW79_C1 passthrough=yes place-before=[find where comment="DW79-PCC-B1"] comment="DW79-PCC-WEIGHT1"
/ip firewall mangle enable [find where comment="DW79-PCC-ENTRY"]

Ожидаемый результат: Остатки 0 и 1 направлены к WAN1, остаток 2 — к WAN2. Пропорция относится к новым хеш-корзинам; не обещает точного отношения Мбит/с. Для возврата к 1:1 удалите только добавленный WEIGHT1 и верните B0/B1 к 2/0 и 2/1 при отключённом ENTRY.

Для закрепления устройства за WAN1 в PCC назначьте его connection mark раньше хеширования:

Где: PCC-цепочка с уже существующим B0. Зачем: Предпочитать WAN1 для новых внешних соединений хоста 192.168.50.20.

/ip firewall mangle add chain=DW79_LAN src-address=192.168.50.20 connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=DW79_C1 passthrough=yes place-before=[find where comment="DW79-PCC-B0"] comment="DW79-PCC-PIN20"

Ожидаемый результат: Хост получает C1 до classifier. Но DW79_to1 допускает резерв WAN2: для строгой привязки публичного IP нужна таблица без fallback и отдельная политика отказа.

Три WAN 1:1:1: начинайте с PCC 1:1, без WEIGHT1. Сначала настройте WAN3 из раздела выше; затем добавьте таблицу и резервы:

Где: Лабораторный PCC с тремя проверенными статическими WAN. Зачем: Подготовить третью таблицу и допустить WAN3 как последний резерв в первых двух.

/routing table add name=DW79_to3 fib
/ip route add dst-address=0.0.0.0/0 gateway=208.67.222.222@main routing-table=DW79_to3 distance=1 check-gateway=ping scope=30 target-scope=11 comment="DW79-T3-USE3"
/ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1@main routing-table=DW79_to3 distance=2 check-gateway=ping scope=30 target-scope=11 comment="DW79-T3-USE1"
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8@main routing-table=DW79_to3 distance=3 check-gateway=ping scope=30 target-scope=11 comment="DW79-T3-USE2"
/ip route add dst-address=0.0.0.0/0 gateway=208.67.222.222@main routing-table=DW79_to1 distance=3 check-gateway=ping scope=30 target-scope=11 comment="DW79-T1-USE3"
/ip route add dst-address=0.0.0.0/0 gateway=208.67.222.222@main routing-table=DW79_to2 distance=3 check-gateway=ping scope=30 target-scope=11 comment="DW79-T2-USE3"
/ip firewall address-list add list=DW79_LOCAL address=203.0.113.0/30 comment="DW79-LOCALWAN3"
/ip firewall address-list add list=DW79_LOCAL address=208.67.222.222 comment="DW79-LOCALPROBE3"

Ожидаемый результат: У третьей корзины есть предпочтительный WAN3 и два резерва; первые таблицы знают третий запасной путь. Адреса WAN3 и его probe исключены из PCC.

Где: После проверки всех трёх таблиц. Зачем: Заменить два остатка тремя и добавить восстановление routing mark третьей группы.

/ip firewall mangle disable [find where comment="DW79-PCC-ENTRY"]
/ip firewall mangle set [find where comment="DW79-PCC-B0"] per-connection-classifier=both-addresses-and-ports:3/0
/ip firewall mangle set [find where comment="DW79-PCC-B1"] per-connection-classifier=both-addresses-and-ports:3/1
/ip firewall mangle add chain=DW79_LAN connection-state=new connection-mark=no-mark per-connection-classifier=both-addresses-and-ports:3/2 action=mark-connection new-connection-mark=DW79_C3 passthrough=yes place-before=[find where comment="DW79-PCC-R1"] comment="DW79-PCC-B2"
/ip firewall mangle add chain=DW79_LAN connection-mark=DW79_C3 action=mark-routing new-routing-mark=DW79_to3 passthrough=no comment="DW79-PCC-R3"
/ip firewall mangle enable [find where comment="DW79-PCC-ENTRY"]

Ожидаемый результат: Новые соединения покрыты остатками 0/1/2 без дыр и пересечений. Проверьте выход каждой группы и отказ одного, затем двух каналов. Для входящих публикаций WAN3 нужны два дополнительных правила из раздела симметрии ниже.

Общее правило: знаменатель одинаковый, каждый остаток от 0 до N−1 назначен ровно один раз. Вес 3:2:1 — шесть корзин, три первой группе, две второй, одна третьей. Переоценивать веса по одному тесту скорости нельзя: учитывайте upload, RTT, стоимость и ограничение трафика.

Ответы через тот же WAN: публикации и сам роутер

Исходящая PCC-схема выше не является полной схемой входящих публикаций. Если запрос пришёл на WAN2, а ответ уйдёт по main через WAN1, удалённая сторона может его не принять. Для двух WAN в описанной лаборатории маркируют входящее соединение и отдельно направляют ответ:

Где: RouterOS, PCC-таблицы уже созданы; без других конкурирующих mangle-правил. Зачем: Запомнить входящий интерфейс нового соединения и выбрать соответствующую таблицу для ответа роутера.

/ip firewall mangle add chain=prerouting in-interface=ether1 connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=DW79_C1 passthrough=yes comment="DW79-PCC-IN1"
/ip firewall mangle add chain=prerouting in-interface=ether2 connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=DW79_C2 passthrough=yes comment="DW79-PCC-IN2"
/ip firewall mangle add chain=output dst-address-type=!local dst-address-list=!DW79_LOCAL connection-mark=DW79_C1 action=mark-routing new-routing-mark=DW79_to1 passthrough=no comment="DW79-PCC-OUT1"
/ip firewall mangle add chain=output dst-address-type=!local dst-address-list=!DW79_LOCAL connection-mark=DW79_C2 action=mark-routing new-routing-mark=DW79_to2 passthrough=no comment="DW79-PCC-OUT2"

Ожидаемый результат: Ответы самого роутера используют метку входящего соединения. Ответ сервера за dstnat, возвращающийся через bridge-lan, проходит существующую DW79_LAN и получает routing mark из той же connection mark.

Где: Только для уже подготовленного третьего WAN и DW79_to3. Зачем: Расширить запоминание входящего канала и ответы роутера на WAN3.

/ip firewall mangle add chain=prerouting in-interface=ether3 connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=DW79_C3 passthrough=yes comment="DW79-PCC-IN3"
/ip firewall mangle add chain=output dst-address-type=!local dst-address-list=!DW79_LOCAL connection-mark=DW79_C3 action=mark-routing new-routing-mark=DW79_to3 passthrough=no comment="DW79-PCC-OUT3"

Ожидаемый результат: Входящие соединения WAN3 получают C3; ответы самого роутера используют DW79_to3. Для сервера за dstnat работает ранее добавленное правило R3 в LAN-цепочке.

Это не создаёт dstnat и не открывает сервисы: публикацию, firewall, NAT и исключения проверяют отдельно. В исходной LAN только bridge-lan; при нескольких VLAN нужно расширить охват ответного трафика по фактическим интерфейсам и подсетям. Если удалённый peer имеет частный адрес из списка обхода, общая логика исключений требует изменения.

VPN, завершающийся на самом роутере, проверяют по способу установления и внутренним обменам, а не только ping. Strict rp-filter может мешать асимметричным и policy-routing-схемам; текущий режим читают в /ip settings print и меняют только после оценки защиты от spoofing. Не используйте fallback другой таблицы как обещание сохранить соединение, пришедшее на уже недоступный IP.

Маркировка пакетов для очередей и расширенная диагностика

Где: Необязательный учебный пример для известного IP АТС 192.168.50.10. Зачем: Отдельно пометить UDP-пакеты АТС для последующей работы очередей.

/ip firewall mangle add chain=forward src-address=192.168.50.10 protocol=udp action=mark-packet new-packet-mark=DW79_PBX_OUT passthrough=yes comment="DW79-QOS-PBX-OUT"
/ip firewall mangle add chain=forward dst-address=192.168.50.10 protocol=udp action=mark-packet new-packet-mark=DW79_PBX_IN passthrough=yes comment="DW79-QOS-PBX-IN"
/ip firewall mangle print stats where comment~"^DW79-QOS-"

Ожидаемый результат: Счётчики показывают UDP-трафик АТС в обоих направлениях. Это не распознавание RTP и не готовый QoS: здесь отмечен весь UDP данного хоста; очереди, полосы и приоритеты пока не созданы.

Для реального QoS уточните адреса медиашлюзов, диапазоны RTP, DSCP и точки ограничения upload/download. Подмена задачи QoS выбором WAN не устраняет переполнение очереди. FastTrack может обходить нужную обработку; одновременно проверяют ускорение, packet mark и место установки queue.

Где: RouterOS, во время новых тестовых подключений. Зачем: Проверить, совпадают ли connection mark, таблица и реальный выход.

/ip firewall mangle print stats where comment~"^DW79-PCC-"
/ip firewall connection print detail where connection-mark=DW79_C1
/ip firewall connection print detail where connection-mark=DW79_C2
/ip route print detail where routing-table=DW79_to1
/ip route print detail where routing-table=DW79_to2
/interface monitor-traffic ether1 once
/interface monitor-traffic ether2 once
/tool netwatch print stats

Ожидаемый результат: Метки видны в conntrack, выбранные маршруты — в своих таблицах, трафик — на WAN. Вывод conntrack содержит адреса и перед публикацией требует очистки.

При необходимости используйте Torch/Packet Sniffer в короткое согласованное окно: инструменты могут влиять на производительность и содержать сведения о трафике. После изменения веса создавайте новые соединения; прежние connection mark сохраняются. Для полного возврата сначала остановите контроллер, отключите PCC ENTRY и правила output, верните сохранённые routing rules/FastTrack и только потом убирайте неиспользуемые таблицы. Не выключайте все объекты по общему префиксу, если это также удалит рабочий базовый выход.

Диагностика: где искать причину

Где: RouterOS, во время воспроизводимого сбоя. Зачем: Сопоставить маршрут, трафик и попадание под правила.

/ip route print detail where comment~"^DW79-"
/routing route print detail where dst-address=0.0.0.0/0
/ip firewall nat print stats
/ip firewall filter print stats
/ip firewall connection print count-only
/interface print stats
/log print where topics~"interface|route|ppp|dhcp"

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

1. Нет обоих шлюзов: проверьте питание, линк, VLAN и адреса WAN.
2. Шлюз есть, probe нет: проверяйте путь оператора и фильтрацию ICMP.
3. Маршрут не переключился: ищите конкурирующий default route, policy routing, неверные scope/target-scope.
4. Роутер выходит, LAN нет: смотрите NAT, forward, адрес клиента и DNS.
5. Новые сайты открываются, VPN нет: проверяйте переподключение, peer, allowlist и исходящий IP.
6. Одна часть трафика идёт иначе: проверьте mangle, таблицы и FastTrack.

FastTrack связан с обработкой через main; для policy routing нужны исключения и проверка совместимости. Не переносите базовую схему в PCC-балансировку без пересмотра симметрии маршрутов. Отличия видов балансировки описаны в Load Balancing, прохождение FastTrack — в Packet Flow.

Приёмка и мониторинг после запуска

1. Оба канала исправныОсновной выбран, резерв доступен
2. Отказ за шлюзомПроверка действительно видит аварию
3. Резерв работаетНовое соединение из LAN
4. Возврат основногоПовторный тест приложений
5. Протокол приёмкиВремя и фактические результаты

• Собирать состояние обоих WAN, потери и задержку по каждому отдельно.
• Следить за загрузкой резервного канала и лимитом мобильного трафика.
• Записывать переключения и периоды восстановления.
• Контролировать маршруты до DNS, мониторинга и удалённого управления.
• Сопоставлять инциденты с логами VPN, АТС и приложений.
• Периодически повторять испытания, особенно после смены провайдера и обновления RouterOS.

История мониторинга нужна и для расследования: что случилось раньше, потерялась ли связь с WAN, менялся ли маршрут, какие приложения перестали работать и кто подтвердил восстановление. Уведомление «порт поднялся» не заменяет проверку рабочего сервиса.

Как вернуть изменения без сброса всего роутера

Если включали расширенные варианты, сначала остановите scheduler DW79-QCTRL, отключите mangle ENTRY и output-правила, верните сохранённые routing rules. Убедитесь, что управление и старый рабочий выход доступны. Ниже отключаются все маршруты и NAT с общим префиксом DW79, включая третий WAN и PCC-таблицы: это полный возврат примера, а не ручной выбор одного провайдера.

Где: RouterOS, согласованный возврат учебной схемы. Зачем: Сначала показать объекты, созданные только этой инструкцией.

/ip route print detail where comment~"^DW79-"
/ip firewall nat print detail where comment~"^DW79-"
/ip address print detail where comment~"^DW79-"
/interface list member print detail where comment~"^DW79-"

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

После сверки по уникальным комментариям можно отключить маршруты и NAT примера. Это не удаляет старую конфигурацию:

Где: Тот же роутер после подтверждения альтернативного маршрута и локального доступа. Зачем: Выключить только добавленные данным примером пути и NAT.

/ip route disable [find where comment~"^DW79-"]
/ip firewall nat disable [find where comment~"^DW79-"]

Ожидаемый результат: Объекты DW79 отключены. WAN-адреса и членство списка остаются: их удаляют отдельно после сверки, чтобы не открыть управление снаружи. Старые изменённые параметры возвращают по протоколу.

Не импортируйте весь экспорт поверх текущей конфигурации без плана: можно получить дубликаты и конфликтующий firewall. Если тест прервался после disable ether1, сначала включите его обратно из локальной сессии.

Скачайте IP-план и протокол испытаний

Настроим резервирование под ваши рабочие сервисы

Частые вопросы