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

Но при чтении анотации на Sourceforge прощелкал предложение, гласящее что фаундеры не загоняются на счет того, чтобы доступ предоставлялся из браузера. Так что это SSL VPN работающий на уровне приложения, но, к сожалению, на базе своего клиента, юзающего для работы движок Java и грузящегося отдельным виджетом, инициализирующим соединение. Но при кажущейся простоте, он работает не по щелчку и для настройки соединений приходится повозиться, т.ч все основное достоинство клиента в том, что он ломится на 443 порт VPN сервера, т.ч может использоваться внутри всякой вымученной инфраструктуры, где админы параноики рубят все выходные порты.

Он есть в совсем халявной версии 1.1 предлагающейся на Sourceforge и коммерческой версии 2.0.5 которую дают с офф.сайта в виде полнофункциональной триалки на 30 дней. И вот этот вопрос мне не ясен совершенно, поскольку цен на сайте я вообще не нашел. То есть они видимо её выкатывают когда ты уже все настроил и подключил, дабы ты сразу не отказался от их продукта.

Перед началом установки надо озадачиться сервантом, ибо требований я не нашел, но версия 1.1 кушает в дефолтной установке порядка 450Mb, т.ч я никак не мог понять, почему на дешманской впске за 200 рублей у меня постоянно перегружался сервак при любых изменениях. При памяти в 1Gb все уже жило крайне стабильно и без единого разрыва. Вторая версия ест почти 600Mb оперативки.

Ставится он элментарно, если не считать стандартных плясок с Oracle Java. , прописываем все нужные пути, после чего уже либо стягиваем халявный сервак от 2015 года:
# wget https://sourceforge.net/projects/hypersocket-vpn/files/1.1.0-2269/hypersocket-vpn-gpl-linux-1.1.0-2269.rpm/download

либо регаемся на офф.сайте и получиваем у них hypersocket-one-linux-2.0.5-3110.rpm

После чего инсталяем пакет
# rpm -i hypersocket-one-linux-2.0.5-3110.rpm

После этого либо стартуем первую версию пакета
service hypersocket start
и подключаемся к https://IP:443 c логином admin:admin где сразу переходим к работе

либо вторую
hypersocket-one-console
либо по адресу https://IP:443 довершаем веб-установку, задаем пароли системе и скармливаем предварительно скаченный лицензионный файл

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

Данный VPN Сервак, как я уже сказал, мне особо не подходит, т.к предполагает наличие клиента на стороне удаленного пользователя, но при этом имеет кучу всяких интересных дополнительных фич, вроде доступа к файлам виртуальной файловой системы через которую можно достучаться до виндовых шарингов, ftp содержимому, NFS томам, HTTP файлам и прочему; публикатор веб-страниц для удаленных вебсерверов; кучу всяких фич безопасности от PIN кодов до одноразовых паролей; управление пользователями через мускуль, AS400, Google Business, LDAP.

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

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

IPSec VPN - его преимущества и недостатки

В первую очередь хотелось бы обратить внимание на определение VPN, наиболее распространенное – «VPN - это технология, которая объединяет доверенные сети, узлы и пользователей через открытые сети, которым нет доверия» (©Check Point Software Technologies).

И действительно, в случае доверенных узлов применение IPsec VPN – это наиболее экономичный путь. Например, для соединения сетей удаленных офисов в единую корпоративную сеть не требуется прокладка или аренда выделенных линий, а используется сеть Интернет. В результате построения защищенных туннелей между доверяемыми сетями образуется единое IP-пространство.

А вот при организации удаленного доступа сотрудников IPsec-решения используются для ограниченного количества только доверенных устройств, например для ноутбуков корпоративных пользователей. Для применения IPsec VPN ИТ-служба должна установить и настроить на каждое доверенное устройство (с которого требуется обеспечить удаленный доступ) VPN-клиент, и поддерживать работу этого приложения. При инсталляции IPsec-решений необходимо учитывать их «скрытую» стоимость, связанную с поддержкой и сопровождением, так как для каждого типа мобильного клиента (ноутбук, PDA и др.) и каждого типа сетевого окружения (доступ через интернет-провайдера, доступ из сети компании-клиента, доступ с использованием адресной трансляции) требуется оригинальная конфигурация IPsec-клиента.

Помимо поддержки есть несколько очень важных проблем:

