Как работает автоматическое переключение на резервный канал?

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

У этой схемы есть неприятное свойство: зеленый индикатор интерфейса часто переживает аварию провайдера, а действующая TCP-сессия обычно не переживает смену публичного адреса. Поэтому проектировать надо не абстрактный «резерв», а четыре разных процесса: обнаружение отказа, смену маршрута, смену трансляции адресов и восстановление приложений. Я настраивал такие пары каналов много раз и чаще всего находил ошибку не в синтаксисе маршрута, а в неверном ответе на вопрос «что именно считаем отказом».

Резерв начинается с модели отказа

Сначала перечислите отказы, от которых должна защищать схема, потому что каждый из них виден маршрутизатору по-разному. Обрыв Ethernet или потеря оптики переводит интерфейс в down, но зависший CPE, повреждение маршрута внутри сети оператора, отказ DNS и сильная потеря пакетов могут оставить линк поднятым.

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

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

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

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

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

Один ping проверяет не тот канал, который нужен бизнесу

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

Выберите для каждого провайдера минимум две цели за пределами его сети доступа. Цели должны отвечать предсказуемо, идти через строго заданный WAN и не зависеть от одного оператора или одной автономной системы. Если маршрутизатор позволяет, объединяйте результаты так, чтобы потеря одной цели давала предупреждение, а потеря всех целей выводила канал из работы. Слишком жесткое правило «любой probe упал, значит WAN мертв» превращает краткий сбой одного адресата в переключение всей организации.

Маршрут до каждой контрольной цели надо закрепить за проверяемым провайдером. Иначе после отказа основного WAN probe уйдет через резерв, снова получит ответ и ошибочно объявит основной путь рабочим. Эта петля выглядит в журнале как постоянное переключение туда и обратно. В рекурсивной статической маршрутизации привязку создают отдельные host route через шлюз каждого оператора; в системах с policy routing ту же задачу решает правило для источника или процесса мониторинга.

ICMP показывает базовую IP-доступность, но не качество приложения. Для телефонии или терминального доступа добавьте пороги потерь и задержки, если платформа умеет считать их на окне наблюдения. Документация Netgate по Multi-WAN прямо различает события полного отказа, высокой задержки и потери пакетов. Это полезное различие: канал с 20-процентной потерей формально жив, но пользователь уже не может нормально работать. Порог берут из измерений исправного канала и требований приложения, а не из чужой конфигурации.

Таймеры должны отсеивать дребезг, а не скрывать аварию

Время переключения равно сумме интервала проб, числа или окна неудач, задержки изменения состояния, времени пересчета маршрута и времени повторного подключения приложения. Обещание «переключение за секунду» ничего не значит, если его проверяли только по появлению резервного default route, а браузер еще минуту держит старую TCP-сессию.

Настройте разные условия ухода и возврата. На уход обычно достаточно нескольких последовательных ошибок или превышения порога в коротком окне. Возврат должен быть медленнее: основной канал обязан показать устойчивую работу, прежде чем вы снова направите на него пользователей. В Cisco object tracking для этого есть отдельные задержки delay down и delay up; похожие параметры или сценарии есть у большинства межсетевых экранов и SD-WAN устройств.

Например, probe раз в 3 секунды, признание отказа после 3 неудач и задержка down в 5 секунд дают теоретическое обнаружение примерно за 11-14 секунд в зависимости от момента обрыва. Затем прибавляются установка маршрута, очистка состояний и повтор приложения. Это расчетная оценка, а не гарантированное число. Измеряйте ее на своем устройстве под реальной нагрузкой.

Не уменьшайте интервалы до предела ради красивой метрики. Короткий timeout на мобильном, радиорелейном или перегруженном канале создаст ложные аварии. Слишком длинное окно тоже вредно: пользователи сообщат о проблеме раньше мониторинга. Хорошая настройка показывает единичные потери в телеметрии, но меняет маршрут только при устойчивом ухудшении.

Маршрут, NAT и правила должны переключаться вместе

После признания отказа резервный default route должен стать активным, а исходящий NAT и правила межсетевого экрана должны разрешить тот же трафик через второй WAN. Частая поломка выглядит так: таблица маршрутизации верна, пакет уходит на резервный интерфейс с частным адресом источника, а провайдер его отбрасывает, потому что правило masquerade или source NAT существует только для первого интерфейса.

