Установка SSL VPN сервера Hypersocket. SSL VPN – алгоритм работы пользователя

24.03.2021Рубрика: Доверительный платеж

Удаленный доступ (Remote Access) на сегодняшний день очень важен. С ростом числа людей, нуждающихся в доступе к информации, хранящейся на домашних и рабочих компьютерах, возможность получать такой доступ из любой точки стала решающей. Прошли те дни, когда люди говорили: «я отправлю вам эту информацию, как только доберусь до своего компьютера». Вам нужна эта информация немедленно, если вы хотите достойно конкурировать в сегодняшнем деловом мире.

В каменном веке компьютеризации способом получения удаленного доступа к своему компьютеру было использование dial-up соединения. RAS dial-up соединения работали через обычные POTS (Простая старая телефонная служба - Plain Old Telephone Service) линии при скорости передачи данных примерно до 56kbps. Скорость была основной проблемой таких соединений, но еще более серьезной проблемой была цена соединения, когда получение доступа требовало больших расстояний.

С ростом популярности сети Интернет, соединения RAS стали использоваться все реже. Причиной этого стало появление соединений по VPN (виртуальная частная сеть). Соединения VPN обеспечивали такую же подключаемость точек между собой, как и соединения dial-up RAS, но делали это быстрее и дешевле, поскольку скорость VPN соединения может быть одинаковой со скоростью подключения к Интернет, а стоимость соединения не зависит от расположения места назначения. Единственное, за что приходится платить, это подключение к Интернет.

Виртуальные частные сети (Virtual Private Networking)

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

Серверы Windows Servers и клиенты поддерживали VPN соединения со времен Windows NT и Windows 95. Хотя клиенты и серверы Windows поддерживают VPN соединения на протяжении десятилетия, тип поддержки VPN эволюционировал со временем. Windows Vista Service Pack 1 и Windows Server 2008 на сегодняшний день поддерживают три типа VPN соединений. Это следующие типы:

L2TP/IPSec

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

Более надежным является VPN протокол L2TP/IPSec. L2TP/IPSec был совместно разработан компаниями Microsoft и Cisco. L2TP/IPSec более безопасен чем PPTP, поскольку безопасная сессия IPSec создается до того, как мандаты пересылаются по проводам. Хакеры не могут получить доступ к мандатам, а, следовательно, не смогут украсть их, чтобы впоследствии использовать. Более того, IPSec обеспечивает взаимную аутентификацию машин, поэтому неизвестные машины не смогут соединиться с каналом L2TP/IPSec VPN. IPSec обеспечивает взаимную аутентификацию, целостность данных, конфиденциальность и невозможность отказа от авторства. L2TP поддерживает PPP и EAP механизмы аутентификации пользователей, которые обеспечивают высокую безопасность входа, поскольку требуется аутентификация как машины, так и пользователя.

Windows Vista SP1 и Windows Server 2008 на сегодняшний день поддерживают новый тип VPN протокола " Secure Socket Tunneling Protocol или SSTP. SSTP использует зашифрованные в SSL HTTP соединения, чтобы создавать VPN подключения к VPN шлюзам. SSTP безопасен, так как мандаты пользователя не передаются до тех пор, пока безопасный туннель SSL для соединения с VPN шлюзом не будет открыт. SSTP также известен как PPP через SSL, это означает, что вы можете использовать PPP и EAP механизмы аутентификации, чтобы сделать ваше SSTP соединение более безопасным.

Приватный не значит безопасный

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

Допустим, у вас есть сотрудник, которому вы открыли доступ VPN. Поскольку ваш Windows Server 2008 VPN протокол поддерживает EAP аутентификацию пользователя, вы решили создать смарт-карты для ваших пользователей и использовать L2TP/IPSec VPN протокол. Комбинация смарт-карт и протокола L2TP/IPSec позволяет требовать аутентификации пользователя и использования здоровой машины. Ваше решение по использованию смарт-карт и протокола L2TP/IPSec работает отлично, и все довольны.

Все довольны до тех пор, пока однажды один из ваших пользователей не заходит на ваш SQL сервер, чтобы получить бухгалтерскую информацию, и начинает делиться ею с другими сотрудниками. Что произошло? Разве соединение VPN было небезопасным? Нет, VPN соединение было безопасным ровно настолько, чтобы обеспечить частный (приватный) компонент, аутентификацию и авторизацию, но оно не обеспечивало контроля над доступом, а контроль над доступом является одним из основополагающих компонентов компьютерной безопасности. На самом деле можно даже говорить о том, что без контроля над доступом все остальные меры безопасности представляют сравнительно малую ценность.

Для VPN, чтобы быть на самом деле безопасными, вам нужно убедиться в том, что ваш VPN шлюз способен обеспечить контроль над доступом пользователей/групп с тем, чтобы вы смогли открывать необходимый уровень доступа пользователям VPN. Более совершенные VPN шлюзы и брандмауэры, такие как ISA Firewall, могут обеспечивать такой контроль на VPN соединениях. Плюс ко всему, такие брандмауэры, как ISA Firewall, могут обеспечивать проверку адресных пакетов и уровня приложений на клиентских VPN соединениях.