Не для всех доверенных мобильных устройств, используемых в компании есть VPN клиенты;
В различных подсетях, из которых производится доступ (например, корпоративная сеть партнера или заказчика) необходимые порты могут быть закрыты и требуется дополнительное согласование их открытия.

Таких проблем не возникает при использовании SSL VPN.

SSL VPN – алгоритм работы пользователя

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

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

У вас под рукой в лучшем случае компьютер в сети организации, куда вы приехали в командировку, с доступом в Интернет только по протоколу http/https, в худшем случае – обычное Интернет-кафе в вашей гостинице.

SSL VPN успешно решает все эти задачи, причем уровень обеспечения безопасности будет достаточным, для работы с критичной информацией из Интернет кафе…
Фактически вы выполняете следующие действия:

Вам нужен только Интернет-обозреватель (Internet Explorer, FireFox и т.п.);
В Интернет-обозревателе набираете адрес SSL VPN устройства;
Далее автоматически скачивается и запускается Java апплет или ActiveX компонент, который предлагает вам аутентифицироваться;
После аутентификации автоматически применяются соответствующие политики безопасности:
- выполняется проверка на вредоносный код (в случае обнаружения который блокируется);
- создается замкнутая среда обработки информации – все данные (включая временные файлы), переданные из внутренней сети, после завершения сеанса будут удалены с компьютера, с которого осуществлялся доступ;
- Также в процессе сеанса используются дополнительные средства защиты и контроля;
После успешного прохождения процедур безопасности вам становятся доступны все необходимые ссылки «в один клик мышкой»:
- Доступ к файловым серверам с возможностью передачи файлов на сервер;
- Доступ к Web-приложениям компании (например, внутренний портал, Outlook Web Access и т.п.);
- Терминальный доступ (MS, Citrix);
- Инструменты для администраторов (например, ssh консоль);
- И, конечно, возможность полноценного VPN через https протокол (без необходимости предварительной установки и настройки VPN клиента) – конфигурация передается напрямую из офиса, в соответствии с аутентификационными данными.

Таким образом, применение SSL VPN решает несколько задач:

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

SSL VPN – производители и возможности

На рынке SSL VPN доминируют аппаратные решения. Среди поставщиков решений SSL VPN – все известные производители активного сетевого оборудования:

Cisco
Huawai
Juniper
Nokia
И т.д.

Среди программных реализаций специалисты компании «Алатус» выделяют решение на базе SSL Explorer компании 3SP Ltd , которое наиболее точно соответствует требованиям заказчиков.

Так же хотелось бы привести таблицу сравнения возможностей IPSec VPN и SSL VPN:

Характеристика	IPSec VPN
Поддержка приложений
Поддержка бизнес приложений
Поддержка HTTP приложений
Поддержка доступа к файловым серверам
Поддержка терминального доступа
Сетевая архитектура
Корпоративный ПК
Мобильный ПК
Работа из сторонней сети (за межсетевым экраном)	- (Требует открытия портов)	+ (Работа через https)
Публичный компьютер (интернет-кафе)	- (Требует установки клиента)
КПК, коммуникатор	-+ (Для устройства должен быть VPN клиент)
Обеспечение защиты
Возможность строгой аутентификации	+ (В большинстве случаев)

Web single sign-on	-
Автоматическое применение политик безопасности в зависимости от типа объекта и пользователя	- (Требует дополнительных решений)
Дополнительно
Безклиентная технология		+ (достаточно Internet Explorer)
Легкость внедрения	Зависит от решения
Легкость конфигурирования	Зависит от решения
Легкость поддержки	Зависит от решения

SSL VPN в России

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

Published on Февраль 3, 2009 by · Комментариев нет

Если вы пропустили предыдущие части этой серии статей, пожалуйста прочтите:

В первых двух частях этой серии статей о том, как создавать сервер SSL VPN на базе Windows Server 2008, мы рассматривали некоторые основы построения сетей VPN и затем обсудили настройку сервера. На данном этапе мы готовы завершить выполнение некоторых мелких изменений в конфигурации Active Directory и на CA веб сайте. После того как мы выполним этим изменения, мы сконцентрируемся на конфигурации клиента VPN и в конце создадим SSL VPN соединение.

Настройка учетной записи пользователя на использование Dial-up соединений

