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

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

IPSec VPN считается более безопасным протоколом.

SSL и TLS

Очень часто в технической литературе можно встретить понятия SSL и TLS.

Оба протокола являются cryptographic protocols , обеспечивающие безопасную передачу данных поверх интернет(e-mail, web browsing, instant messaging).
Протоколы обеспечивают confidentiality, integrity, authentication services.
SSL и TLS работают на уровне Session Layer модели OSI или выше.
Протоколы могут использовать public key infrastructure (PKI) а также сертификаты для аутентификации и передачи друг другу симметричных ключей.
Также как и IPSec для шифрования данных они используют симметричные ключи.

Большинство безопасных передач на браузере производятся через SSL или TLS.
Изначально появился SSL, его разработала компания Netscape.
TLS является дальнейшим развитием SSL, а также стандартом, разработанным Internet Engineering Task Force (IETF) .
Например TLS 1.0 основан на SSL3.0.
Что конкретно использовать SSL или TLS решают сами браузеры: предпочтителен TLS но возможно переключение и на SSL.

Таким образом, важно понимать, что используя термин SSL мы подразумеваем SSL или TLS.
К примеру Cisco SSL VPN реально использует TLS.

Операции SSL

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

• Клиент инициализирует подключение к серверу на его IP адрес и порт 443. В качестве источника используется соответственно IP клиента и порт выше чем 1023
• Происходит стандартный процесс TCP подключения, использующий three-way handshake
• Клиент запращивает подключение по SSL и сервер отвечает высылая свой digital certificate, который содержит public key этого сервера.
• Получив сертификат, клиент должен решить: доверять этому сертификату или нет.
  Здесь начинают работать механизмы PKI.
  Если digital certificate подписан CA, которой клиент доверяет + сертификат валидный по дате + серийник сертификата не числится в certificate revocation list (CRL) - клиент может доверять сертификату и использовать public key этого сертификата.
• Клиент генерирует симметричный ключ shared secret , который будет использоваться для шифрования данных между клиентом и сервером. Далее клиент шифрует shared secret с использованием public key и передает это серверу.
• Сервер, используя свой private key , расшифровывает полученный симметричный ключ shared secret .
• Обе стороны теперь знают shared secret и могут шифровать SSL Session.

Типы SSL VPN

SSL VPN можно разделить на два вида:

• Clientless SSL VPN - также называется Web VPN . Не требует установки клиента. Ограниченные возможности.
• Full Cisco AnyConnect Secure Mobility Client SSL VPN Client - полноценный SSL клиент, требующий установки на клиента ПО, обеспечивающее полноценный доступ к корпоративной сети

Настройка SSL VPN

1. Копируем файл Anyconnect PKG.
   В нашем случае это anyconnect-win-3.1.08009-k9.pkg
2. Указываем на файл pkg, и включаем сервис Webvpn Anyconnect service.
   

   webvpn anyconnect image disk0:/anyconnect-win-3.1.08009-k9.pkg 1 enable outside2 anyconnect enable

3. Исключаем (exempt) трафик SSL WebVPN от проверок на outside interface ACL . Нам нужно либо сделать в ACL правила permit, либо использовать команду:
   

   msk-asa-01(config)# sysopt connection permit-vpn

4. Для удобства настроим перенаправление с 80 на 443:
   

   http redirect outside2 80

5. Создадим IP address pool . Эти адреса будут выдаваться удалённым пользователям.
   

   ip local pool vpnpool_pool 192.168.93.10-192.168.93.254 mask 255.255.255.0

6. Создаём NAT exemption для трафика между LAN Network и сетью vpnpool. Мы делаем данное исключение, поскольку шифрованный трафик не должен проходить через NAT. Данный шаг необходим в случае если на ASA настроен этот NAT.
   object network vpnpool_obj

   object network vpnpool_obj subnet 192.168.92.0 255.255.255.0 object-group network RFC1918_objg network-object 192.168.0.0 255.255.0.0 network-object 172.16.0.0 255.240.0.0 network-object 10.0.0.0 255.0.0.0 nat (inside,outside) source static RFC1918_objg RFC1918_objg destination static vpnpool_obj vpnpool_obj no-proxy-arp route-lookup

