Надёжная маршрутизация для multi-homed сайтов через VPN: Active-Active и Active-Passive схемы 2026

Инфраструктура с несколькими интернет-каналами (Dual-homed или Multi-homed) перестала быть прерогативой крупных дата-центров. В 2026 году это стандарт для любого бизнеса, где простой критичных сервисов измеряется прямыми финансовыми потерями. Однако подключение второго канала - это только половина решения. Без интеллектуальной маршрутизации вы рискуете получить ложное чувство безопасности: VPN-туннели в филиалы будут обрываться, удалённые сотрудники потеряют доступ к CRM, а звонки по VoIP станут нестабильными. Простое резервирование не работает автоматически.

Эта статья - практическое руководство для системных администраторов и DevOps-инженеров. Вы получите готовые, проверенные конфигурации для популярных платформ (PfSense, OPNsense, MikroTik, Linux), которые реализуют отказоустойчивые схемы Active-Active и Active-Passive. Мы разберём, как настроить мониторинг линков, обеспечить непрерывность VPN-соединений и распределить трафик для эффективного использования всех каналов. Все инструкции актуальны для 2026 года и основаны на реальных сценариях внедрения.

Зачем вам отказоустойчивая маршрутизация при нескольких интернет-каналах

Основная цель подключения второго интернет-канала - исключение единой точки отказа. Но базовая настройка Dual-WAN, которую предлагают многие маршрутизаторы «из коробки», часто создаёт больше проблем, чем решает. Она не учитывает специфику stateful-сервисов, таких как VPN, VoIP или защищённые веб-сессии.

Риски простого Dual-WAN без интеллектуальной маршрутизации

При использовании простой балансировки или приоритизации маршрутов возникают три ключевые проблемы:

Асимметричная маршрутизация: Исходящий пакет уходит через один шлюз (например, WAN1), а ответный приходит через другой (WAN2). Stateful firewall (состоятельный межсетевой экран) на основном шлюзе не видит established-сессии для входящего пакета и блокирует его. Это ломает работу многих протоколов и веб-приложений.
Обрыв VPN-туннелей: Туннель IPsec или OpenVPN привязан к конкретному внешнему IP-адресу. При сбое основного канала и переключении на резервный, исходный IP для туннеля меняется. Удалённая сторона продолжает ожидать соединения со старым IP, что приводит к полному обрыву связи до ручного вмешательства или долгого таймаута Dead Peer Detection (DPD).
Неэффективное использование ресурсов: В схеме Active-Passive без корректного мониторинга резервный канал простаивает, а при сбое основного переключение занимает минуты. В схемах с балансировкой трафик может распределяться случайно, без учёта загрузки каналов или типа сервиса, что приводит к лагам в VoIP при загрузке файлов.

Конкретные сценарии сбоев: сотрудник на удалёнке теряет RDP-сессию к рабочему серверу при обрыве «основного» провайдера; филиал отключается от головного офиса, потому что VPN-шлюз не переключился; облачная CRM-система становится недоступной для отдела продаж. Интеллектуальная маршрутизация решает эти проблемы, обеспечивая автоматический failover за секунды и контролируемое распределение нагрузки.

Выбор схемы: Active-Active или Active-Passive для ваших задач

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

Критерий	Active-Passive (Активный-Резервный)	Active-Active (Активный-Активный)
Основная цель	Максимальная стабильность и простота. Гарантированная работа критичных сервисов при сбое.	Балансировка нагрузки, эффективное использование полосы пропускания, увеличение общей доступной ширины канала.
Использование каналов	Один канал активен, второй простаивает до момента сбоя.	Оба канала используются одновременно для передачи трафика.
Поведение VPN	Проще обеспечить непрерывность. Туннель «привязан» к активному шлюзу.	Сложнее. Может потребоваться терминация VPN на виртуальном интерфейсе или использование DynDNS для плавающего IP.
Сложность настройки	Ниже. Требуется настройка мониторинга и правил failover.	Выше. Требуется настройка балансировки, политик и решение проблемы асимметричной маршрутизации.
Идеальные сценарии	IPsec Site-to-Site туннели, VoIP (SIP, RTP), терминальные службы (RDP, Citrix), доступ к критичным базам данных.	Веб-трафик, файловые хранилища (SMB, NFS), резервное копирование, видеонаблюдение, загрузка контента.

