Как обеспечить отказоустойчивость корпоративного VPN: архитектура, резервирование и контроль сбоев

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

Что такое отказоустойчивость VPN и зачем она нужна

Отказоустойчивость VPN — это способность системы сохранять доступ к корпоративным ресурсам, даже если один из ее компонентов вышел из строя. В инфраструктуре с высокой доступностью, или High Availability VPN, трафик автоматически направляется через исправный сервер, канал или площадку. Переключение должно происходить автоматически или по заранее определенной процедуре. В зависимости от архитектуры активное соединение сохранится либо пользователю потребуется подключиться заново, но доступ не должен зависеть от ручного восстановления основного сервера.

В корпоративной инфраструктуре VPN используют в двух основных сценариях: Remote Access VPN подключает к сети отдельных сотрудников и подрядчиков, а Site-to-Site VPN связывает офисы, дата-центры и облачные среды. Общие принципы отказоустойчивости для них одинаковы, но техническая реализация различается: в первом случае важно сохранить пользовательский доступ и аутентификацию, во втором — работу сетевых шлюзов, туннелей и маршрутов.

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

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

• SLA — согласованный уровень доступности сервиса;
• RTO — допустимое время восстановления после сбоя;
• RPO — допустимый объем потерянных данных.

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

Какую архитектуру отказоустойчивого VPN выбрать

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

Active-Passive

В схеме Active-Passive трафик обрабатывает основной VPN-сервер, а резервный принимает его роль при сбое. Узлы синхронизируют настройки, а при необходимости — состояния пользовательских сессий, чтобы переключение прошло с минимальным разрывом.

Различают горячее, теплое и холодное резервирование. Горячий узел постоянно готов принять трафик; теплый требует короткой подготовки; холодный запускают и настраивают после отказа. Чем быстрее резервный узел готов принять нагрузку, тем дороже его содержание, поэтому Active-Passive подходит компаниям с умеренной нагрузкой, которым важна доступность VPN, но не нужна постоянная работа всех серверов.

Active-Active

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

Этот вариант оправдан при высокой или неравномерной нагрузке. Например, если через VPN одновременно работают сотни удаленных сотрудников, отказ одного сервера не должен перегрузить второй и вызвать новый сбой.

Географическое резервирование

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

На практике эти подходы можно сочетать: например, развернуть Active-Passive-кластер на основной площадке и резервный VPN-сервер в другом дата-центре.

Реклама 16+

Коннект от Контур.Эгиды

Организуйте безопасный и удобный доступ к рабочим ресурсам компании из любой точки мира.

Оставить заявку

Как устроен отказоустойчивый VPN

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

Кластер и синхронизация

VPN-серверы могут объединять в кластер и предоставлять пользователям единую точку подключения — например, виртуальный IP-адрес, доменное имя или адрес балансировщика. При отказе одного узла трафик перенаправляется на другой: пользователь в любом случае обращается к одному адресу, а инфраструктура определяет, какой узел обработает соединение. При выходе основного сервера из строя его роль принимает другой.

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

Каналы, маршруты и балансировка

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

В схеме Active-Active трафик распределяется между узлами с помощью балансировщика, механизмов ECMP, Anycast или встроенных облачных шлюзов в зависимости от реализации. В Active-Passive он направляет подключения на основной сервер и исключает его из схемы, если проверка доступности обнаружила сбой.

В локальной сети одной площадки отказоустойчивость обычно обеспечивают с помощью плавающего IP‑адреса, VRRP или OSPF — последний помогает динамически перенаправлять трафик внутри самой площадки. А вот если инфраструктура распределенная, с несколькими географически разнесенными узлами и VPN‑туннелями, тут уже нужен BGP. Он автоматически обменивается маршрутами между туннелями, быстро убирает из таблиц маршрутизации сбойные соединения и распределяет нагрузку между каналами. OSPF для таких задач не подходит: он работает внутри одной управляемой сети и не умеет управлять VPN‑туннелями между разными площадками.

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

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

Как настроить отказоустойчивый VPN

Настройку отказоустойчивого VPN начинают не с создания второго сервера, а с поиска общих точек отказа. Рабочая последовательность выглядит так:

1. Определить допустимое время простоя и сценарии, которые должна выдержать система: отказ сервера, канала, провайдера или всей площадки.
2. Выбрать архитектуру — Active-Passive, Active-Active или географически распределенную.
3. Разместить узлы так, чтобы они не зависели от одного оборудования, канала и источника питания.
4. Настроить единые политики доступа и синхронизацию конфигураций, сертификатов, ключей и, если требуется, пользовательских сессий.
5. Подключить резервные каналы и VPN-туннели, настроить маршруты до корпоративных ресурсов.
6. Настроить проверки доступности и условия автоматического переключения: какие сбои считаются критичными, после какого количества неудачных проверок система должна перейти на резервный узел и когда узел можно вернуть в работу.
7. Проверить, что резервный сервер выдерживает расчетную нагрузку и использует те же параметры шифрования и политики доступа.
8. Отключить основной узел в тестовом режиме и измерить фактическое время восстановления.

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

Безопасность VPN при аварийном переключении

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

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

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

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

Мониторинг и действия при отказе VPN

Отказ VPN важно обнаружить раньше, чем о нем сообщат пользователи. Проверка только доступности сервера недостаточна: узел может отвечать на сетевые запросы, но не устанавливать защищенное соединение или не пропускать трафик к корпоративным ресурсам.

Что контролировать

Система мониторинга должна отслеживать:

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

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

Алерты и реагирование

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

При отказе VPN стоит действовать по заранее подготовленному плану:

1. Определить масштаб сбоя: затронут один пользователь, один сервер, канал или вся площадка.
2. Проверить, произошло ли автоматическое переключение на резервный узел.
3. Убедиться, что пользователи могут подключиться и получают доступ только к разрешенным ресурсам.
4. При необходимости вручную переключить трафик и отключить неисправный узел.
5. После восстановления проверить конфигурацию и только затем возвращать основной сервер в работу.

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

Как тестировать отказоустойчивость

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

Во время проверки оценивают:

• произошло ли автоматическое переключение;
• сколько времени заняло восстановление доступа;
• сохранились ли активные сессии или пользователям пришлось подключаться заново;
• применяются ли на резервном узле актуальные правила доступа и шифрования;
• выдерживает ли он полную нагрузку;
• корректно ли система возвращается к штатной схеме после восстановления.

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

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

Облачный и локальный отказоустойчивый VPN

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

Облачные платформы предоставляют готовые механизмы высокой доступности, но их возможности различаются. Например, в AWS можно подключить несколько Site-to-Site VPN-соединений к Transit Gateway, Azure VPN Gateway поддерживает два активных экземпляра шлюза, а Google Cloud HA VPN использует два интерфейса с резервными туннелями. Защиту от отказа целого облачного региона в каждом случае нужно проектировать отдельно.

Но высокая доступность облачного сервиса не гарантирует доступность всей цепочки: точкой отказа могут остаться корпоративный маршрутизатор, локальный интернет-канал или один оператор связи.

Выбор здесь зависит не столько от места размещения VPN-серверов, сколько от того, какие сбои должна пережить система. Так, для небольшой компании может быть достаточно локальной схемы Active-Passive с резервным каналом, а для критичных сервисов — распределения узлов между собственным дата-центром и облаком.

Информационная безопасность бизнеса

Контур.Эгида — сервисы информационной безопасности: уменьшение рисков внутренних угроз и утечек конфиденциальных данных, предотвращение атак злоумышленников.

Оставить заявку