SSL VPN для выездных сотрудников: уходим от IPsec-клиентов

В последние несколько месяцев у нас накопилось достаточно кейсов с SSL VPN, чтобы сказать что-то осмысленное. Толчком был очевидный: у клиентов появляются выездные сотрудники с ноутбуками под Windows Vista, с MacBook-ами, а иногда и с Linux - и поддерживать зоопарк IPsec-клиентов под каждую ОС становится отдельным приключением с невесёлым концом.

IPsec VPN как технология никуда не делся и в сети между площадками работает отлично. Но для клиентского доступа с ноутбука через гостиничный Wi-Fi или корпоративный интернет в командировке - там IPsec начинает скрипеть. NAT оператора - первый и самый частый убийца: ESP-пакеты через NAT проходят только если настроен NAT-T, и то не везде. IKE на UDP 500 некоторые хотспоты блокируют напрочь. Корпоративный клиент Cisco, который работал на XP, на Vista может отказаться без объяснений или потребовать переустановки. Звонки в техподдержку «VPN не поднимается» из аэропорта - это потерянное время всех участников.

Почему SSL VPN решает именно эту задачу

Принцип у SSL VPN простой: туннель поверх TLS, порт 443, который не блокирует практически никто. Через NAT проходит без трюков, потому что это обычный TCP. Для пользователя - браузер или тонкий клиент, который скачивается при первом входе и работает на всех ОС, где есть Java или нативный клиент.

Конкретно нас интересовали три варианта: OpenVPN в SSL-режиме, Cisco AnyConnect (пришедший на смену VPN Client) и Juniper SA-серия. Аппаратные решения в данном контексте - Juniper SA 700 и SA 2000.

OpenVPN: свобода и цена этой свободы

OpenVPN работает поверх TLS, порт можно вешать на 443/TCP - трафик неотличим от HTTPS для большинства промежуточных устройств. Клиент есть под Windows, Linux, Mac. На сервере - Linux, FreeBSD, что угодно с нормальным стеком.

Мы развернули у одного клиента: 40 выездных сотрудников, смесь XP и Vista, несколько MacBook. Сервер - CentOS 5, OpenVPN 2.1 RC. Поставили, настроили PKI на базе easy-rsa, выдали сертификаты. Работает.

Подводные камни, которые не очевидны на старте:

Управление сертификатами - если сотрудник уволился, надо отозвать сертификат и убедиться, что CRL раздаётся серверу. Процедура не сложная, но её надо организовать. У нас первые несколько месяцев это делалось вручную по заявке - в итоге договорились на скрипт и процедуру.

Сплит-туннелинг - по умолчанию весь трафик пойдёт через туннель. Если пользователь работает с видео в командировке, канал к серверу засоряется. Настраиваем push route только под корпоративные подсети, остальное - напрямую. Звучит просто, но надо аккуратно описать список подсетей.

Поддержка пользователей - Windows-клиент OpenVPN требует прав администратора при установке TAP-адаптера. На корпоративных ноутбуках с ограниченными правами это отдельная история. Решили преинсталляцией при выдаче ноутбука.

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

Аппаратные решения: Juniper SA

Juniper SA 700 - это железяка, которая встаёт в DMZ и берёт на себя весь SSL VPN. Web-интерфейс для управления, встроенная поддержка LDAP/Active Directory, ролевая модель доступа, встроенный агент проверки состояния хоста (Host Checker).

Последний пункт интересен: перед тем как пустить пользователя в сеть, агент проверяет, установлен ли антивирус, обновлён ли Windows Update до определённого уровня. Если нет - в карантинную зону с минимальным доступом. Для нас это был аргумент при разговоре с клиентом из финансового сектора, которому важно соответствие требованиям и который недавно начал готовиться к ISO 27001.

Стоимость SA 700 - порядка 5-8 тысяч долларов плюс лицензии на количество одновременных пользователей. Это не смешная сумма, но для организации на 200+ человек с серьёзными требованиями к безопасности - сопоставимо с тем, во что обходится поддержка IPsec-зоопарка силами IT-отдела.

Cisco AnyConnect мы видели у нескольких клиентов с уже существующей инфраструктурой Cisco ASA. Работает чисто, интегрируется в привычный административный интерфейс. Если у клиента уже стоит ASA 5500-серии - смотреть в эту сторону логично.

Где SSL VPN не панацея

Надо сказать честно: SSL VPN через 443/TCP - это TCP поверх TCP, если туннелировать произвольный TCP-трафик. При потерях пакетов на канале это приводит к двойным ретрансмиссиям и нестабильной производительности. OpenVPN умеет работать по UDP на произвольном порту - тогда это не проблема, но UDP 1194 блокируется чаще, чем TCP 443.

Для передачи больших объёмов данных или чувствительных к задержкам приложений - RDP, 1С в файловом режиме через медленный канал - SSL VPN не волшебная таблетка. Но для большинства офисных задач: почта, веб-приложения, файловые ресурсы через mapped drive - работает нормально.

Что сейчас

В рамках сопровождения у нас три активных развёртывания SSL VPN: два на OpenVPN, один на Juniper SA. Запрос со стороны клиентов на «сделайте нам VPN, который работает из любой гостиницы» продолжает поступать - и теперь есть понятный ответ без необходимости договариваться с оператором о разрешении ESP-трафика.

IPsec между офисами трогать не планируем - там он работает как надо. А вот клиентский доступ, судя по нашей практике, переезжает на SSL-туннели.