7. Создаём Split-Tunnel ACL, данная настройка позволит пользователям при подключении по VPN одновременно пользоваться интернетом. Без этой настройки в туннель будет заворачиваться весь трафик.
   

   access-list split-tunnel_acl standard permit 192.168.10.0 255.255.255.0

   Данная настройка будет заворачивать в туннель только трафик в сети той же RFC1918.

8. Создаём Group Policy .
   Мы можем создать несколько Group Policy, и в каждой настроить сетевые атрибуты типа DNS server addresses, split-tunneling settings, default domain, протокол(SSL или IPSec) и т.д.

   group-policy anyconnect_gp internal group-policy anyconnect_gp attributes dns-server value 192.168.10.5 vpn-tunnel-protocol ssl-client ssl-clientless split-tunnel-policy tunnelspecified split-tunnel-network-list value split-tunnel_acl webvpn anyconnect keep-installer installed anyconnect dpd-interval client 20 anyconnect ask none default anyconnect

9. Создадим Tunnel Group .
   Tunnel Group в интерфейсе ASDM называется как Connection Profile.
   Tunnel Group должна в себя включать только что нами настроенную Group Policy и объединяет её с IP address pool.
   Мы можем создать несколько таких групп, а пользователь при логине может выбрать для себя нужную Tunnel Group со всеми нужными характеристиками: наследуемые параметры из Group Policy + address-pool

   tunnel-group vpn-users_tg type remote-access tunnel-group vpn-users_tg general-attributes address-pool vpnpool_pool default-group-policy anyconnect_gp tunnel-group vpn-users_tg webvpn-attributes group-alias vpn_users-alias enable webvpn tunnel-group-list enable

   Последняя команда позволяет пользователям выбирать для себя tunnel-group.
   Для пользователей данная группа будет выглядеть с именем "vpn_users-alias"

Anyconnect уже должно заработать, - можно заходить под админской учёткой.

Мониторинг SSL VPN

• ASDM: Monitoring > VPN > VPN Statistics > Sessions
• Из CLI:
  

  vpn# show uauth Current Most Seen Authenticated Users 1 1 Authen In Progress 0 0 remote access VPN user "vpn_video_user1" at 192.168.92.25, authenticated access-list #ACSACL#-IP-video_dacl-54ddc357 (*)

  vpn# show access-list access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300 access-list split-tunnel_acl; 1 elements; name hash: 0xb6fb0e access-list split-tunnel_acl line 1 standard permit 192.168.10.0 255.255.255.0 (hitcnt=0) 0x13482529 access-list #ACSACL#-IP-video_dacl-54ddc357; 1 elements; name hash: 0x6c7d7b7f (dynamic) access-list #ACSACL#-IP-video_dacl-54ddc357 line 1 extended permit ip any4 host 192.168.10.45 (hitcnt=0) 0x4ce5deb8

  Смотрим кто залогинен

  show vpn-sessiond summary

  show vpn-sessiond anyconnect

  Выкинуть юзера из впн:

  vpn-sessiondb logoff name langemakj

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

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

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

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

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

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

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

Запрос сертификата машины (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 выполните следующие шаги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка 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

Именно поэтому нужно создавать публичные записи 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 запросов на сервер сертификации выполните следующие шаги:

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

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

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

Теперь, когда NAT сервер установлен и настроен, мы можем перенести наше внимание на настройку сервера CA и клиента SSTP VPN.

Заключение

В этой статье мы продолжили разговор о настройке сервера SSL VPN, используя Windows Server 2008. Мы рассмотрели установку IIS на VPN сервер, запрос и установку сертификата сервера, установку и настройку сервисов RRAS и NAT на VPN сервере. В следующей статье мы закончим рассматривать настройку CA сервера и SSTP 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 клиента выполните следующие процедуры:

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

Использование 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.

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

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

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

1. Закрываем консоль 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 (Часть...