Active-Passive: максимальная стабильность для критичных соединений

Выбирайте эту схему, когда приоритетом является гарантированная доступность, а не 100% использование пропускной способности второго канала. Механизм работы основан на постоянном мониторинге состояния активного шлюза (Gateway Monitoring).

Система отправляет ICMP-запросы (ping) к надёжным внешним хостам, например, 8.8.8.8 и 1.1.1.1. При потере пакетов или увеличении задержки сверх порога, шлюз помечается как «отказавший». Маршрутизатор затем повышает приоритет (уменьшает метрику) маршрутов через резервный шлюз, делая его активным. Ключевой параметр - таймауты и пороги срабатывания. Слишком агрессивные настройки приведут к «дребезгу» (частым переключениям) при кратковременных всплесках нагрузки. Рекомендуемые значения для OPNsense/PfSense: интервал опроса 1 секунда, порог потери пакетов 20%, время до объявления шлюза недоступным - 10 секунд.

Active-Active: балансировка нагрузки и эффективное использование каналов

Эта схема задействует все каналы одновременно. Распределение трафика может происходить по разным алгоритмам:

Per-connection: Все пакеты в рамках одной сетевой сессии (определяемой 5-тью параметрами: src/dst IP, src/dst port, protocol) идут через один шлюз. Это решает проблему асимметричной маршрутизации для stateful-сервисов.
Per-source IP: Весь трафик с определённого IP-адреса в локальной сети направляется через один шлюз. Полезно для выделения стабильного канала под VoIP-аппарат или сервер.
Weighted Round Robin: Распределение в пропорции, соответствующей пропускной способности каналов (например, 70/30 для каналов 100 Мбит/с и 50 Мбит/с).

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

Ядро системы: настройка мониторинга линков и политик маршрутизации

Интеллектуальность системы обеспечивается двумя компонентами: механизмом мониторинга доступности внешних шлюзов и гибкими правилами (политиками) для выбора пути трафика на основе этого состояния.

Настройка Gateway Groups и мониторинга в OPNsense/PfSense

В OPNsense 24.x и PfSense CE 2.7.x настройка выполняется через веб-интерфейс. Вот пошаговая инструкция:

Создание шлюзов (Gateways): Перейдите в System > Gateways > Single. Для каждого WAN-интерфейса создайте шлюз. Укажите его IP-адрес, интерфейс и отключите опцию «Disable Host Monitoring». В поле «Monitor IP» укажите 2-3 надёжных внешних адреса (например, 8.8.8.8, 1.1.1.1).
Настройка мониторинга: Оставьте параметры по умолчанию: Probe Interval - 1s, Loss Interval - 10s, Time Period - 60s. Порог потерь (Loss threshold) установите на 20%.
Создание группы шлюзов (Gateway Group): Перейдите в System > Gateways > Groups. Добавьте новую группу.
- Для Active-Passive: Добавьте основной шлюз с Tier 1, резервный - с Tier 2. В Trigger Level выберите «Member down».
- Для Active-Active: Добавьте оба шлюза с одинаковым Tier 1. В поле «Weight» установите пропорции (например, 1 и 1 для равномерного распределения). Выберите Trigger Level «Packet Loss». В Policy Routing выберите «Round Robin» или «Sticky Connections».
Применение группы к правилам: В Firewall > Rules на вкладке LAN создайте или отредактируйте правило. В поле «Gateway» выберите созданную группу шлюзов. Весь трафик, попадающий под это правило, будет маршрутизироваться согласно логике группы.

Логи переключений можно наблюдать в System > Log Files > Gateway. Сообщения вида «WAN_DHCP is down, waiting 6 seconds» указывают на начало процесса failover.

Использование IP SLA и Tracked Objects в MikroTik

В MikroTik RouterOS 7.x логика строится на связке IP SLA, Tracked Objects и правил маршрутизации в таблице Mangle.

# 1. Создание SLA probe для мониторинга через WAN1
/ip sla
add comment="Monitor via WAN1" destination=8.8.8.8 interval=10s timeout=5s

# 2. Создание Tracked Object, который отслеживает состояние SLA
/tool romon
add disabled=no name="Track_WAN1" policy=ping,ping address=8.8.8.8 interface=ether1-WAN interval=10s timeout=5s

# 3. Создание маршрута по умолчанию через WAN1 с расстоянием 1
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.1.1 distance=1 check-gateway=ping comment="Primary WAN"

