Прошло уже более года, после того как мы начали работу с 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 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 вполне жизнеспособным себя показывает проект с открытым исходным кодом 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 соединения.
Полученный сертификат устанавливается на 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 (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке. Часть инструкций доступна для онлайн просмотра и обсуждения на нашем Вики.
RSS - Записи
Алексей, $10 стоит нужный сертификат публичного ЦС (RapidSSL). Китайский может работать, может нет, т.к. не факт, что на клиентском ПК корневой будет в хранилище.
Зачем писать инструкцию по настройке VPN, когда есть действующий SCCM через который можно развернуть политики подключения к VPN и экспортировать нужные сертификаты? На сколько помню SCCM у вас развернут.
Часть пользователей подключаются из дому. Там нет ни SCCM, ни специалиста тех.поддержки, который может понажимать нужные кнопки.
Добрый день.
Подскажите:
1) публичный сертификат на RAS (VPN) сервере используется для установления ssl/tls соединения, через которой и будет проходить аутентификация пользователя?
2) Можно ли сделать аутентификацию пользователя сертификатом?
1) Да.
2) Можно, но я такого опыта не имел, поэтому от комментариев на эту тему воздержусь.
Как раз пытаюсь реализовать 2 способ, если получится отпишусь.
Есть успехи?
мне кажется надо копать в сторону NPS, и там создавать правило на проверку наличия сертификата.
как я и думал (я использовал смарт карту для хранения сертификатов):
- правило NPS
- настройка клиента на смарт карту
- выпуск пользовательского сертификата на смарт карту
подробности позже
exonix, если есть желание, можете накидать step-by-step, мы опубликуем либо в Блоге, либо в Вики.
вот написал статью, как это делать:
http://exonix.ru/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D0%B8/Windows_Server/SSTP_SmartCard/
Помогите. Поднят Server 2012 R2, c Direct Access and RAS ролями, есть внешний wildcard сертификат Thawte, но при попытке подключится по SSTP выскакивает ошибка 866:Подключение удаленного доступа завершено, но не удалось выполнить проверку подлинности поскольку в сертификате на сервере не указано имя сервера. В чем может быть проблема? в том что используем wildcard сертификат ?
Вообще-то выше как раз и приведён пример с вайлкардом. И это работает.
Тогда я что-то не понимаю. попробую перечитать еще раз.
Алексей, подскажите пожалуйста направление куда копать?
неподскажите, почему в Encryption Type стоит - unknown ?
если потребуется переместить CRL на другой сервер, нужно ли перевыпускать сертификаты для компьютеров-клиентов?
Это зависит от того, каким образом в сертификатах прописан URL с CRL
прописан URL: crl1.domain.domain.com
т.е. если просто во внешнем DNS поменять IP этого сервера - то ничего не надо перевыпускать.
а как быть со строкой file://\\server\sharefolder? она то будет меняться на file://\\NEWserver\sharefolder (или уже во внутреннем DNS сделать CNAME :) ?)
Сомневаюсь, что внешним клиентам будет полезна ссылка типа \\server\sharefolder
Такие вещи из расположений CRL лучше убирать, чтобы оставались только HTTP URL, которые одинаково должны быть доступны как для внутренних так и для внешних клиентов.
так именно по адресу file:// AD CS будет выкладывать CRL... если её не указать то куда AD CS выложит CRL ??
Посмотрите настройки ЦС повнимательней. Там отдельно можно указать места:
А) в которых ЦС должен публиковать сведения об отзыве сертификатов (это может быть контейнер в AD, шара на сервере ЦС или даже шара на соседнем файловом сервере)
Б) из которых будут доступны данные об отзыве. Это может быть опять же шара, LDAP-каталог, HTTP. Я полагаю, что стоит здесь указывать именно только HTTP, и только тот, который доступен клиентам как внутренним так и внешним.
всё понял. file://\\ используется только для того, чтобы определить куда будет публиковаться CRL (пункт А). Но доступны CRL будут только по http:// (Пункт Б)
пришлось менять запись FILE://\\. Сертификаты НЕ перевыпускал. Всё работает.
Подскажите пожалуйста все уже перепробовал. При запросе сертификата через certutil выдает ошибку (Сервер RPC недоступен. 0x800706ba (WIN32:1722)) Через Web все нормально.
Причины могут быть разные. Посмотрите здесь. Начните с проверки firewall на стороне ЦС.
Есть еще маленький нюанс, если компьютер в домене все нормально отрабатывает.
Это только внешние пользователи, либо внутренние но не в домене.
Может сталкивались с таким.
Рекомендации по DCOM от Microsoft пробовал не помогает.
И firewall отключен.
Может кому пригодиться решилось дописыванием в логин при подключении к VPN @test.local
Алексей, здравствуйте.
Спасибо за статью.
1.Не знаете, сертификат от "Let's encrypt" для этих целей подойдёт?
2.Если на VPN-cli отключить проверку сертификата сервера, то сертификат без уважения точки распространения CRL подойдёт?
Здравствуйте, Юрий.
1. Практически - не знаю. Не имел с этими сертификатами дела. Теоретически - сертификат может быть любой, главное чтобы он соответствовал требованиям, о которых написано в заметке.
2. Должен, но это неправильно с точки зрения безопасности.
Понял вас. Спасибо.
Обратная ссылка: Сборка и установка deb-пакетов клиента SSTP VPN в Debian GNU/Linux 11 (Bullseye) — Блог IT-KB /