Хотя сервер Windows Server 2008 VPN не обеспечивает контроль над доступом пользователей и групп, есть другие способы, посредством которых вы можете настраивать контроль доступа на самом сервере, если вы не хотите платить за приобретение более совершенных брандмауэров и VPN шлюзов. В данной статье мы заостряем наше внимание только на компонентах VPN серверов. Если вы хотите узнать больше о брандмауэрах ISA и их возможностях для VPN серверов, перейдите по ссылке www.isaserver.org

Зачем использовать новый VPN протокол?

Microsoft уже создали два жизнеспособных протокола VPN, позволяющих пользователям соединяться с корпоративной сетью, так зачем же создавать третий? SSTP - это отличное дополнение для пользователей Windows VPN, поскольку SSTP не имеет проблем с брандмауэрами и устройствами NAT в отличие от протоколов PPTP и L2TP/IPSec. Для того чтобы PPTP работал через устройство NAT, это устройство должно поддерживать PPTP с помощью редактора NAT для PPTP. Если такой NAT редактор для PPTP отсутствует на данном устройстве, то PPTP соединения не будут работать.

L2TP/IPSec имеет проблемы с устройствами NAT и брандмауэрами, поскольку брандмауэру необходимо иметь L2TP порт UDP 1701, открытый для исходящих соединений, IPSec IKE порт, UDP 500 открытый для исходящих соединений, и IPSec NAT порт просмотра-обхода, UDP 4500 открыт для исходящих соединений (порт L2TP не требуется при использовании NAT-T). Большинство брандмауэров в общественных местах, таких как гостиницы, центры конференций, рестораны и т.д. имеют малое количество портов, открытых для исходящих соединений, например, HTTP, TCP порт 80 и HTTPS (SSL), TCP порт 443. Если вам нужна поддержка не только протоколов HTTP и SSL, когда вы покидаете офис, ваши шансы на успешное соединение значительно снижаются. Вы можете и не получить порты, требуемые для протоколов PPTP или L2TP/IPSec.

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

Процесс соединения SSTP

SSTP VPN клиент создает TCP соединение с SSTP VPN шлюзом между случайным TCP портом источника клиента SSTP VPN и TCP портом 443 шлюза SSTP VPN.
SSTP VPN клиент отправляет SSL Client-Hello сообщение, указывая на то, что он хочет создать SSL сеанс с SSTP VPN шлюзом.
SSTP VPN шлюз отправляет сертификат компьютера клиенту SSTP VPN.
Клиент SSTP VPN подтверждает сертификат компьютера, проверяя базу сертификатов Trusted Root Certification Authorities, чтобы убедиться в том, что CA сертификат, подписанный сервером, находится в этой базе. Затем SSTP VPN клиент определяет способ шифрования для SSL сеанса, генерирует ключ SSL сеанса и шифрует его с помощью SSTP VPN ключа публичного шлюза, после чего отправляет зашифрованную форму ключа SSL сеанса на SSTP VPN шлюз.
Шлюз SSTP VPN расшифровывает зашифрованный ключ SSL сеанса с помощью личного ключа сертификатов компьютера. Все последующие соединения между SSTP VPN клиентом и SSTP VPN шлюзом будут зашифрованы оговоренным методом шифрования и ключа SSL сеанса.
SSTP VPN клиент отправляет HTTP через SSL (HTTPS) сообщение запроса на SSTP VPN шлюз.
SSTP VPN клиент обсуждает SSTP канал с SSTP VPN шлюзом.
SSTP VPN клиент обсуждает PPP соединение с SSTP сервером. Эти переговоры включают аутентификацию мандатов пользователя посредством стандартного PPP метода аутентификации (или даже EAP аутентификации) и конфигурирование настроек для трафика Интернет протокола четвертой версии (IPv4) или Интернет протокола шестой версии (IPv6).
Клиент SSTP начинает отправку IPv4 или IPv6 трафика через PPP соединение.

Те, кому интересны характеристики архитектуры VPN протоколов, могут посмотреть их на рисунке ниже. Обратите внимание, что SSTP имеет дополнительный заголовок в отличие от двух других VPN протоколов. Это благодаря дополнительному HTTPS шифрованию, помимо заголовка SSTP. L2TP и PPTP не имеют заголовков уровня приложений для шифровки соединения.

Рисунок 1

Мы возьмем для примера простую сеть из трех машин, чтобы посмотреть, как работает SSTP. Названия и характеристики этих трех машин следующие:

Vista Business Edition

Vista Service Pack 1

Non-domain member

W2008RC0-VPNGW:

Two NICs " Internal and External

WIN2008RC-DC:

Windows Server 2008 Enterprise Edition

Domain Controller of MSFIREWALL.ORG domain

Certificate Server (Enterprise CA)