Учетные записи пользователей требуют разрешений для доступа dial-up, прежде чем смогут подключиться к серверу Windows VPN, который входит в домен Active Directory. Самый лучший способ сделать это – это использовать сервер Network Policy Server (NPS), а также разрешение учетной записи пользователя по умолчанию, которое разрешает удаленный доступ на основе политики NPS. Однако в нашем случае мы не устанавливали сервер NPS, поэтому нам придется настраивать разрешение пользователю для доступа dial-in вручную.

Следующую статью я посвящу использованию NPS сервера и аутентификации EAP User Certificate для создания соединений с SSL VPN сервером.

Для того чтобы разрешить определенной учетной записи пользователя доступ dial-in для подключения к SSL VPN серверу, нужно выполнить следующие шаги. В этом примере мы будем активировать разрешение dial-in доступа для учетной записи администратора домена по умолчанию:

Настройка IIS на сервере сертификации (Certificate Server) для разрешения HTTP соединений для CRL Directory

По каким-то причинам, когда мастер установки устанавливает Certificate Services (службы сертификации) веб сайт, он настраивает CRL директорию на запрос SSL соединения. Хотя с точки зрения безопасности это кажется вполне хорошей идеей, проблема заключается в том, что унифицированный идентификатор ресурса (URI) на сертификате не настроен под использование SSL. Полагаю, что вы сможете самостоятельно создать CDP запись для сертификата, чтобы он смог использовать SSL, но могу поспорить, что компания Microsoft нигде не упоминала об этой проблеме. Поскольку в этой статье мы используем стандартные параметры для CDP, нам необходимо отключить требование SSL на веб сайте CA для пути CRL директории.

Чтобы дезактивировать требование SSL для директории CRL выполните следующие шаги:

Настройка HOSTS файла для VPN клиента

Теперь мы можем уделить все внимание VPN клиенту. Первое что нам необходимо сделать с клиентом, это настроить HOSTS файл, чтобы мы смогли имитировать публичную DNS инфраструктуру. Есть два имени, которые нам необходимо внести в HOSTS файл (то же самое нужно сделать и для публичного DNS сервера, который вы будете использовать в производственных сетях). Первое имя – это имя VPN сервера, как определено общим/субъектным именем сертификата, который мы привязали к SSL VPN серверу. Второе имя, которое нам нужно ввести в HOSTS файл (и публичный DNS сервер), — это имя CDP URL, которое находится на сертификате. Мы рассматривали расположение информации CDP во второй части этой серии.

Два имени, которые необходимо ввести в HOSTS файл в этом примере будут:

192.168.1.73 sstp.msfirewall.org

192.168.1.73 win2008rc0-dc.msfirewall.org

Для настройки HOSTS файла для Vista SP1 VPN клиента выполните следующие процедуры:

Закройте файл и выберите опцию сохранить изменения .

Использование PPTP для подключения к VPN серверу

Мы постепенно приближаемся к созданию SSL VPN соединения! Следующим шагом будет создание VPN коннектора на Vista SP1 клиенте, который позволит нам создать начальное VPN соединение с VPN сервером. В нашем случае это нужно сделать, потому что компьютер клиента не является членом домена. Так как машина не является членом домена, сертификат CA не будет автоматически установлен в ее хранилище Trusted Root Certificate Authorities. Если бы машина входила в домен, автоматическая регистрация позаботилась бы за нас об этой проблеме, так как мы установили Enterprise CA.

Самый простой способ выполнить этот шаг заключается в создании PPTP подключения Vista SP1 VPN клиента к Windows Server 2008 VPN серверу. По умолчанию VPN сервер будет поддерживать PPTP соединения, и клиент сначала попробует PPTP, перед тем как пробовать L2TP/IPSec и SSTP. Для этого нам нужно создать VPN Коннектор или объект соединения.

Для создания коннектора на VPN клиенте выполните следующие шаги:

Получение CA Certificate с Enterprise CA

Клиент SSL VPN должен доверять CA, который выпустил сертификат, используемый VPN сервером. Чтобы создать это доверие, нам нужно установить CA сертификат на CA, выпустивший сертификат для VPN сервера. Мы можем это сделать, подключившись к веб сайту регистрации на CA во внутренней сети и установив сертификат VPN клиента в его хранилище Trusted Root Certification Authorities.

Для получения сертификата с сайта регистрации выполните следующие шаги:

Нажимаем Закрыть в диалоговом окне .
Закрываем Internet Explorer .