Проверьте не одну основную таблицу. Policy routing для гостевой сети, телефонии, VPN, серверного сегмента и трафика самого маршрутизатора может ссылаться на конкретный шлюз. Статический маршрут до корпоративного DNS или головного офиса тоже способен обойти новую default route. Если резерв предназначен не для всех систем, явно завершите исключенные политики правилом reject, чтобы они не вытекали через случайный маршрут.

На резервном канале нужны свои исходящие трансляции, разрешающие правила и, при необходимости, меньший MSS для туннелей. DNS-клиенты должны иметь доступный резолвер через оба пути. Службы самого межсетевого экрана, включая NTP, обновления, VPN-клиент и отправку журналов, иногда используют отдельную таблицу или привязку к интерфейсу, поэтому тест с пользовательского ноутбука не подтверждает их работу.

Не путайте failover с балансировкой. При резервировании все новые соединения идут через канал первого приоритета, пока тот пригоден. При балансировке система распределяет соединения между двумя рабочими WAN. Распределять отдельные пакеты одной сессии по разным провайдерам почти всегда ошибочно: разные задержки и публичные адреса нарушают порядок пакетов и проверки удаленной стороны. Если нужна утилизация обоих каналов, распределяйте целые соединения и закрепляйте чувствительные назначения за одним выходом.

Старые соединения не обязаны пережить смену провайдера

При обычном IPv4 NAT действующие соединения чаще всего оборвутся, потому что резервный провайдер подставит другой публичный адрес. Удаленный сервер видит новый четырехэлементный набор адресов и портов как другое соединение, а пакеты старой сессии либо не доходят, либо не совпадают с состоянием NAT и межсетевого экрана.

RFC 4116 формулирует это без рекламных оговорок: транспортные сессии в общем случае не сохраняются при переключении в схеме multihoming с NAT, зато после смены пути можно создавать новые. Это и есть честное ожидание для двух бытовых или корпоративных доступов с адресами провайдеров. Браузер обычно повторит запрос, мессенджер переподключится, а SSH, RDP, SIP-звонок, длительная выгрузка и часть VPN-туннелей заметят разрыв.

Таблица состояний определяет, как долго клиент будет цепляться за мертвый путь. Если оставить старые state entries, приложение может ждать TCP timeout, хотя резервный маршрут уже активен. Если очистить состояния, клиент быстрее создаст соединение через второй WAN, но вы сознательно оборвете все подходящие сессии. Документация pfSense поэтому предлагает выбор между сохранением состояний, выборочной очисткой состояний отказавшего шлюза и очисткой всей таблицы; последний вариант может задеть несвязанный трафик.

Я предпочитаю выборочную очистку состояний отказавшего WAN после подтвержденного отказа. Для голосового шлюза или постоянного туннеля полезен отдельный watchdog, который перезапускает регистрацию или туннель, если приложение само восстанавливается слишком долго. Сохранить сеанс можно лишь тогда, когда оба пути используют один достижимый публичный префикс и маршрутизация в Интернете переводит его между операторами, либо когда поверх обоих доступов работает туннель к общей точке выхода. Это уже другая архитектура с BGP, PI-адресами, операторской услугой или внешним концентратором.

Входящий трафик переключается по отдельным правилам

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

Для некритичной публикации можно завести второй адрес и изменить DNS при аварии, но задержка определяется кэшем резолверов, TTL, скоростью обновления записи и поведением приложения. Уже открытые соединения все равно используют старый адрес. Для IPsec с адресом узла в DNS восстановление также может занять заметное время, пока стороны обновят имя и пересоберут туннель.

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

Обратный путь тоже должен быть симметричным. Пакет, пришедший на WAN2, должен получить ответ через WAN2, иначе фильтрация источника у провайдера или stateful firewall отбросит его. Policy routing по входному интерфейсу, отдельные таблицы и корректный source NAT решают эту задачу. Проверяйте публикации из настоящей внешней сети, а не из LAN через hairpin NAT.

Рабочая конфигурация видна в таблице маршрутов