Обратите внимание, что Vista Service Pack 1 используется в качестве VPN клиента. Хотя в прошлом были обсуждения по поводу Windows XP Service Pack 3, поддерживающей SSTP, дело может закончиться совсем не так. Я недавно установил пробную версию Windows XP Service Pack 3 на тестовый компьютер и не нашел никаких доказательств поддержки SSTP. И это действительно плохо, поскольку на сегодняшний день слишком много ноутбуков используют ОС Windows XP, а факты говорят о том, что Vista слишком медлительна для работы ноутбуков. Возможно, проблемы производительности Vista будут решены с помощью пакета обновления Vista Service Pack 1.

Высокоуровневая конфигурация примерной сети показана на рисунке ниже.

Рисунок 2

Конфигурирование Windows Server 2008 в качестве сервера Remote Access SSL VPN Server

Я не собираюсь рассматривать все шаги, начиная с самых основ. Смею предположить, что вы установили контроллер домена и активировали DHCP, DNS и Certificate Services роли на этом сервере. Тип сертификации сервера должен быть Enterprise, и вы имеете CA в вашей сети. Сервер VPN должен быть подключен к домену, прежде чем продолжать выполнять следующие шаги. Прежде чем начинать, нужно установить пакет обновления SP1 для клиента Vista.

Нам нужно выполнить следующие процедуры для того, чтобы наше решение работало:

Установить IIS на VPN сервер
Запросить сертификат машины для сервера VPN, используя мастера запроса сертификатов IIS Certificate Request Wizard
Установить роль RRAS на сервере VPN
Активировать RRAS Server и настроить его на работу в качестве VPN и NAT сервера
Настроить NAT сервер на публикацию CRL
Настроить учетную запись (User Account) на использование dial-up соединений
Настроить IIS на Certificate Server, чтобы разрешить HTTP соединения для директории CRL
Настроить HOSTS файл для VPN клиента
Использовать PPTP для связи с VPN сервером
Получить CA Certificate из Enterprise CA
Настроить клиента на использование SSTP и соединение с сервером VPN с помощью SSTP

Установка IIS на VPN сервер

Возможно, вам покажется странным, что мы начинаем именно с этой процедуры, так как я рекомендую никогда не устанавливать вебсервер на устройство безопасности сети. Хорошая новость заключается в том, что нам не придется хранить вебсервер на VPN сервере, он понадобится нам лишь на некоторое время. Причина кроется в том, что регистрационный сайт, включенный в Windows Server 2008 Certificate Server, более не является полезным для запроса сертификатов компьютера. На самом деле он вообще бесполезен. Интересно то, что если вы все же решите использовать регистрационный сайт для получения сертификата компьютера, все будет выглядеть так, словно сертификат получен и установлен, однако на самом деле это не так, сертификат не установлен.

Для решения этой проблемы мы воспользуемся преимуществом того, что используем enterprise CA. При использовании Enterprise CA, можно посылать запрос на интерактивный сервер сертификации. Интерактивный запрос на получение сертификата компьютера возможен, когда вы используете мастера IIS Certificate Request Wizard и запрашиваете то, что теперь называется сертификатом домена "Domain Certificate". Это возможно только в том случае, если запрашивающая машина принадлежит тому же домену, что и Enterprise CA.

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

Откройте Windows 2008 Server Manager.
В левой панели консоли кликните на вкладке Роли .

Рисунок 1

Жмем в меню Добавить роли с правой стороны правой панели.
Жмем Далее на странице Прежде чем начать .
Ставим галочку напротив строкиWeb Server (IIS) на странице Выбрать роли сервера . Жмем Далее .

Рисунок 2

Можете прочесть информацию на странице Web Server (IIS) , если пожелаете. Это довольно полезная общая информация об использовании IIS 7 в качестве вебсервера, но поскольку мы не собираемся использовать IIS вебсервер на VPN сервере, эта информация не совсем применима в нашей ситуации. Жмем Далее .
На странице Выбрать службы ролей несколько опций уже выбраны. Однако если вы используете опции по умолчанию, вы не сможете воспользоваться мастером Certificate Request Wizard. По крайней мере, так было, когда я тестировал систему. Нет службы роли для мастера Certificate Request Wizard, поэтому я пытался ставить галочки напротив каждой опции Безопасность , и, кажется, сработало. Сделайте то же самое у себя и нажмите Далее .

Рисунок 3

Просмотрите информацию на странице Подтвердить выбор установок и нажмите Установить .
Нажмите Закрыть на странице Результаты установки .

Рисунок 4

Запрос сертификата машины (Machine Certificate) для VPN сервера с помощью мастера IIS Certificate Request Wizard

Следующий шаг - это запрос сертификата машины для VPN сервера. VPN серверу требуется сертификат машины для создания SSL VPN соединения с компьютером клиента SSL VPN. Общее название сертификата должно соответствовать имени, которое VPN клиент будет использовать для соединения с компьютером шлюза SSL VPN. Это означает, что вам нужно будет создать публичную DNS запись для имени на сертификате, который будет разрешать внешний IP адрес VPN сервера, или IP адрес NAT устройства перед VPN сервером, которое будет переадресовывать соединение на SSL VPN сервер.

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

В Server Manager , разверните вкладку Роли в левой панели, а затем разверните вкладку Web Server (IIS) . Нажмите на .