Теперь нам нужно установить сертификат CA в хранилище Trusted Root Certification Authorities Certificate Store машины клиента VPN. Для этого нужно сделать следующее:

Закрываем консоль MMC.

Настройка клиента на использование SSTP и подключение к VPN серверу через SSTP

И вот почти все готово! Теперь нам нужно отключить VPN соединение и настроить VPN клиента на использование SSTP для VPN протокола. В производственном окружении вам не придется использовать этот шаг для пользователей, так как вы будете использовать пакет Connection Manager Administration Kit для создания VPN объекта соединения для пользователя, который будет включать клиента, использующего SSTP, или вы будете настраивать только SSTP порты на VPN сервере.

Все зависит от конфигурации окружения, поскольку вам нужно распределить время так, чтобы пользователи смогли в течение некоторого времени использовать PPTP, пока вы устанавливаете сертификаты. Конечно, вы можете установить сертификаты CA не через сеть, то есть посредством загрузки с веб сайта или по электронной почте, и в этом случае вам не придется разрешать пользователям PPTP. Но тогда, если какие-то клиенты не поддерживают SSTP, вам потребуется разрешить PPTP или L2TP/IPSec, и вы не сможете отключить все не-SSTP порты. В таком случае вам придется полагаться на ручную настройку или на обновленный пакет CMAK.

Еще одним вариантом здесь может стать привязка SSTP клиента к определенному IP адресу на RRAS сервере. В этом случае вы сможете создать пользовательский пакет CMAK, который ссылается только на IP адрес на SSL VPN сервере, прослушивающем сеть на предмет входящих SSTP соединений. Другие адреса на сервере SSTP VPN будут прослушивать сеть на предмет PPTP и/или L2TP/IPSec соединений.

Выполните следующие шаги для того, чтобы отключить PPTP сеанс и настроить объект подключения VPN клиента на использование SSTP:

Рисунок 29

Заключение

В этой заключительной части нашей серии статей о том, как собрать вместе SSL VPN сервер, используя Windows Server 2008, мы закончили настройку учетной записи пользователя, CRL веб сайта и SSL VPN клиента. Мы также закончили создание SSTP соединения и подтвердили, что оно было успешным. Благодарю!

Источник www.windowsecurity.com

Смотрите также:

Readers Comments (Комментариев нет)

Exchange 2007

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ...

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ...

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть...

Прошло уже более года, после того как мы начали работу с . Накопился некоторый опыт использования описанной конфигурации, были выявлены её плюсы и минусы, сделаны определённые выводы. Опираясь на эти выводы, в данной заметке мы продолжим развитие темы настройки безопасных VPN соединений и рассмотрим шаги, необходимые для организации возможности работы по протоколу SSTP (Secure Socket Tunneling Protocol ).

Опыт использования L2TP/IPsec VPN показал, что при наличии внятной пошаговой инструкции по подключению, большинство пользователей способны без особых проблем настроить такое VPN-подключение самостоятельно. Но всё-таки всегда остаются индивидуумы, которые умудряются наделать ошибок даже в таких условиях, и поэтому мысль о необходимости упрощения процесса создания VPN-подключения всегда мелькала где-то на заднем фоне. К тому же в ряде ситуаций мы столкнулись с проблемой блокировки некоторых портов, необходимых для L2TP/IPsec VPN, обнаруженной на уровне интернет-провайдеров. Причём иногда дело доходило до абсурда, когда у одного и того-же интернет-провайдера трафик L2TP/IPsec в одном конце города транслировался беспрепятственно, а в другом конце города блокировался. Мы уже даже мысленно поделили для себя зоны разных интернет-провайдеров на сегменты, где L2TP/IPsec VPN будет работать без нареканий, и на зоны, где точно будут проблемы и нам потребуется подумать об альтернативных вариантах доступа к ресурсам локальной корпоративной сети. Помимо этого, были и случаи, когда командированные пользователи и "отпускники", удалённо пытающиеся подключиться через "гостиничный интернет", испытывали проблемы в силу всё тех же проблем с блокировкой нужных портов. Разумеется перед внедрением L2TP/IPsec VPN мы понимали все эти риски и в подавляющем большинстве проблемных ситуаций находилось какое-то обходное решение, но "осадочек" от каждой такой ситуации оставался неприятный.

