Кому нужен VPN?

На март 2017 г. доля вакансий о работе с удаленным доступом, размещенных на hh.ru составляла 1,5% или 13 339 вакансий. За год их число удвоилось. В 2014 г. численность удаленных сотрудников оценивалась в 600 тыс. чел или 1% от экономически-активного населения (15–69 лет). J'son & Partners Consulting прогнозирует, что к 2018 г. около 20% всех занятых россиян будут работать удаленно. Например, до конца 2017 г. Билайн планирует перевести на удаленное сотрудничество от 50% до 70% персонала.

Зачем компании переводят сотрудников на удаленку:

• Сокращение затрат компании на аренду и содержание рабочих мест.
• Отсутствие привязки к одной локации дает возможность собирать команду
  проекта, которую никогда нельзя было бы собрать в пределах одного города. Дополнительный плюс – возможность использования более дешевой рабочей силы.
• Удовлетворение потребности сотрудников в связи с их семейными обстоятельствами.

Мы для себя открыли потребность в VPN более 10 лет назад. Для нас мотиватором предоставления VPN доступа сотрудникам была возможность оперативного доступа в корпоративную сеть из любой точки мира и в любое время дня и ночи.

Путь выбора идеального VPN решения

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

VPN в роутерах

Так называемых “китайских решений” на рынке много. Практически любой роутер имеет функциональность встроенного VPN сервера. Обычно это простое вкл/выкл функционала и добавление логинов паролей для пользователей, иногда интеграция с Radius сервером. Почему мы не стали рассматривать подобное решение? Мы прежде всего думаем о своей безопасности и непрерывности работе сервиса. Подобные же железки не могут похвастаться ни надежной защитой (прошивки выходят обычно очень редко, или не выходят в принципе), да и надежность работы оставляет желать лучшего.

VPN Enterprise класса

Если посмотреть на квадрат Гартнера то на VPN рынке уже давно лидирующие позиции занимают компании, которые производят сетевое оборудование. Juniper, Cisco, Check Point: все они имеют комплексные решения решения, в составе которых есть и VPN сервис.

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

Microsoft VPN

10 лет назад мы были компанией, ориентированной прежде всего на Windows. Microsoft предлагает бесплатное решение для тех, у кого вся инфраструктура построена на их базе. В простых случаях настройка не вызывает сложностей даже у начинающего системного администратора. В нашем случае мы хотели выжать из VPN все с точки зрения безопасности, соответственно, использование паролей было исключено. Мы естественно хотели использовать сертификаты вместо паролей и для хранения ключевой пары использовать свой продукт Рутокен ЭЦП. Для реализации проекта нам нужно было: контроллер домена, радиус сервер и правильно поднятая и настроенная инфраструктура PKI. Подробно на настройке я останавливаться не буду, в интернете есть достаточно много информации по данным вопросам, а правильная настройка PKI вообще может потянуть на десяток статей. Первым протоколом, который мы использовали у себя, был протокол PPTP. Долгое время данный вариант VPN нас устраивал, но в конечном итоге нам пришлось отказаться от него по двум причинам: PPTP работал далеко не везде и мы начинали пользоваться не только Windows, но и другими операционными системами. Поэтому мы стали искать альтернативы. Замечу, что поддержка PPTP не так давно была прекращена apple. Для начала мы решили посмотреть, что еще из протоколов может предложить на Microsoft. SSTP/L2TP. SSTP нас устраивал всем, за исключением того, что он работал только на Windows. L2TP данным недостатком не обладал, но его настройка и поддержание его в работе показались нам достаточно затратными и мы решили попробовать альтернативы. Хотелось более простого решения, как для пользователей, так и для администраторов.

OpenVPN

Мы в компании “Актив” искренне любим open source. Выбирая замену Microsoft VPN мы не могли обойти стороной решение OpenVPN. Основным плюсом для нас было то, что решение "из коробки" работает на всех платформах. Поднять сервер в простом случае достаточно просто. Сейчас, используя docker и, к примеру готовый образ, это можно сделать за несколько минут. Но нам хотелось большего. Нам хотелось добавить в проект интеграцию с Microsoft CA, для того, чтобы использовать выданные ранее сертификаты. Нам хотелось добавить поддержку используемых нами токенов. Как настраивать связку OpenVPN и токены описано к примеру вот в этой статье. Сложнее было настроить интеграцию Microsoft CA и OpenVPN, но в целом тоже вполне реализуемо. Получившимся решением мы пользовались около трех лет, но все это время продолжали искать более удобные варианты. Главной возможностью, которую мы получили, перейдя на OpenVPN, был доступ из любой ОС. Но остались еще две претензии: сотрудникам компании нужно пройти 7 кругов ада Microsoft CA для выписывания сертификата, а администраторам по-прежнему приходилось поддерживать достаточно сложную инфраструктуру VPN.