Рисунок 5

В консоли Internet Information Services (IIS) Manager , которая появится справа в левой панели, нажмите на имени сервера. В этом примере имя сервера будет W2008RC0-VPNGW . Нажмите на иконку Сертификаты сервера в правой панели консоли IIS.

Рисунок 6

В правой панели консоли жмем на ссылку Создать сертификат домена .

Рисунок 7

Введите информацию на странице Определенные свойства имени . Самым важным объектом здесь будет Общее имя . Это то имя, которое VPN клиенты будут использовать для соединения с VPN сервером. Вам также понадобится публичная DNS запись для этого имени с тем, чтобы распознавать внешний интерфейс VPN сервера, или публичный адрес NAT устройства перед VPN сервером. В этом примере мы используем общее имя sstp.msfirewall.org . Позже мы создадим записи HOSTS файла на компьютере VPN клиента, чтобы он мог распознавать это имя. Жмем Далее .

Рисунок 8

На странице жмем кнопку Выбрать . В диалоговом окне Выбрать источник сертификатов , жмем на имени Enterprise CA и нажимаем OK . Вводим дружественное имя в строке Friendly name . В этом примере мы использовали имя SSTP Cert , чтобы знать, что оно используется для шлюза SSTP VPN.

Рисунок 9

Жмем Закончить на странице Интерактивный источник сертификатов .

Рисунок 10

Мастер будет запущен, а затем исчезнет. После этого вы увидите, как появится сертификат в консоли IIS. Кликнем дважды на сертификате и увидим общее имя в секции Назначен для , и теперь у нас есть частный ключ, соответствующий сертификату. Жмем OK , чтобы закрыть диалоговое окно Сертификат .

Рисунок 11

Теперь, когда у нас есть сертификат, мы можем установить роль RRAS Server Role. Обратите внимание на то, что очень важно установить сертификат до того, как устанавливать роль RRAS Server Role. Если вы этого не сделаете, вы наживете себе большие головные боли, поскольку вам придется использовать довольно сложную рутину командных строк, чтобы связать сертификат с клиентом SSL VPN.

Установка роли RRAS Server Role на VPN сервере

Для установки роли RRAS Server Role нужно выполнить следующие шаги:

В Server Manager , нажмите на вкладку Роли в левой панели консоли.
В секции Общие сведения ролей нажмите на ссылку Добавить роли .
Нажмите Далее на странице Прежде чем начать .
На странице Выбрать роли сервера поставьте галочку напротив строки . Нажмите Далее .

Рисунок 12

Прочтите информацию на странице Политика сети и службы доступа . Большая ее часть касается Network Policy Server (который ранее назывался Internet Authentication Server и по сути был RADIUS сервером) и NAP, ни один из элементов не применим в нашем случае. Нажимаем Далее .
На странице Выбрать службы роли ставим галочку напротив строки Маршрутизация и службы удаленного доступа . В результате этого будут выбраны пункты Службы удаленного доступа и Маршрутизация . Жмем Далее .

Рисунок 13

Жмем Установить в окне Подтвердить выбранные установки .
Жмем Закрыть на странице Результаты установки .

Активация RRAS Server и его настройка в качестве VPN и NAT сервера

Теперь, когда роль RRAS установлена, нам нужно активировать сервисы RRAS, также как мы делали это в предыдущих версиях Windows. Нам нужно активировать функцию VPN сервера и сервисы NAT. С активацией компонента VPN сервера все понятно, но вы можете поинтересоваться, зачем нужно активировать NAT сервер. Причина активации сервера NAT кроется в том, что внешние клиенты могут получать доступ к серверу сертификации (Certificate Server), чтобы соединяться с CRL. Если клиент SSTP VPN не сможет загрузить CRL, SSTP VPN соединение работать не будет.

Для того, чтобы открыть доступ к CRL, мы настроим VPN сервер в качестве NAT сервера и опубликуем CRL, используя обратимый NAT. В сетевом окружении компаний у вас, скорее всего, будут брандмауэры, например ISA Firewall, перед сервером сертификации, поэтому вы сможете публиковать CRL с помощью брандмауэров. Однако в этом примере единственный брандмауэр, которым будем пользоваться, это брандмауэр Windows Firewall на сервере VPN, поэтому в этом примере нам нужно настроить VPN сервер в качестве NAT сервера.

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

В Server Manager разверните вкладку Роли в левой панели консоли. Разверните вкладку Политика сети и Службы доступа и кликните по вкладке . Правой клавишей кликните по вкладке и нажмите Настроить и активировать маршрутизацию и удаленный доступ .

Рисунок 14

Нажмите Далее в окне Welcome to the Routing and Remote Access Server Setup Wizard .
На странице Конфигурация выберите опцию Доступ к виртуальным частным сетям и NAT и нажмите Далее .

Рисунок 15

На странице VPN соединение выберите NIC в секции Интерфейсы сети , которая представляет внешний интерфейс VPN сервера. Затем нажмите Далее .

Рисунок 16

