В теории отказоустойчивость на уровне подключения к интернету выглядит просто. Есть два провайдера. Один — основной, второй — резервный. Если первый перестаёт работать, трафик должен автоматически перейти ко второму. Такая схема — основа сетевой надёжности для тысяч офисов, филиалов, дата-центров, учебных заведений и даже домашних маршрутизаторов. Многие производители сетевого оборудования рекламируют “Dual WAN failover” или “auto link backup” как решение “в один клик”. Но на практике это “один клик” при отсутствии глубокой настройки и понимания принципов работы маршрутизации, сессий, NAT и протокольных ограничений способен в один момент вывести из строя всю сеть. Причём не в момент аварии, а именно в момент, когда включается “резерв”.

Неправильно реализованный failover между двумя провайдерами не делает сеть устойчивой. Он превращает её в сложный набор противоречивых состояний, в которых часть приложений перестаёт работать, туннели разрываются, DNS-запросы зависают, маршруты становятся некорректными, политики безопасности нарушаются, а пользователи получают “интернет вроде есть, но ничего не открывается”. И что ещё хуже — в отличие от полной потери связи, такая деградация не выглядит аварией. В логах — линк поднят. Пинг идёт. А фактически — бизнес-приложения не работают, почта не уходит, туннели не поднимаются. Виноват, на первый взгляд, никто. Но на деле — это инженерная ошибка, которая закладывается в момент проектирования маршрутов.

Failover — это не просто «второй интернет»

Главная ошибка в понимании резервирования провайдеров — это представление, что “второй канал” должен просто “включиться” после падения первого. Однако вся модель L3-маршрутизации построена на принципе таблицы маршрутов, в которой приоритет определяет интерфейс, маршрут, метрика, доступность next-hop и ряд других параметров. И если переключение между двумя провайдерами не сопровождается корректной переоценкой всей таблицы маршрутизации, NAT-сессий, DNS-резолвинга, политики Firewall, состояния туннелей, правил маршрутизации трафика по приложениям, то сам факт “переключения” создаёт состояние, хуже полного обрыва. Потому что сеть продолжает существовать, но перестаёт работать корректно.

Пользователи получают частичную доступность: часть сайтов открывается, другая — нет. VPN не устанавливается. Роуминговые сессии рвутся. Подключение к серверам работает нестабильно. Интерфейсы видят линк, но доступность сервисов отсутствует. И администратор оказывается в ситуации, когда он не может объяснить, что происходит, потому что “всё вроде на месте”.

Где скрываются технические ловушки

В простых конфигурациях Failover между двумя провайдерами реализуется с помощью двух WAN-интерфейсов и маршрута с разной административной дистанцией (AD). При падении линка основной маршрут исчезает, активируется резервный. Но падение линка — это далеко не единственный сценарий отказа. Чаще всего канал остаётся физически активен, но у оператора или в транспортной сети происходит частичный сбой: теряется маршрутизация, недоступен DNS, отваливаются ASN. При этом интерфейс “живой”, маршрутизатор его считает доступным. И резерв не активируется.

Или, напротив, резерв активируется — но не обновляются политики NAT. В этом случае внутренние хосты начинают выходить в интернет через второго провайдера, но их IP-пакеты по-прежнему маскируются внешним IP основного провайдера. На границе сети — рассинхронизация. Ответные пакеты идут “в никуда”. Сессии рвутся. Приложения недоступны. Или же активируется маршрут, но на серверах внешней стороны включена проверка IP, и сессия из “неожиданного адреса” блокируется.

Другой частый сценарий — существующие туннели IPsec или SSL VPN были настроены под IP-адрес основного провайдера. После переключения на резерв туннель не поднимается. Клиенты не могут подключиться. Сторона филиала считает, что “всё работает”. Но головной офис “не видит” удалённую площадку. Причина — конфигурации туннеля не адаптированы под плавающий WAN-адрес.

Ещё одна проблема — отсутствие механизмов возврата. После восстановления основного канала сеть продолжает использовать резервный. Но тот медленнее, с ограничениями, с тарифом “на случай аварии”. Это может привести к перегрузке, ухудшению качества и дополнительным расходам. А всё потому, что не реализован механизм failback, либо сделан вручную, что вносит элемент человеческой ошибки и задержек.

Когда “умные” механизмы только усугубляют

Многие современные маршрутизаторы и NGFW имеют встроенные механизмы автоопределения доступности провайдера. Используются проверки по ICMP, HTTP, DNS. Но если эти проверки сделаны по одному хосту (например, 8.8.8.8) — то отказ его доступности воспринимается как обрыв интернета. Хотя на деле это может быть частичный сбой одного из upstream-провайдеров. В результате резерв активируется без необходимости. А обратный переход — не происходит. Получается “флаппинг”, постоянная перетасовка маршрутов, разрыв сессий, нарушение стабильности.

В случаях, когда используется BGP — ошибок ещё больше. Без точной настройки weight, local preference, as-path prepending и route-map даже малейшее изменение в upstream может привести к перехвату всего трафика резервом, несмотря на то, что основной канал работает. А если два провайдера имеют пересекающиеся маршруты и один из них не фильтрует анонсы — Вы получите route leakage, где “резерв” уходит в “основной” путь, и наоборот.

Failover без архитектуры — это ловушка

Резервирование — это не просто наличие второго канала. Это встроенная в архитектуру логика реакции на сбой, с полной проработкой: как переключается маршрут, как восстанавливается NAT, как реагируют политики Firewall, как отрабатывают DNS-запросы, какие туннели требуют пересоздания, какова скорость convergence, и что будет в случае обратного перехода. Без этого Вы проектируете не устойчивость, а точку повторного риска.

Даже если всё работает при тестировании — это не значит, что Failover корректно отработает при реальном сбое. Потому что в тестах — идеальные условия. В жизни — частичная деградация, неявные сбои, неожиданные разрывы. Только при наличии полной схемы взаимодействия маршрутов, политик, проверок и fallback-механизма Failover становится действительно устойчивым. Иначе — это мина замедленного действия.

Устойчивость — это способность к восстановлению, а не к “переключению”

На курсе «Передача и коммутация данных в компьютерных сетях» Вы научитесь проектировать отказоустойчивые схемы подключения к интернету с двумя и более провайдерами: определять метрики, выстраивать приоритеты, настраивать маршруты с учётом SLA, отслеживать доступность через IP SLA, реализовывать корректную смену NAT-объектов, защищать туннели от флаппинга, обеспечивать постоянную видимость всех внешних сервисов, и — главное — выстраивать архитектуру, в которой резерв не ломает, а поддерживает. Потому что настоящая отказоустойчивость — это не кабель, а модель реакции системы на сбой.

Не каждый “резерв” делает сеть надёжной. Но каждый неверно реализованный резерв делает её ломкой. Постройте настоящую архитектуру устойчивости!