С IPsec-клиента на Cisco AnyConnect SSL VPN: certificate pinning, split tunneling и RADIUS+TOTP

Удалённая работа перестала быть исключением - для части команд это уже норма. Вместе с этим старый добрый IPsec-клиент, который работал «как-то», начал давать трещины: жалобы на обрывы за NAT, проблемы с мобильными устройствами, и главное - ни одного вменяемого способа добавить второй фактор аутентификации без колхоза. Один из клиентов на сопровождении дозрел до миграции на Cisco AnyConnect SSL VPN. Разбираем, что из этого вышло.

Почему SSL VPN, а не починить IPsec

IPsec работает хорошо, пока сеть послушная. Как только между клиентом и ASA появляется NAT (гостиница, кафе, домашний роутер с агрессивным файерволом) - начинаются приключения с UDP 500/4500 и IKE. NAT-T помогает, но не всегда. SSL VPN работает через HTTPS на порту 443, и пробиться через него умеет практически любая сеть.

Второй момент - клиент. Cisco VPN Client для IPsec официально мёртв, и тащить его на новые машины - отдельное удовольствие. AnyConnect - живой продукт с клиентами под Windows, OS X и Linux, плюс нормальная поддержка мобильных платформ через профили XML.

Certificate pinning: чтобы не подключались куда попало

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

Certificate pinning в AnyConnect решается через XML-профиль подключения. В секции <ServerList> для каждого хоста можно указать <CertificateHash> - SHA-256-хеш сертификата ASA. Клиент сверяет его при каждом подключении, и если хеш не совпадает - соединение не устанавливается, пользователь получает ошибку. Обновлять хеш при плановой смене сертификата надо заблаговременно - профиль раскатывается через ASDM или SCCM, это не мгновенная операция.

Отдельный вопрос - CA. Корпоративный VPN стоит подписывать на внутреннем CA, а не на публичном. Это даёт полный контроль над жизненным циклом сертификатов и убирает зависимость от внешних сервисов.

Split tunneling: не гнать весь трафик через офис

По умолчанию AnyConnect настраивается в режиме full tunnel: весь трафик клиента идёт через VPN, включая YouTube, почту и всё остальное. Это создаёт нагрузку на канал офиса и замедляет интернет у пользователя.

Split tunneling решает это изящно: через VPN идут только корпоративные подсети, остальное - напрямую. Настраивается через ACL на ASA и атрибут в группе ASDM. Список сетей передаётся клиенту в момент установки туннеля.

Здесь есть нюанс, который не все учитывают: split tunneling удобен, но ослабляет контроль. Если у пользователя на машине зловред, он может ходить наружу напрямую, минуя корпоративный периметр. Для компаний с требованиями compliance или с параноидальной политикой ИБ full tunnel - обоснованный выбор. Мы выбрали split tunneling с явным белым списком корпоративных подсетей и DNS-сервером через туннель - компромисс между удобством и контролем DNS-запросов.

RADIUS+TOTP: второй фактор без боли

Это был главный мотив миграции. IPsec-клиент прикрутить к TOTP было нереально без внешних плясок. AnyConnect через RADIUS-сервер с поддержкой OTP - нормальная история.

Схема такая:

• ASA принимает подключение AnyConnect
• Авторизация идёт на RADIUS-сервер (мы использовали FreeRADIUS)
• FreeRADIUS проверяет первый фактор (пароль AD) через LDAP/AD-модуль
• Второй фактор - TOTP через модуль google-authenticator (библиотека libpam-google-authenticator, давно умеет работать не только с PAM)

Пользователь при подключении вводит пароль в формате пароль+TOTP-код - например МойПароль123456. AnyConnect передаёт его в RADIUS, FreeRADIUS разрезает строку по правилу и проверяет оба фактора. Не самая элегантная схема в мире - существуют RADIUS-серверы, которые умеют диалог challenge/response и показывают пользователю отдельный промпт для OTP - но работает надёжно и понятно пользователям после однократного объяснения.

Регистрация TOTP-токенов для пользователей сделана через внутренний веб-портал - страница с QR-кодом, пользователь сканирует в Google Authenticator или FreeOTP. Процедура занимает две минуты.

Что пошло не по плану

Мобильные клиенты и сертификаты. На iOS и Android AnyConnect требует установки корпоративного CA-сертификата в системное хранилище - иначе ругается на недоверенный сертификат шлюза. На iOS это делается через MDM-профиль, на Android - вручную или через MDM. Те, у кого не было MDM на мобилках, потратили час на ручную установку.

RADIUS timeout при пиковой нагрузке. При одновременном подключении нескольких десятков пользователей FreeRADIUS начинал отвечать медленнее, ASA получала timeout и отклоняла подключение. Решение - увеличить radius-server timeout на ASA с дефолтных 10 до 20 секунд и поднять второй инстанс FreeRADIUS для failover. На стресс-тесте после этого всё держится.

Переучивание пользователей. Формат пароля пароль+TOTP не интуитивен. Несколько человек первые дни путались и звонили в поддержку. Помогло короткое письмо с примером и скриншотами - после него звонки почти прекратились.

Итог

Миграция с IPsec на AnyConnect SSL VPN заняла около двух недель с учётом пилота, тестирования и раскатки на всех пользователей. Основные выигрыши - надёжность подключения из любой сети, второй фактор аутентификации и нормальный живой клиент. Certificate pinning добавляет уверенности, что пользователи подключаются именно туда куда нужно, а не куда им говорят подключиться.

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