На странице Назначение IP адресов выберите опцию Автоматически . Мы можем выбрать эту опцию, потому что у нас установлен DHCP сервер на контроллере домена за VPN сервером. Если у вас нет DHCP сервера, тогда вам нужно будет выбрать опцию Из определенного списка адресов , а затем внести список адресов, которые VPN клиенты смогут использовать при подключении к сети через шлюз VPN. Жмем Далее .

Рисунок 17

На странице Управление удаленным доступом нескольких серверов выбираем Нет, использовать маршрутизацию и удаленный доступ для аутентификации запросов соединения . Эту опцию мы используем, когда недоступны NPS или RADIUS серверы. Поскольку VPN сервер является членом домена, можно аутентифицировать пользователей, используя учетные записи домена. Если VPN сервер не входит в домен, тогда только локальные учетные записи VPN сервера можно использовать, если только вы не решите использовать NPS сервер. Я напишу статью об использовании NPS сервера в будущем. Жмем Далее .

Рисунок 18

Прочтите общую информацию на странице Завершение работы мастера настройки маршрутизации и удаленного доступа и нажмите Закончить .
Нажмите OK в диалоговом окне Маршрутизация и удаленный доступ , которое говорит вам о том, что распределение DHCP сообщений требует агента распределения DHCP.
В левой панели консоли разверните вкладку Маршрутизация и удаленный доступ и затем нажмите на вкладке Порты . В средней панели вы увидите, что WAN Miniport соединения для SSTP теперь доступны.

Рисунок 19

Настройка NAT сервера для публикации CRL

Как я говорил ранее, клиент SSL VPN должен иметь возможность загружать CRL для подтверждения того, что сертификат сервера на сервере VPN не был поврежден или отозван. Для этого нужно настроить устройство перед сервером сертификации для направления HTTP запросов о расположении CRL на Сервер сертификации.

Как узнать, к какому URL нужно подключиться SSL VPN клиенту, чтобы загрузить CRL? Эта информация содержится в самом сертификате. Если вы снова перейдете на VPN сервер и дважды кликните на сертификате в IIS консоли, как делали прежде, вы сможете найти эту информацию.

Жмем на кнопку Детали на сертификате и листаем вниз до записи Точки распределения CRL , затем жмем на эту запись. В нижней панели показаны различные точки распределения, основанные на протоколе, используемом для получения доступа к этим точкам. В сертификате, показанном на рисунке ниже, видно, что нам нужно открыть доступ клиенту SSL VPN к CRL через URL:

http://win2008rc0-dc.msfirewall.org/CertEnroll/WIN2008RC0-DC.msfirewall.org.crl

Рисунок 20

Именно поэтому нужно создавать публичные записи DNS для этого имени, чтобы внешние VPN клиенты смогли относить это имя к IP адресу или устройству, которое будет выполнять обратимый NAT или обратимый proxy для получения доступа к вебсайту сервера сертификации. В этом примере нам нужно связать win2008rc0-dc.msfirewall.org с IP адресом на внешнем интерфейсе VPN сервера. Когда соединение достигает внешнего интерфейса VPN сервера, VPN сервер перенаправит NAT соединение на сервер сертификации.

Если вы используете расширенный брандмауэр, например ISA Firewall, вы можете сделать публикацию CRL сайтов более безопасной, открывая доступ только к CRL, а не ко всему сайту. Однако в этой статье мы ограничим себя возможностью простого NAT устройства, такого, которое обеспечивает RRAS NAT.

Следует отметить, что использование имени CRL сайта по умолчанию может быть менее безопасной опцией, поскольку оно раскрывает частное имя компьютера в Интернете. Вы можете создавать пользовательскую CDP (CRL Distribution Point), чтобы этого избежать, если считаете, что раскрытие частного имени вашей CA в публичной DNS записи создает угрозу безопасности.

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

В левой панели Server Manager разверните вкладку Маршрутизация и удаленный доступ , а затем разверните вкладку IPv4 . Кликните по вкладке NAT .
Во вкладке NAT кликните правой клавишей на внешнем интерфейсе в средней панели консоли. В данном примере имя внешнего интерфейса было Local Area Connection . Нажмите на Свойства .

Рисунок 21

В диалоговом окне поставьте галочку напротив Web Server (HTTP) . Это вызовет диалоговое окно Служба редактирования . В текстовой строке Частный адрес введите IP адрес сервера сертификации во внутренней сети. Нажмите OK .

Рисунок 22

Нажмите OK в диалоговом окне Свойства Local Area Connection .

Рисунок 23

Теперь, когда NAT сервер установлен и настроен, мы можем перенести наше внимание на настройку сервера CA и клиента SSTP 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 доступа для учетной записи администратора домена по умолчанию:

На контроллере домена откройте консоль Active Directory пользователи и компьютеры из меню .
В левой панели консоли разверните имя домена и кликните по вкладке пользователи . Дважды кликните на учетной записи Администратор .
Перейдите по вкладке Dial-in . Параметром по умолчанию будет Контроль доступа через NPS политику сети . Поскольку у нас нет NPS сервера в этом сценарии, мы изменим параметр на Разрешить доступ , как показано ниже на рисунке 1. Жмем OK .