Я начал вспоминать, почему же ранее мой выбор пал именно на L2TP/IPsec. Определяющих факторов было два – приемлемый уровень безопасности и поддержка более широкого круга клиентских ОС. Помню, что в то время меня заинтересовал протокол SSTP , но было пару факторов, которые заставили меня отстраниться от данной технологии. Во первых, на то время у нас было ещё достаточное количество клиентов на базе Microsoft Windows XP, а в этой ОС протокол SSTP, как известно, не поддерживается. Во вторых, у меня не было возможности использовать публичный сертификат с корпоративными доменными именами для защиты SSTP соединений, а заменять его на сертификат внутреннего выделенного ЦС не было желания, так как это влекло за собой проблемы связанные с распространением его корневого сертификата на интернет-клиентов и публикации списка отзыва сертификатов (Certificate Revocation List – CRL ) в Интернет.

Но прошло время, клиентов с Windows XP стало на порядок меньше (усиление корпоративной политики ИБ и агрессивные рекламные компании Microsoft по обновлению ОС сделали своё дело), а у меня появилась возможность работы с публичным сертификатом. К тому же на глаза мне попалась информация о том, что на таких OC, как Linux и Apple Mac OS X, клиентское ПО для поддержки SSTP подключений уже давно вполне успешно эксплуатируется, несмотря на то, что в своё время этому протоколу пророчили "Win-изоляцию" в силу его проприетарности.

Таким образом, совершенно определённо, для нас настало время испытать на практике все преимущества SSTP, в частности возможность работы практически в любых условиях, везде, где только есть возможность использования стандартного Интернет-соединения по протоколу HTTPS (TCP 443). То есть при использовании SSTP, теоретически, у вас нигде не должно возникнуть проблем с VPN подключением, ни из дома (даже при условии использования всяких там NAT-ов и всевозможных кривых настроек местного сетевого оборудования интернет-провайдеров), ни в гостинице (даже при условии использования прокси), ни где быто ни было ещё. К тому же процедура настройки VPN-соединения с использованием SSTP на клиентской системе упрощается до безобразия и не подразумевает манипуляций с цифровыми сертификатами (при условии, что на стороне сервера используется публичный сертификат).

Основные требования к клиентам и их настройка

Если речь вести о клиентских системах на базе ОС Microsoft Windows , то нужно учесть, что SSTP работает на системах начиная с Windows Vista SP1 и более поздних. Для клиентских систем ниже Windows Vista SP1, в том числе и для ещё "живых мамонтов" в виде Windows XP , как и ранее, предполагается использование протокола L2TP/IPsec со всеми вытекающими обстоятельствами, о которых я говорил выше. От использования протокола PPTP , как уже давно скомпрометированного, предлагается отказаться вовсе. Ссылки на обновлённые инструкции по настройке SSTP соединения на клиентских ОС Windows можно найти в конце этой статьи.

Для клиентских систем на базе ОС Linux вполне жизнеспособным себя показывает проект с открытым исходным кодом . Мной уже подготовлены пошаговые инструкции для не особо искушённых пользователей Linux-систем на примере настройки в Ubuntu Linux 14.04 и 15.04 /15.10 .

По поводу клиентских систем на базе ОС Apple Mac OS внятного пока ничего сказать не могу, так как под руками их у меня попросту нет. По имеющейся поверхностной информации можно использовать (в качестве консольного варианта), а можно использовать созданный на его основе пакет iSSTP с управлением через графический интерфейс. Надеюсь, что в ближайшее время Виталий Якоб нас порадует соответствующей инструкцией пользователя.

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

Основные требования к VPN-серверу и его настройка

Серверную часть VPN-соединения в нашем случае будет представлять собой расширение к VPN-сервера на базе Windows Server 2012 R2 с ролью Remote Access .

Из основных требований к VPN-серверу, как уже наверно понятно из всего вышесказанного, является наличие на нём установленного сертификата. Получить такой сертификат можно из публичных ЦС и, как правило, такие сертификаты стоят немалых денег. Но есть и бесплатные варианты, например WoSign Free SSL Certificates . Сам я пока опыта общения с таким ЦС не имел, и поэтому будет интересно выслушать Ваши комментарии по этому поводу.

Требования к сертификату VPN-сервера