Пример для RouterOS 7 показывает принцип рекурсивной проверки, а не готовый шаблон для вставки. Замените шлюзы и контрольные адреса, проверьте имена таблиц и сначала выполните команды на стенде. Документация MikroTik по WAN Backup использует тот же прием: host route закрепляет внешний probe за провайдером, а default route рекурсивно зависит от доступности probe.

/ip route
add dst-address=1.1.1.1/32 gateway=192.0.2.1 scope=10 comment=probe-isp1-a
add dst-address=9.9.9.9/32 gateway=192.0.2.1 scope=10 comment=probe-isp1-b
add dst-address=8.8.8.8/32 gateway=198.51.100.1 scope=10 comment=probe-isp2-a
add dst-address=208.67.222.222/32 gateway=198.51.100.1 scope=10 comment=probe-isp2-b
add dst-address=0.0.0.0/0 gateway=1.1.1.1,9.9.9.9 distance=1 target-scope=11 check-gateway=ping comment=default-isp1
add dst-address=0.0.0.0/0 gateway=8.8.8.8,208.67.222.222 distance=2 target-scope=11 check-gateway=ping comment=default-isp2

Адреса 192.0.2.1 и 198.51.100.1 взяты из документационных диапазонов и в рабочей сети должны быть заменены реальными next hop. Два gateway в каждой default route образуют несколько рекурсивных next hop. Перед применением уточните поведение вашей версии RouterOS: нужная логика состоит в том, чтобы основной маршрут оставался доступен при ответе хотя бы одной цели и исчезал только при потере обеих.

После настройки команда /routing/route/print detail where dst-address=0.0.0.0/0 должна показывать основной маршрут активным и резервный кандидатом с большей distance. При отказе рекурсивные next hop основного маршрута становятся недоступными, основной default route получает неактивное состояние, а маршрут с distance=2 становится активным. Одновременно проверьте счетчики NAT, выбранный исходящий интерфейс и внешний адрес тестового клиента. Флаг маршрута без проходящего трафика доказывает только половину работы.

Для оборудования другого производителя сохраняется тот же граф зависимостей: probe привязан к WAN, track object получает результат, основной default route зависит от track, резервный имеет худшую метрику, а NAT и политики существуют для обоих выходов. Не копируйте синтаксис между платформами. Копируйте проверяемую причинную связь.

Испытание должно ломать сеть выше физического порта

Приемочное испытание обязано воспроизводить каждую заявленную аварию и измерять результат с точки зрения приложения. Выдернуть кабель полезно, но это самый простой случай: интерфейс сразу падает, и сложная проверка доступности вообще не участвует.

1. Запустите непрерывный ping, короткие HTTPS-запросы, длительную загрузку, сеанс SSH или RDP и тестовый звонок. Одновременно сохраните время событий маршрутизации, NAT и мониторинга.
2. Заблокируйте контрольные цели через основной WAN выше локального шлюза или временно создайте blackhole у провайдера на стенде. Убедитесь, что одна потерянная цель не выводит канал, а потеря всех переводит трафик.
3. Оставьте линк поднятым, но запретите обычный Интернет-трафик. Так вы обнаружите проверку, которая случайно ходит через резерв или измеряет только шлюз.
4. Верните основной путь на короткое время и снова нарушьте его. Маршрут не должен дребезжать, а delay up должен удержать пользователей на резерве до устойчивого восстановления.
5. Повторите тест для входящих публикаций, VPN, DNS, телефонии и служб самого маршрутизатора. Запишите разрыв старых сессий отдельно от времени успешного нового соединения.

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

Не проводите первый полный тест в рабочее время без окна и пути отката. Сначала отключите автоматический возврат, проверьте ручной переход, затем включите детектирование и только после этого failback. Для инфраструктурного проекта GSE может связать серверную и сетевую часть, независимость каналов и круглосуточную поддержку в одной схеме, но критерии приемки все равно должны принадлежать заказчику и отражать его приложения.

Возврат на основной канал опаснее самого перехода

Автоматический failback часто создает второй незапланированный перерыв: пользователи уже работают через WAN2, затем восстановившийся WAN1 отбирает маршрут и меняет публичный адрес снова. Если основной оператор несколько раз поднимается и падает, без гистерезиса сеть будет рвать сессии при каждом событии.

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

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