Рисунок 1

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

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

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

В меню Инструменты администрирования откройте менеджера Internet Information Services (IIS) Manager .
В левой панели консоли IIS разверните имя сервера, а затем разверните вкладку Сайты . Разверните вкладку Веб сайт по умолчанию и кликните на вкладке CertEnroll , как показано на рисунке 2.

Рисунок 2

Если вы посмотрите на среднюю панель консоли, вы увидите, что CRL находится в этой виртуальной директории, как показано на рисунке ниже. Чтобы посмотреть содержимое этой виртуальной директории, вам нужно нажать кнопку Посмотреть содержимое в нижней части средней панели.

Рисунок 3

Нажмите на кнопку Просмотр параметров внизу средней панели. Внизу средней панели дважды кликните на иконке Параметры SSL .

Рисунок 4

В средней панели появится страница Параметры SSL . Уберите галочку в строке Требовать SSL . Нажмите Применить в правой панели консоли.

Рисунок 5

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

Рисунок 6

Настройка 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 клиента выполните следующие процедуры:

В меню Пуск введите c:\windows\system32\drivers\etc\hosts в строку поиска и нажмите ENTER.
В диалоговом окне Открыть с помощью выберите Блокнот .
Введите записи в HOSTS файл в формате, как показано на рисунке ниже. Обязательно нажмите enter после последней строки, чтобы курсор находился под ней.

Рисунок 7

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

Использование 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 клиенте выполните следующие шаги:

На VPN клиенте кликните правой клавишей на иконке сети и нажмите Сеть и коммутационный центр (Sharing Center) .
В окне Сеть коммутационного центра нажмите на ссылке Создать соединение или сеть в левой части окна.
На странице Выбрать опции подключения нажмите на записи Подключиться к рабочему месту , затем нажмите Далее .

Рисунок 8

На странице Как вы хотите подключиться выберите опцию Использовать мое Интернет соединение (VPN) .

Рисунок 9

На странице Введите Интернет адрес для подключения введите имя SSL VPN сервера. Убедитесь в том, что это имя и общее имя на сертификате, используемом сервером SSL VPN, одинаковое. В этом примере имя было sstp.msfirewall.org . Введите Имя адресата . В этом примере мы будем использовать имя адресата SSL VPN . Нажмите Далее .

Рисунок 14

В окне Сеть и коммутационный центр , нажмите на ссылку Показать статус в разделе SSL VPN , как показано на рисунке ниже. В диалоговом окне Статус SSL VPN вы увидите, что тип соединения VPN - это PPTP. Нажмите Закрыть в диалоговом окне Статус SSL VPN .

Рисунок 15

Откройте окно командной строки и отправьте команду ping на контроллер домена. В этом примере IP адрес контроллера домена будет 10.0.0.2 . Если ваше VPN соединение успешное, вы получите ping ответ с контроллера домена.

Рисунок 16

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

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

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

На клиенте VPN, подключенном к VPN серверу через PPTP соединение, введите http://10.0.0.2/certsrv в строке адреса в обозревателе Internet Explorer и нажмите ENTER.
Введите имя пользователя и пароль, используемый в мандатном диалоговом окне. В этом примере мы будем использовать имя пользователя и пароль учетной записи администратора домена по умолчанию.
На странице Приветствие сайта регистрации перейдите по ссылке Загрузить сертификат CA, цепь сертификатов или CRL .

Рисунок 17

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

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

Жмем Пуск , затем вводим mmc в строку поиска и нажимаем ENTER.
Жмем Продолжить в диалоговом окне UAC.
В окне Консоль1 жмем меню Файл , а затем жмем Добавить/Удалить оснастку .
В диалоговом окне Добавить или Удалить оснастки выбираем Сертификаты в списке Доступные оснастки , затем нажимаем Добавить .
На странице Оснастки сертификатов выбираем опцию Учетная запись компьютера и жмем Закончить .
На странице Выбрать компьютер выбираем опцию Локальный компьютер и жмем Закончить .
Жмем OK в диалоговом окне Добавить или удалить оснастки .
В левой панели консоли разворачиваем вкладку Сертификаты (Локальный компьютер) и затем разворачиваем вкладку Жмем Закончить на странице Завершение импорта сертификатов .
Жмем OK в диалоговом окне, информирующем о том, что импорт прошел успешно.
Теперь в консоли появится сертификат, как показано на рисунке ниже.

Рисунок 24

Закрываем консоль 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:

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

Рисунок 25

В диалоговом окне Свойства SSL VPN перейдите по вкладке Сеть . В окне Тип VPN нажмите стрелку вниз и выберите опцию Secure Socket Tunneling Protocol (SSTP) , затем нажмите

Рисунок 29

Томас Шиндер (Thomas Shinder)

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

