Windows Server 2012 R2 Remote Access — Настраиваем VPN сервер на использование протокола SSTP

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

Но прошло время, клиентов с 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 вполне жизнеспособным себя показывает проект с открытым исходным кодом SSTP-Client. Мной уже подготовлены пошаговые инструкции для не особо искушённых пользователей Linux-систем на примере настройки в Ubuntu Linux 14.04 и 15.04/15.10.

По поводу клиентских систем на базе ОС Apple Mac OS внятного пока ничего сказать не могу, так как под руками их у меня попросту нет. По имеющейся поверхностной информации можно использовать SSTP-Client (в качестве консольного варианта), а можно использовать созданный на его основе пакет 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 соединения.

image

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

image

Также разумеется, что ЦС выдавшему сертификат должны доверять не только наши 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

image

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

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

image

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

image

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

netstat -na | findstr 443

image

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

image

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

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

image

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

 

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

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

image

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

image

 

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

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

Всего комментариев: 29 Комментировать

  1. Стас /

    Алексей, $10 стоит нужный сертификат публичного ЦС (RapidSSL). Китайский может работать, может нет, т.к. не факт, что на клиентском ПК корневой будет в хранилище.

  2. Andrye /

    Зачем писать инструкцию по настройке VPN, когда есть действующий SCCM через который можно развернуть политики подключения к VPN и экспортировать нужные сертификаты? На сколько помню SCCM у вас развернут.

    1. Алексей Максимов / Автор записи

      Часть пользователей подключаются из дому. Там нет ни SCCM, ни специалиста тех.поддержки, который может понажимать нужные кнопки.

  3. archeegrig /

    Добрый день.
    Подскажите:
    1) публичный сертификат на RAS (VPN) сервере используется для установления ssl/tls соединения, через которой и будет проходить аутентификация пользователя?
    2) Можно ли сделать аутентификацию пользователя сертификатом?

    1. Алексей Максимов / Автор записи

      1) Да.
      2) Можно, но я такого опыта не имел, поэтому от комментариев на эту тему воздержусь.

      1. archeegrig /

        Как раз пытаюсь реализовать 2 способ, если получится отпишусь.

        1. exonix /

          Есть успехи?

          1. exonix /

            мне кажется надо копать в сторону NPS, и там создавать правило на проверку наличия сертификата.

          2. exonix /

            как я и думал (я использовал смарт карту для хранения сертификатов):
            — правило NPS
            — настройка клиента на смарт карту
            — выпуск пользовательского сертификата на смарт карту
            подробности позже

          3. Алексей Максимов / Автор записи

            подробности позже

            exonix, если есть желание, можете накидать step-by-step, мы опубликуем либо в Блоге, либо в Вики.

          4. exonix /

            вот написал статью, как это делать:
            http://exonix.ru/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D0%B8/Windows_Server/SSTP_SmartCard/

  4. archeegrig /

    Помогите. Поднят Server 2012 R2, c Direct Access and RAS ролями, есть внешний wildcard сертификат Thawte, но при попытке подключится по SSTP выскакивает ошибка 866:Подключение удаленного доступа завершено, но не удалось выполнить проверку подлинности поскольку в сертификате на сервере не указано имя сервера. В чем может быть проблема? в том что используем wildcard сертификат ?

    1. Алексей Максимов / Автор записи

      Вообще-то выше как раз и приведён пример с вайлкардом. И это работает.

      1. archeegrig /

        Тогда я что-то не понимаю. попробую перечитать еще раз.

      2. archeegrig /

        Алексей, подскажите пожалуйста направление куда копать?

  5. exonix /

    неподскажите, почему в Encryption Type стоит — unknown ?

  6. exonix /

    если потребуется переместить CRL на другой сервер, нужно ли перевыпускать сертификаты для компьютеров-клиентов?

    1. Алексей Максимов / Автор записи

      Это зависит от того, каким образом в сертификатах прописан URL с CRL

      1. exonix /

        прописан URL: crl1.domain.domain.com
        т.е. если просто во внешнем DNS поменять IP этого сервера — то ничего не надо перевыпускать.

        а как быть со строкой file://\\server\sharefolder? она то будет меняться на file://\\NEWserver\sharefolder (или уже во внутреннем DNS сделать CNAME :) ?)

        1. Алексей Максимов / Автор записи

          Сомневаюсь, что внешним клиентам будет полезна ссылка типа \\server\sharefolder
          Такие вещи из расположений CRL лучше убирать, чтобы оставались только HTTP URL, которые одинаково должны быть доступны как для внутренних так и для внешних клиентов.

          1. exonix /

            так именно по адресу file:// AD CS будет выкладывать CRL… если её не указать то куда AD CS выложит CRL ??

          2. Алексей Максимов / Автор записи

            Посмотрите настройки ЦС повнимательней. Там отдельно можно указать места:
            А) в которых ЦС должен публиковать сведения об отзыве сертификатов (это может быть контейнер в AD, шара на сервере ЦС или даже шара на соседнем файловом сервере)
            Б) из которых будут доступны данные об отзыве. Это может быть опять же шара, LDAP-каталог, HTTP. Я полагаю, что стоит здесь указывать именно только HTTP, и только тот, который доступен клиентам как внутренним так и внешним.

  7. exonix /

    всё понял. file://\\ используется только для того, чтобы определить куда будет публиковаться CRL (пункт А). Но доступны CRL будут только по http:// (Пункт Б)

    1. exonix /

      пришлось менять запись FILE://\\. Сертификаты НЕ перевыпускал. Всё работает.

  8. Serega /

    Подскажите пожалуйста все уже перепробовал. При запросе сертификата через certutil выдает ошибку (Сервер RPC недоступен. 0x800706ba (WIN32:1722)) Через Web все нормально.

    1. Алексей Максимов / Автор записи

      Причины могут быть разные. Посмотрите здесь. Начните с проверки firewall на стороне ЦС.

      1. Serega /

        Есть еще маленький нюанс, если компьютер в домене все нормально отрабатывает.
        Это только внешние пользователи, либо внутренние но не в домене.
        Может сталкивались с таким.
        Рекомендации по DCOM от Microsoft пробовал не помогает.

        1. Serega /

          И firewall отключен.

          1. Serega /

            Может кому пригодиться решилось дописыванием в логин при подключении к VPN @test.local

Добавить комментарий