# 4. Создание маршрута через WAN2 с большим расстоянием (низким приоритетом) и привязкой к Tracked Object
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.2.1 distance=5 comment="Backup WAN" \
    routing-mark=backup-route disable-on-track=no track="Track_WAN1"
# Ключевой параметр: `disable-on-track=no` означает, что маршрут АКТИВЕН, когда Tracked Object В РАБОЧЕМ состоянии.
# Наша цель - отключить резервный маршрут, когда основной жив. Делаем наоборот:
# Создаём Tracked Object для мониторинга через WAN2.
/tool romon
add name="Track_WAN2" policy=ping,ping address=1.1.1.1 interface=ether2-WAN2

# Изменяем резервный маршрут: он должен быть ВКЛЮЧЕН (distance=5), когда Track_WAN1 НЕ активен.
# В RouterOS нет прямой опсии «включить если down». Используем скрипт.

/ip route
set [ find comment="Backup WAN" ] disabled=yes
# Резервный маршрут изначально выключен.

# Создаём скрипт для включения/выключения резервного маршрута
/system script
add name="failover_script" source=\n    \"if ([/tool romon get [find name=\\\"Track_WAN1\\\"] status] = \\\"down\\\") do={ \n        /ip route enable [find comment=\\\"Backup WAN\\\"] \n        :log info (\\\"Primary WAN down, enabling Backup route\\\") \n    } else={ \n        /ip route disable [find comment=\\\"Backup WAN\\\"] \n        :log info (\\\"Primary WAN up, disabling Backup route\\\") \n    }\"

# Настраиваем scheduler для запуска скрипта каждые 5 секунд
/system scheduler
add interval=5s name="failover_scheduler" on-event=failover_script start-time=startup

Этот подход обеспечивает чёткий Active-Passive режим. Для балансировки Active-Active в MikroTik используется таблица Mangle для маркировки соединений и несколько маршрутных таблиц (routing marks).

Главный вызов: обеспечение непрерывности работы VPN-туннелей

Сохранение VPN-соединений при переключении шлюзов - самая сложная задача. Проблема в том, что большинство VPN-протоколов (особенно IPsec в режиме tunnel) жёстко привязывают туннель к IP-адресам конечных точек.

Решение 1: Использование DynDNS или плавающего публичного IP. Настройте динамический DNS (например, через Cloudflare API) для доменного имени, указывающего на ваш VPN-шлюз. Скрипт на маршрутизаторе должен обновлять запись при смене активного WAN-интерфейса. Удалённая сторона будет подключаться по доменному имени, а не по фиксированному IP. Это универсальный метод для Site-to-Site туннелей.

Решение 2: Агрессивные настройки Dead Peer Detection (DPD) и переподключения. В настройках IPsec (например, в strongSwan или на межсетевом экране) сократите таймауты DPD. Пример для strongSwan (ipsec.conf): dpdaction=restart dpddelay=10s dpdtimeout=5s Это заставит туннель быстро обнаружить потерю пира и попытаться переподключиться, используя новый исходный IP-адрес. Этот метод требует согласования настроек с удалённой стороной.

Решение 3: Вынос VPN-терминации на виртуальный интерфейс. Создайте bridge или VLAN-интерфейс, который не привязан к физическому WAN. Настройте политическую маршрутизацию (Policy-Based Routing, PBR) так, чтобы весь трафик этого интерфейса использовал Gateway Group (в OPNsense) или routing mark (в MikroTik). Сам VPN-демон (OpenVPN, WireGuard) слушает на этом виртуальном интерфейсе. При смене физического шлюза IP-адрес виртуального интерфейса не меняется, и туннель не рвётся. Это наиболее стабильный, но и более сложный в настройке метод.

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

Внедрение отказоустойчивой маршрутизации - это процесс. Начните с тестирования в нерабочее время. Создайте резервную конфигурацию перед изменениями. Используйте команды ping с разных источников и traceroute для проверки путей. Мониторьте логи шлюзов. Поэтапный подход и использование готовых конфигураций из этой статьи сведут риски к минимуму. Для автоматизации работы с различными API, включая нейросетевые, которые могут использоваться в вашей инфраструктуре, может пригодиться сервис агрегации, например, AiTunnel, предоставляющий единый интерфейс без необходимости настройки сложных VPN-правил для доступа к зарубежным сервисам.