Прежде чем мы начнем, должен признаться, что знаю о наличии пошагового руководства по созданию SSTP соединений для Windows Server 2008, которое находится на www.microsoft.com веб-сайте. Мне показалось, что эта статья не отражает реально существующее окружение, которое используется в организациях для назначения сертификатов. Именно поэтому, и из-за некоторых проблемных моментов, которые не были затронуты в руководстве Microsoft, я решил написать эту статью. Я считаю, что вы узнаете немного нового, если будет следовать за мной в этой статье.

Нам нужно выполнить следующие процедуры для того, чтобы наше решение работало:

Установить IIS на VPN сервер
Запросить сертификат машины для сервера VPN, используя мастера запроса сертификатов IIS Certificate Request Wizard
Установить роль RRAS на сервере VPN
Активировать RRAS Server и настроить его на работу в качестве VPN и NAT сервера
Настроить NAT сервер на публикацию CRL
Настроить учетную запись (User Account) на использование dial-up соединений
Настроить IIS на Certificate Server, чтобы разрешить HTTP соединения для директории CRL
Настроить HOSTS файл для VPN клиента
Использовать PPTP для связи с VPN сервером
Получить CA Certificate из Enterprise CA
Настроить клиента на использование SSTP и соединение с сервером VPN с помощью SSTP

Установка IIS на VPN сервер

Для решения этой проблемы мы воспользуемся преимуществом того, что используем enterprise CA. При использовании Enterprise CA, можно посылать запрос на интерактивный сервер сертификации. Интерактивный запрос на получение сертификата компьютера возможен, когда вы используете мастера IIS Certificate Request Wizard и запрашиваете то, что теперь называется сертификатом домена ‘Domain Certificate’. Это возможно только в том случае, если запрашивающая машина принадлежит тому же домену, что и Enterprise CA.
Для установки роли IIS Web server на сервере VPN выполните следующие шаги:

Откройте Windows 2008 Server Manager.
В левой панели консоли кликните на вкладке Роли .

Жмем в меню Добавить роли с правой стороны правой панели.
Жмем Далее на странице Прежде чем начать .
Ставим галочку напротив строкиWeb Server (IIS) на странице Выбрать роли сервера . Жмем Далее .

Можете прочесть информацию на странице Web Server (IIS) , если пожелаете. Это довольно полезная общая информация об использовании IIS 7 в качестве вебсервера, но поскольку мы не собираемся использовать IIS вебсервер на VPN сервере, эта информация не совсем применима в нашей ситуации. Жмем Далее .
На странице Выбрать службы ролей несколько опций уже выбраны. Однако если вы используете опции по умолчанию, вы не сможете воспользоваться мастером Certificate Request Wizard. По крайней мере, так было, когда я тестировал систему. Нет службы роли для мастера Certificate Request Wizard, поэтому я пытался ставить галочки напротив каждой опции Безопасность , и, кажется, сработало. Сделайте то же самое у себя и нажмите Далее .

Просмотрите информацию на странице Подтвердить выбор установок и нажмите Установить .
Нажмите Закрыть на странице Результаты установки .

Запрос сертификата машины (Machine Certificate) для VPN сервера с помощью мастера IIS Certificate Request Wizard

Следующий шаг – это запрос сертификата машины для VPN сервера. VPN серверу требуется сертификат машины для создания SSL VPN соединения с компьютером клиента SSL VPN. Общее название сертификата должно соответствовать имени, которое VPN клиент будет использовать для соединения с компьютером шлюза SSL VPN. Это означает, что вам нужно будет создать публичную DNS запись для имени на сертификате, который будет разрешать внешний IP адрес VPN сервера, или IP адрес NAT устройства перед VPN сервером, которое будет переадресовывать соединение на SSL VPN сервер.

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

В Server Manager , разверните вкладку Роли в левой панели, а затем разверните вкладку Web Server (IIS) . Нажмите на .

В консоли Internet Information Services (IIS) Manager , которая появится справа в левой панели, нажмите на имени сервера. В этом примере имя сервера будет W2008RC0-VPNGW . Нажмите на иконку Сертификаты сервера в правой панели консоли IIS.

В правой панели консоли жмем на ссылку Создать сертификат домена .

Введите информацию на странице Определенные свойства имени . Самым важным объектом здесь будет Общее имя . Это то имя, которое VPN клиенты будут использовать для соединения с VPN сервером. Вам также понадобится публичная DNS запись для этого имени с тем, чтобы распознавать внешний интерфейс VPN сервера, или публичный адрес NAT устройства перед VPN сервером. В этом примере мы используем общее имя sstp.msfirewall.org . Позже мы создадим записи HOSTS файла на компьютере VPN клиента, чтобы он мог распознавать это имя. Жмем Далее .

На странице жмем кнопку Выбрать . В диалоговом окне Выбрать источник сертификатов , жмем на имени Enterprise CA и нажимаем OK . Вводим дружественное имя в строке Friendly name . В этом примере мы использовали имя SSTP Cert , чтобы знать, что оно используется для шлюза SSTP VPN.

Жмем Закончить на странице Интерактивный источник сертификатов .

