VPN под нагрузкой: как COVID-19 положил SSL-концентраторы у трёх клиентов за одну неделю

Понедельник, начало марта. К обеду прилетает первый тикет: у клиента А не могут подключиться к VPN половина сотрудников, шлюз «тупит». К вечеру - клиент Б, та же история, SSL-концентратор перестал принимать новые сессии. К ночи - клиент В, там совсем плохо: шлюз ушёл в рестарт по перегрузке CPU и не восстановился нормально.

Три разных компании, три разных вендора (Cisco ASA, Fortinet FortiGate, Check Point), одна причина: руководство в пятницу сказало «переводим всех на удалёнку с понедельника», а VPN-инфраструктура проектировалась под 10-15% одновременно работающих удалённо - обычный офис, несколько командировочных, пара больничных. Теперь же подключиться пытаются все сразу.

Что именно сломалось и почему

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

Cisco ASA у клиента А - исчерпан лимит одновременных SSL VPN-сессий по лицензии. ASA продаётся с ограничением по количеству AnyConnect-сессий, которое прописано в лицензии. Купленный когда-то лицензионный пакет покрывал 50 одновременных соединений - этого хватало с запасом при обычном режиме. В понедельник утром попыток подключения стало 300+. Железо могло бы потянуть, лицензия - нет. ASA честно отказывала новым сессиям при достижении лимита, люди видели ошибку «exceeded maximum connection limit».

FortiGate у клиента Б - лицензионный лимит не проблема (FortiGate SSL VPN без ограничений по сессиям в базовой лицензии для большинства моделей), но проблема оказалась в CPU. Модель была выбрана с учётом firewall throughput, но без расчёта на SSL-offload. Каждая SSL VPN-сессия - это криптографическая нагрузка, и когда сессий стало в десять раз больше, FortiGate начал деградировать: пакеты дропались, задержки росли, пользователи жаловались что «VPN работает, но всё жутко тормозит». CPU держался на 95-98%, и запаса не было никакого.

Check Point у клиента В - комбинация: и лицензионный cap, и нехватка памяти. Check Point Remote Access VPN лицензируется отдельно, и купленный blade покрывал ограниченное количество пользователей. Кроме того, при резком росте числа соединений security gateway начал исчерпывать connection table - таблица состояний переполнилась, и шлюз стал вести себя нестабильно вплоть до kernel panic и перезагрузки.

Как решали - оперативно

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

Клиент А (Cisco ASA): экстренный запрос на расширение лицензии. Cisco позволяет выдать временные eval-лицензии через партнёра достаточно быстро - это спасло ситуацию в первый день. Параллельно начали смотреть на возможность поднять второй ASA-узел в режиме Active/Active с балансировкой через DNS round-robin - это не самый изящный способ, но рабочий. Постоянная лицензия на 500 сессий оформляется, пока - временная.

Клиент Б (FortiGate): здесь лицензия не поможет - упёрлись в железо. Решение оказалось в том, что в серверной у клиента стоял FortiGate старшей модели, купленный как «будущая замена» и пылившийся в ожидании. Его подняли как дополнительный VPN-терминатор, настроили split DNS и распределили пользователей между двумя шлюзами по подразделениям (через разные профили в корпоративном портале). Не элегантно, зато работает сегодня, а не через месяц. Нагрузка распределилась примерно 50/50.

Клиент В (Check Point): самый сложный случай. Пока добывали лицензию - подняли второй gateway в кластере, вынесли Remote Access VPN на него отдельно. Check Point поддерживает разделение трафика между gateway в кластере, так что это было возможно без серьёзной реструктуризации политик. Connection table limit подняли через команды в gaia, параллельно оптимизировали timeout'ы неактивных сессий - много «зависших» соединений от пользователей, которые просто закрыли ноутбук.

Мониторинг, которого не было

Один из неприятных выводов: у всех трёх клиентов не было нормального мониторинга VPN-сессий. Был общий мониторинг доступности шлюза - пинг, SNMP uptime. Но метрик по количеству активных сессий, утилизации лицензионного пула, CPU на SSL-offload - не было. Поэтому о проблеме узнали не по алёрту, а по звонку «у нас VPN не работает».

После стабилизации ситуации первым делом добавили мониторинг:

• Cisco ASA - SNMP OID для current active sessions и licensed sessions, алёрт при достижении 70% лимита.
• FortiGate - мониторинг CPU через SNMP плюс количество SSL VPN-сессий через FortiGate SNMP MIB, алёрт на CPU > 70% и > 80%.
• Check Point - cpstat на количество активных соединений, алёрт через Zabbix.

Пороги 70-80% выбраны с запасом для реакции - при 90% уже некогда думать.

Что это показывает про capacity planning

У нас в managed-сопровождении был стандартный чек-лист для VPN-инфраструктуры, но в него не входил вопрос «что будет если все 100% сотрудников одновременно подключатся удалённо». Исторически это казалось нереалистичным сценарием. Сейчас он стал реальностью за одни выходные.

Мораль простая, хотя и немного запоздалая: лицензионные лимиты - это не абстракция в документации, это реальный потолок, и его надо мониторить как ресурс наравне с CPU и памятью. Capacity planning для VPN нужно считать от пиковой одновременной нагрузки, а не от среднестатистической. И иметь план на случай если потолок будет достигнут - заранее, а не в понедельник утром с тремя звонящими клиентами.

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