Важным для SSTP является то, что при генерации запроса на получение сертификата от стороннего публичного ЦС нужно помнить про то, что в запрашиваемом сертификате должна присутствовать политика применения (Extended Key Usage , EKU ) - Server Authentication (1.3.6.1.5.5.7.3.1 ). Само собой для такого сертификата должен быть разрешён экспорт закрытого ключа, так как возможно нам потребуется установка сертификата на несколько VPN-серверов в случае, если, например, используется кластерная конфигурация.

Обязательным требованием к получаемому сертификату является также то, что список отзыва сертификатов (CRL ) указанный в сертификате обязательно должен быть доступен в Интернете, так как в самом начале создания SSTP соединения клиентский компьютер будет пытаться проверить не является ли предоставленный VPN-сервером сертификат отозванным. Не будет доступного CRL – не будет SSTP соединения.

Полученный сертификат устанавливается на VPN-сервере в хранилище сертификатов Local Computer \Personal и должен иметь привязку к закрытому ключу этого сертификата.

Также разумеется, что ЦС выдавшему сертификат должны доверять не только наши VPN-серверы, но и все наши внешние Интернет-клиенты, которые будут подключаться к этим серверам по протоколу SSTP. То есть корневой сертификат (их может быть и несколько) должен присутствовать на всех компьютерах в хранилище сертификатов Local Computer \Trusted Root Certification Authorities . Информацию об этих требованиях можно найти в статье TechNet Library - Configure RRAS with a Computer Authentication Certificate . В большинстве современных клиентских ОС коллекция публичных корневых сертификатов обновляется автоматически при наличии постоянного подключения к Интернет.

Настройка роли Remote Access

После того, как на VPN-сервере установлен сертификат, откроем оснастку Routing and Remote Access и в свойствах сервера VPN на вкладке Security выберем этот сертификат для SSTP в разделе SSL Certificate Binding

Изменение этой опции выведет предложение об автоматическом перезапуске служб RRAS. Соглашаемся с перезапуском служб.

Далее в разделе Ports добавим порты SSTP . В нашем примере под SSTP соединения отдаётся большая часть портов и небольшая часть портов выделяется для клиентов без поддержки SSTP, например Windows XP. Возможность же подключения по протоколу PPTP отключаем совсем.

Информацию о том, как правильно отключить возможность подключения по протоколу PPTP, можно найти в статье Routing How To...Add PPTP or L2TP ports . Пример на скриншоте:

После сделанных изменений проверим TCP прослушиватели (TCP Listener) работающие на нашем VPN-сервере. Среди них должен появиться прослушиватель для 443 порта, на который VPN-сервером будут приниматься клиентские подключения по протоколу SSTP:

netstat -na | findstr 443

Не забываем настроить брандмауэр, включив уже имеющееся после установки и настройки роли Remote Access правило Secure Socket Tunneling Protocol (SSTP-In)

Поимо этого можно отключить разрешающее правило для входящих PPTP -подключений на порт TCP 1723 (в конфигурации по умолчанию это правило называется "Routing and Remote Access (PPTP-In) ")

Так как наш VPN-сервер является членом NLB -кластера, нам потребуется дополнительно создать правило разрешающее балансировку порта TCP 443 .

Сделанных настроек вполне достаточно для того чтоб наш VPN-сервер смог успешно принимать SSTP подключения.

Проверяем подключение VPN-клиента

На клиентской машине имеющей прямой доступ в интернет по 443 порту настраиваем проверочное VPN-соединение и выполняем подключение…

На стороне сервера при этом убеждаемся в том, что клиент использует один из свободных созданных нами ранее SSTP портов…

Инструкции для пользователей

Как уже отмечалось ранее, для пользователей выполняющих подключение к корпоративным VPN-серверам из Интернет необходимо разработать чёткие пошаговые инструкции. Мне удалось протестировать (и параллельно разработать пошаговые инструкции для пользователей) VPN-подключения в составе следующих операционных систем:

Windows XP 32-bit RU SP3
(Инструкция переписана с учётом использования L2TP/IPsec, но при отсутствии работающего PPTP. Запрос и установка сертификата делаются в два этапа разными скриптами)
Windows Vista Business 32-bit RU SP2 (SSTP)
Windows 7 Pro 32-bit RU SP1 (SSTP)
Windows 8.1 Pro 64-bit RU (SSTP)
Ubuntu Desktop Linux 14.04 64-bit (SSTP)
Ubuntu Desktop Linux 15.04 64-bit (SSTP)
Ubuntu Desktop Linux 14.10 64-bit (SSTP)