Мастер будет запущен, а затем исчезнет. После этого вы увидите, как появится сертификат в консоли IIS. Кликнем дважды на сертификате и увидим общее имя в секции Назначен для , и теперь у нас есть частный ключ, соответствующий сертификату. Жмем OK , чтобы закрыть диалоговое окно Сертификат .

Установка роли RRAS Server Role на VPN сервере

Для установки роли RRAS Server Role нужно выполнить следующие шаги:

В Server Manager , нажмите на вкладку Роли в левой панели консоли.
В секции Общие сведения ролей нажмите на ссылку Добавить роли .
Нажмите Далее на странице Прежде чем начать .
На странице Выбрать роли сервера поставьте галочку напротив строки . Нажмите Далее .

Прочтите информацию на странице Политика сети и службы доступа . Большая ее часть касается Network Policy Server (который ранее назывался Internet Authentication Server и по сути был RADIUS сервером) и NAP, ни один из элементов не применим в нашем случае. Нажимаем Далее .
На странице Выбрать службы роли ставим галочку напротив строки Маршрутизация и службы удаленного доступа . В результате этого будут выбраны пункты Службы удаленного доступа и Маршрутизация . Жмем Далее .

Жмем Установить в окне Подтвердить выбранные установки .
Жмем Закрыть на странице Результаты установки .

Активация RRAS Server и его настройка в качестве VPN и NAT сервера

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

В Server Manager разверните вкладку Роли в левой панели консоли. Разверните вкладку Политика сети и Службы доступа и кликните по вкладке . Правой клавишей кликните по вкладке и нажмите Настроить и активировать маршрутизацию и удаленный доступ .

Нажмите Далее в окне Welcome to the Routing and Remote Access Server Setup Wizard .
На странице Конфигурация выберите опцию Доступ к виртуальным частным сетям и NAT и нажмите Далее .

На странице VPN соединение выберите NIC в секции Интерфейсы сети , которая представляет внешний интерфейс VPN сервера. Затем нажмите Далее .

На странице Назначение IP адресов выберите опцию Автоматически . Мы можем выбрать эту опцию, потому что у нас установлен DHCP сервер на контроллере домена за VPN сервером. Если у вас нет DHCP сервера, тогда вам нужно будет выбрать опцию Из определенного списка адресов , а затем внести список адресов, которые VPN клиенты смогут использовать при подключении к сети через шлюз VPN. Жмем Далее .

На странице Управление удаленным доступом нескольких серверов выбираем Нет, использовать маршрутизацию и удаленный доступ для аутентификации запросов соединения . Эту опцию мы используем, когда недоступны NPS или RADIUS серверы. Поскольку VPN сервер является членом домена, можно аутентифицировать пользователей, используя учетные записи домена. Если VPN сервер не входит в домен, тогда только локальные учетные записи VPN сервера можно использовать, если только вы не решите использовать NPS сервер. Я напишу статью об использовании NPS сервера в будущем. Жмем Далее .

Прочтите общую информацию на странице Завершение работы мастера настройки маршрутизации и удаленного доступа и нажмите Закончить .
Нажмите OK в диалоговом окне Маршрутизация и удаленный доступ , которое говорит вам о том, что распределение DHCP сообщений требует агента распределения DHCP.
В левой панели консоли разверните вкладку Маршрутизация и удаленный доступ и затем нажмите на вкладке Порты . В средней панели вы увидите, что WAN Miniport соединения для SSTP теперь доступны.

Настройка NAT сервера для публикации CRL

http://win2008rc0-dc.msfirewall.org/CertEnroll/WIN2008RC0-DC.msfirewall.org.crl

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

В левой панели Server Manager разверните вкладку Маршрутизация и удаленный доступ , а затем разверните вкладку IPv4 . Кликните по вкладке NAT .
Во вкладке NAT кликните правой клавишей на внешнем интерфейсе в средней панели консоли. В данном примере имя внешнего интерфейса было Local Area Connection . Нажмите на Свойства .

В диалоговом окне поставьте галочку напротив Web Server (HTTP) . Это вызовет диалоговое окно Служба редактирования . В текстовой строке Частный адрес введите IP адрес сервера сертификации во внутренней сети. Нажмите OK .

Нажмите OK в диалоговом окне Свойства Local Area Connection .

Заключение

В этой статье мы продолжили разговор о настройке сервера SSL VPN, используя Windows Server 2008. Мы рассмотрели установку IIS на VPN сервер, запрос и установку сертификата сервера, установку и настройку сервисов RRAS и NAT на VPN сервере. В следующей статье мы закончим рассматривать настройку CA сервера и SSTP VPN клиента. До встречи! Том.

Прошло уже более года, после того как мы начали работу с . Накопился некоторый опыт использования описанной конфигурации, были выявлены её плюсы и минусы, сделаны определённые выводы. Опираясь на эти выводы, в данной заметке мы продолжим развитие темы настройки безопасных 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 (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке . Часть инструкций доступна для онлайн просмотра и обсуждения .

Три дня и три ночи я долбался с 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. Но как уже говорилось ранее, пока данная технология в России не набрала своей популярности, в то время как производители данных решений сообщают об очень высоком спросе на них среди западных компаний.