Рутокен VPN

У нас есть знание, как использовать токены в любых операционных системах, у нас есть понимание, как правильно готовить инфраструктуру PKI, мы умеем настраивать разные версии OpenVPN и мы имеем технологии, которые позволяют управлять всем этим удобным для пользователя образом из окна браузера. Так возникла идея нового продукта.

Настройка Рутокен VPN

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

На втором шаге нужно ввести название компании и подождать несколько минут, пока устройство произведет настройку встроенного центра сертификации.

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

Четвертым шагом настройки мы создаем локальных пользователей, или добавляем их из AD

На этом настройку можно считать завершенной, все остальные действия может произвести сам сотрудник (хотя все может сделать и администратор).

Личный кабинет сотрудника

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

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

После установки плагина/расширения нам остается лишь сгенерировать сертификат себе на Рутокен ЭЦП.

И установить клиент под нужную операционную систему:

Как все это работает?

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

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

• Raspberry Pi – уже достаточно известный микрокомпьютер, который обладает вполне неплохой производительностью при не самой высокой стоимости и который можно начать использовать как VPN-сервер уже через 10 минут после того, как его в прямом смысле вынули из коробки.

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

Но изначально, нам все же нужно осуществить настройку сервисов, которые требуются для корректной работы продукта. Настройка сервисов осуществляется на текущий момент специалистами нашей компании в полуавтоматическом режиме. Это значит, что автоматизирован процесс деплоя программного обеспечения и первичных настроек, но инициализация данного процесса пока остается привилегией человека. Во время первичной настройки устанавливаются системные пакеты, python, django, OpenVPN, supervisor, OpenSSL и пр.

А что же дальше? Далее необходимо настроить всю инфраструктуру, которая собственно и отвечает в целом за безопасность. А именно: CA (центр сертификации), PKI (инфраструктура открытых ключей), выписать необходимые ключи и сертификаты.

Создание PKI и CA, а также формирование файла конфигурации OpenVPN-сервера, генерация ключей и выписывание сертификатов осуществляется уже после передачи продукта клиенту. Но это не значит, что для этого необходимо иметь какие-то специфические знания и прямой доступ к операционной системе. Все реализовано в бизнес-логике бэкенда системы администрирования, доступ к которой предоставляется через Web-интерфейс. От клиента требуется только ввести минимальный набор атрибутов (описано выше), после чего стартует процесс инициализации PKI и создания СА. Описывать конкретные вызовы системных команд смысла особого нет, так как уже давно все описано и разжевано до нас. Главное, что мы сделали — это автоматизировали данный процесс, избавив пользователя от необходимости обладать специфическими знаниями в администрировании.

Для работы с ключами и сертификатами мы решили не изобретать велосипед (хотя очень хотелось и до сих пор вынашиваем мысль его изобрести исходя из наших дальнейших планов развития продукта) и используем easy-rsa.

Самый долгий процесс при настройке инфраструктуры – это генерация файла Diffie-Hellman. Мы долго экспериментировали с параметрами и пришли к балансу “качество-производительность”. Хотя были мысли вообще избавиться от данного шага, нагенерировать таких файлов заранее, используя наши серверные мощности и просто “раздавать” их во время первичной инициализации. Тем более, что данные, содержащиеся в этом файле не являются приватными. Но пока мы оставили эти мысли для дальнейших “изысканий”.

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

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

При инициализации процесса выписывания сертификата, осуществляется запрос на токен для генерации ключевой пары а также запрос на выписку сертификата в CA. Приватный ключ записывается на токен, а запрос на выписку сертификата отправляется в СА, который в свою очередь осуществляет его выписывание и возвращает в ответе. После чего сертификат так же записывается на токен.

Почти все готово для установления VPN-соединения. Не хватает клиента, который “знает”, как работать с сервером и нашими токенами.

Наш клиент реализован на Electron. Кто не в курсе, что это за зверь, то если совсем кратко – возможность реализовать десктопное приложение, используя js, css и html. Не вдаваясь в подробности, клиент является неким “враппером” над OpenVPN-клиентом, позволяющим осуществлять его вызовы с нужными параметрами. Почему именно так? На самом деле нам было так удобней, хотя выбранное решение и накладывает определенные ограничения.

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

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

Немного о наших планах. Основное, над чем сейчас мы работаем — это реализация ГОСТ-шифрования. Уже пройден достаточно большой путь исследований, позволивший нам максимально приблизиться к ее реализации. В ближайшее время сможем удовлетворить интерес потенциальных клиентов в данной функциональности.