Инструкции в формате DOCX (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке . Часть инструкций доступна для онлайн просмотра и обсуждения .

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

Сегодня сети VPN стали фактическим стандартом для взаимосвязанных корпоративных сетей. Они очень удачно применяются в межсетевых соединениях. К сожалению, сложность традиционной технологии VPN со временем повышается, поскольку разработчики VPN-продуктов пытаются обслуживать другие приложения, в том числе пользователей коммутируемых, широкополосных и беспроводных соединений. Количество настраиваемых параметров стремительно растет, и в результате настройка VPN превращается в испытание даже для опытных сетевых инженеров. Индивидуальные удаленные пользователи должны установить специальную клиентскую программу, которая порой мешает обычной работе сети и достаточно сложна в настройке и эксплуатации. Положение усугубляется тем, что некоторые Интернет-провайдеры блокируют протоколы VPN, такие как Cisco Generic Routing Encapsulation (GRE) и Layer 2 Tunneling Protocol (L2TP), взимая дополнительную плату за их использование.

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

Чтобы понять, как использовать сети SSL VPN вместо IPSec-разновидности, необходимо знать спектр продуктов и различные реализованные в них наборы функций. Список продуктов данной категории приведен в таблице «Основные участники рынка SSL VPN» . Одни продукты SSL VPN функционируют совсем без клиентов, а в других используются небольшие апплеты Java или модули ActiveX, автоматически загружаемые из Web. В ряде продуктов применяется простая проверка подлинности с идентификатором пользователя/паролем; в других же используются очень надежные цифровые сертификаты и/или двухфакторная проверка подлинности. В некоторых продуктах подключенным пользователям предоставляется полный доступ к сети; в других доступ можно ограничить только ресурсами, определенными политиками. Такова картина на рынке.

Принципы действия

Чтобы разобраться в принципах действия SSL VPN, рассмотрим основы IPsec для индивидуальных удаленных пользователей, для которых хост-компьютер выглядит напрямую подключенным к частной сети за брандмауэром компании. В IPsec этот эффект достигается благодаря созданию виртуального интерфейса сети непосредственно на компьютере конечного пользователя, связанного туннелем со шлюзом IPsec (автономным устройством или встроенным в брандмауэр компании). Поведение и вид этого виртуального интерфейса похоже на любой другой адаптер локальной или распределенной сети; в действительности, большинство IPSec VPN выглядят как Ethernet-платы с собственным IP-адресом и записями в таблице маршрутов. После того, как установлен туннель IPSec, удаленные пользователи могут свободно обращаться ко всем сетевым ресурсам на другом конце туннеля с использованием своих частных IP-адресов.

В отличие от традиционных VPN, сети SSL VPN не обязательно создают виртуальный интерфейс сети. Удаленный пользователь инициирует соединение SSL VPN, направляя браузер на шлюз SSL VPN, который может быть специализированным устройством или сервером с программой SSL VPN, такой как Microsoft Forefront Unified Access Gateway (UAG) 2010. Соединение шифруется с использованием протокола SSL/TLS, и в результате могут применяться различные механизмы проверки подлинности, поддерживаемые SSL. Проверка подлинности пользователей в SSL VPN может выполняться через существующую инфраструктуру каталогов, будь то Active Directory (AD) или открытый стандарт Lightweight Directory Access Protocol (LDAP). В результате пользователям не приходится запоминать дополнительный пароль и исключается одна из точек входа, добавление/удаление которой нужно отслеживать.

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

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

Если пользователям требуется полный дистанционный доступ на сетевом уровне, то применение виртуального сетевого интерфейса, подобного созданному традиционной VPN, и локальных для компании IP-адресов позволяет добиться этого через специфический для каждого продукта приложения-коннектора «виртуальный IPsec». Эти приложения взаимодействуют с операционной системой пользователя таким же образом, как IPsec, путем создания виртуального сетевого интерфейса. Но в отличие от IPsec, этим приложениям не требуется сложная настройка, так как пользователю не предоставляются параметры для выбора. Администратор шлюза SSL VPN выполняет все настройки, назначая различные политики доступа для шлюза. Таким образом, можно предоставить одному пользователю доступ по протоколу FTP к серверу финансового отдела, другому - возможность отправлять почту SMTP и третьему запретить оба этих действия.

Расширенные возможности SSL VPN зависят от поставщика, но, поскольку пользователям не нужно устанавливать никаких программ, проблем совместимости не возникает. Требуется лишь выяснить, поддерживает ли поставщик операционные системы, с которыми работают пользователи. Не все продукты совместимы со всеми операционными системами, но все поддерживают Windows и Internet Explorer (IE), пользователи которых формируют основной спрос на SSL VPN. Но кроме совместимости с операционной системой необходимо учитывать основные категории, на которые делятся продукты SSL VPN: простые, гибридные, многофункциональные и многофункциональные гибридные.

Разновидности SSL VPN

Простой шлюз. Простой шлюз обеспечивает минимальный набор функций SSL VPN, который в действительности достаточно широк: proxy HTTP и HTTPS, детальное управления доступом на уровне IP-адресов, проверка подлинности с использованием пароля и сертификата, учет доступа и управление аудитом. Пользователь почти любого браузера может обратиться к простому шлюзу, так как не применяется никаких приложений или элементов управления ActiveX. Простой шлюз размещается за брандмауэром компании, в локальной сети или демилитаризованной зоне, а трафик следует через порт 443. Простой шлюз не предназначен для функционирования в качестве брандмауэра и во многих случаях подключается к одному порту Ethernet, обслуживающему как сеансы SSL VPN, исходящие из глобальной сети, так и направляемый в локальную сеть пользовательский трафик.

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

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

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

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

Известные уязвимые места

Легко поверить, что с установкой любого VPN-подключения немедленно решаются все проблемы безопасности для удаленных пользователей. Но, как хорошо известно пользователям IPsec, это не всегда так. От неправильно развернутой VPN может исходить такая же опасность, как от локальной сети, подключенной к Интернету без брандмауэра. Если удаленная сеть или конечный пользователь скомпрометированы (вирусом, шпионской программой или взломщиком), то VPN (традиционная или SSL) может стать каналом для проникновения вредоносных агентов во внутреннюю сеть компании.

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

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

Большинство шлюзов SSL VPN автоматически отключают удаленных пользователей от общедоступного Интернета, пока активен туннель VPN, вынуждая пользователей обращаться в Интернет через него. Таким образом удается избежать атак типа split-network, в ходе которых взломщик получает доступ в реальном времени к локальной сети компании через туннель VPN. В SSL VPN для защиты от подобных угроз все обращения к браузеру просто направляются через VPN, а другие Интернет-протоколы блокированы. Но split-network - лишь одна из угроз.

Вторая угроза еще более коварна. На сегодня для нее не существует противоядия, известен только обходной прием. В результате взломщик может полностью завладеть компьютером пользователя; причина в неудачной реализации программы, устанавливаемой многими продуктами в начале сеанса SSL VPN. Если в приложении Java или Active X есть функция для запуска на компьютере пользователя локальной программы, например клиентского приложения, то взломщик сможет запустить вредную программу, в частности простой (но очень опасный) регистратор нажатий на клавиши. В целом эта функция удобна для конечных пользователей: автоматический запуск локальной программы, например для ввода заказов, упростит работу пользователя. Чтобы обойти эту проблему, необходимо отключить функцию запуска приложений.

Третий класс угроз - заражение вирусами и шпионскими программами, что может привести к внедрению опасных программ за брандмауэром. Вредные программы могут проникнуть вместе с вложенными файлами электронной почты и пересылаемыми файлами или (если используются коннекторы протоколов SSL VPN) через любой протокол TCP/IP. Такие угрозы иногда называют пассивными, так как они не направлены на конкретную цель и просто пытаются распространиться на все доступные компьютеры в сети. Благодаря SSL уязвимых мест становится меньше, но они не исчезают.

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

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

Пакет SSL VPN

Подавляющее большинство шлюзов SSL VPN представляют собой специализированные устройства, но есть и программные продукты для серверов UNIX или Windows. Цена как аппаратных, так и программных продуктов определяется в основном количеством пользователей. В аппаратных устройствах это ограничение может зависеть от характеристик оборудования или строго заданного предельного числа пользователей. Для программных продуктов, в том числе Microsoft Forefront UAG, часто требуется отдельно покупать лицензии каждому пользователю.

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

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

Сначала пробуй, затем покупай

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

Мел Бекман ([email protected]) - старший технический редактор System iNEWS. Президент компании Beckman Software Engineering, специализирующейся на техническом консалтинге в области высокомасштабируемых широкополосных сетей

Online-сервисы