После каждой аварии сравнивайте фактическое время с целевым и смотрите, какой этап задержал восстановление. Если маршрут сменился за 12 секунд, а VPN поднялся через 90, тюнинг probe ничего не исправит. Нужен разбор таймеров IKE, DNS, регистрации или логики конкретного клиента.

Пропускную способность резерва надо защищать политикой

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

Составьте бюджет полосы для голоса, терминального доступа, платежных операций, корпоративного VPN и служебных DNS и NTP. Добавьте запас на служебные накладные расходы и короткие всплески. Затем ограничьте или запретите через WAN2 обновления операционных систем, облачную синхронизацию больших каталогов, гостевой Wi-Fi и внешнее резервное копирование, если они способны вытеснить рабочие приложения. Приоритет без ограничения агрессивного класса часто не помогает: очередь уже заполнена большими потоками, а узкое место находится на стороне оператора, где ваш маршрутизатор не управляет отправкой.

Исходящую скорость формируйте чуть ниже реально измеренной емкости резервного доступа. Тогда очередь остается на вашем устройстве, и вы можете дать голосу или интерактивному трафику предсказуемое обслуживание. Для входящего направления контроль слабее, поэтому ограничивайте получателей у себя, договаривайтесь с оператором о профиле или снижайте интенсивность приложений. Проверяйте качество при полной нагрузке: пустой канал почти всегда показывает красивую задержку, которая исчезает после одного большого upload.

Резерв через LTE или другой тарифицируемый доступ требует отдельной защиты от неожиданного счета. Установите предупреждения по объему, запретите тяжелые категории и убедитесь, что канал не стал основным из-за забытого отказа. Если оператор использует CGNAT, обычные исходящие соединения могут работать, а входящие публикации и некоторые туннели не поднимутся. Это свойство услуги надо выяснить до аварии, а не во время нее.

Производительность пограничного устройства тоже меняется при включении второго WAN. NAT, шифрование туннелей, учет состояний, формирование очередей и подробное журналирование используют процессор и память. Испытайте маршрутизатор на требуемой скорости с включенными правилами безопасности, а не ориентируйтесь на скорость портов в спецификации. Если резерв медленнее ожидаемого, сначала найдите ограничение: тариф, радиосигнал, дуплекс, MTU, CPU, очередь или удаленный VPN-шлюз требуют разных исправлений.

Наконец, политика должна сохранять управляемость самой сети. Доступ администраторов, мониторинг, журналы и DNS нельзя случайно отнести к «неважному» трафику и отрезать при перегрузке. Оставьте для них небольшую гарантированную полосу и проверьте, что инженер может войти на оборудование через независимый путь. Резерв, который работает только пока его не надо диагностировать, не прошел приемку.

Резерв надо обслуживать как рабочий канал

Неиспользуемый месяцами WAN незаметно перестает быть резервом: меняется адрес шлюза, истекает оплата, оператор заменяет CPE, правило NAT остается от старой схемы, а пропускной способности уже не хватает новым приложениям. Автоматическая проверка внешнего адреса ловит часть этих отказов, но не подтверждает реальную производительность и доступность всех сервисов.

Проводите управляемое переключение по расписанию и оставляйте пользователей на втором канале достаточно долго, чтобы проявились DNS, VPN, публикации, ограничения тарифа и асимметрия маршрутов. Мониторинг должен отдельно показывать состояние обоих WAN, активный default route, задержку, потери, число переключений и причину каждого события. Алерт «мы на резерве» нужен сразу, даже если пользователи ничего не заметили: теперь следующая авария оставит площадку без выхода.

Храните схему с физическими трассами. Два договора не дают независимости, если оба ввода идут в одной муфте, используют одну городскую магистраль, один CPE, одну стойку или один источник питания. Спросите операторов о последней миле и точках ввода, затем подтвердите ответ осмотром и испытанием. Технологическая независимость проверяется отказом, а не логотипами в договоре.

Готовой считается схема, в которой команда может объяснить каждое состояние и повторить его: почему WAN признан неисправным, какой маршрут победил, какой NAT применился, какие сессии оборвались, как восстановились приложения и когда разрешен возврат. Если на эти вопросы отвечает только человек, который однажды настроил маршрутизатор, резервирование уже имеет единую точку отказа.